Я тот ещё любитель поякать. Или как я умудряюсь создавать так много контента в канале

Есть неплохая рекомендация для блогеров, которые не знают, о чём писать:

1. Сделай какую-нибудь ерундень;
2. Расскажи о том, что сделал.

В начале карьеры почти никто не может рассказать о чём-то большом и сложном. Но день за днём делая что-то понемногу и рассказывая об этом, я перехожу ко всё более сложным и интересным делам, основанным на предыдущих, простых. Правда, для этого нужно не скакать с темы на тему, а заниматься штуками, которые направлены примерно в одну сторону.

Я много якаю. И обожаю читать других якальщиков. Эти люди рассказывают о том, что сделали сами, а не говорят другим, как надо делать. К ним не может возникнуть никаких вопросиков. А их опыт зачастую интересный и не искажённый псевдоэкспертностью. Их интересно читать даже когда они пишут о каких-то мелочах.

Когда я выдыхаюсь и мне не о чем писать? Только в периоды, когда я ничего не делаю ^_^ В такие моменты у меня есть два варианта: вспомнить какую-нибудь офигительную историю из далёкого прошлого либо пойти и сделать что-нибудь. Второй вариант предпочтительнее: он сделает меня лучшей версией себя. В то время как первый просто выиграет немного времени.

Как я учился говорить клиентам «не знаю», если действительно чего-то не знал

В детстве меня приучили к тому, что, если я не знаю ответа на какой-нибудь вопрос, нужно попробовать дойти до него своим умом. Порассуждать логически, подумать, погадать. Школьное образование только закрепило такой подход.

— В каком году Пушкин стрелялся с Дантесом?
— Не знаю :(
— А ты подумай.

Ну и я думал и зачастую действительно приходил к верному ответу. Но мне кажется, что в дальнейшей жизни это принесло мне больше вреда, чем пользы.

В общем, я окончил старшие классы школы, пробрался сквозь университет и вот уже общаюсь с собственными клиентами на проектирование интерфейсов в ранние двадцать. А принцип заниматься предположениями там, где я чего-то не знаю, так и сохранился.

— Как думаете, людям будет проще добавлять товары в корзину, если мы добавим здесь эту кнопку?
— Сколько времени займёт у верстальщика этот участок работы?
— Сколько будет стоить проектирование в вашем исполнении?

И я отвечал, отвечал, отвечал. Гадал, как будут вести себя пользователи на проекте, который ещё не готов. Оценивал работу верстальщика, хотя сам не продавал вёрстку. Прикидывал объёмы работы по проектированию ещё до погружения в проект и составления функциональных требований.

Коготок завяз — всей птичке пропасть.

В какой-то момент я посмотрел случайный ролик на Ютубе, где неизвестный мне автор рассказывал о том, что если чего-то не знаешь, то лучше так об этом сразу и сказать. И решил попробовать это дело в бою.

И получилось так, что, с одной стороны, первый же клиент, с которым я общался таким образом, ни разу не был разочарован в том, что я чего-то не знаю, и, с другой, мне не пришлось разгребать последствий своих рассуждений.

— Сколько будет стоить проектирование? Хотя бы примерно?
— Не знаю. Давайте погрузим меня в проект, составим функциональные требования — и я вам дам оценку!

— Сколько займёт этап вёрстки?
— Не знаю. Давайте найдём верстальщика и спросим у него.

— Как будут вести себя пользователи в этом участке интерфейса?
— Не знаю. Увидим, когда будет готово. Или можем протестировать прототип. Но я могу подробно рассказать, на каких предположениях основывался, проектируя эту часть.

Работать стало легче. Я взял подход на вооружение и теперь почти никогда не гадаю, если чего-то не знаю. Особенно сегодня, когда можно быстро получить необходимую информацию в Интернете и стать умнее.

Я начал обращать внимание на рассуждения в словах других людей. Специалисты, которые уверенно отвечали на любые мои вопросы, начинали вызывать подозрение. А вот те, которые говорили «это я не знаю, это я не знаю, это я не знаю, но зато вот в этом я специалист» зарабатывали больше доверия. Кажется, если человек честно признаётся в куче вещей, в которых не разбирается, то он также честно заявляет и о том, в чём действительно хорош.

Почему мы с клиентом поржали, когда студия-разработчик прислала КП по нашему проекту

Я не буду светить именами, но история свежая. Этим летом я больше месяца посвятил проектированию интерфейса интернет-магазина для клиента Проектората (если кто-то ещё не знает, это мой старый проектировщический бренд). В результате получился интерактивный прототип в Axure примерно на шестьдесят экранов и документ с функциональной спецификацией на сорок страниц.

Всё это дело мы передали в работу дизайнеру, с которым уже не раз работали вместе, а клиент начал потихоньку искать студию-разработчика, которая воплотила бы проект в жизнь. Одна из таких студий на днях прислала КП.

КП ждали две недели. Столько времени студии потребовалось на оценку. Цена немного не дотянула до десяти миллионов, но погоду делала не она. В оценку включили создание прототипа и дизайна (которые уже готовы, и студии об этом было известно). А если внимательно ознакомиться с табличкой, в которой расписаны все работы, то можно заметить, что на вёрстку каждого из модальных окон с подтверждением результата (это когда пользователь добавил, например, товар к сравнению, и видит сообщеньку: «Товар успешно добавлен к сравнению» и кнопку «Перейти к сравнению»), необходимо затратить по восемь часов времени.

Это выглядело смешно. Как будто табличку заполняли часами наобум. И даже если на самом деле оценка проводилась тщательно и внимательно, а часы затем равномерно были раскиданы по табличке, это всё равно было смешно, потому что ради проекта за несколько миллионов можно было потратить несколько часов на подготовку более достоверного КП.

Перед тем, как клиент пошёл искать подрядчика на разработку, я поделился с ним двумя мыслями.

Первая мысль. Чтобы просто ознакомиться с прототипом и функциональной спецификацией, разработчику придётся изрядно напрячь мозги и потратить много времени. Это точно больше рабочего дня, когда он не сможет заниматься ничем другим, а только въезжать в проект. И ещё не меньше понадобится для того, чтобы оценить по этим вводным разработку.

Эта работа не может быть бесплатной. Либо деньги на оценку умножаются на десять и закладываются в разработку под ключ (чтобы в случае, когда из десяти клиентов в работу пошёл только один, он окупил бы оценку девяти предыдущих), либо у вас сразу попросят какую-то сумму за несколько рабочих дней высококлассного специалиста, который сможет подготовить КП.

Если деньги на оценку просят сразу — это хороший знак. Можно быть уверенным в том, что оценку сделают ответственно. Если не просят — ставим галочку в графе «подозрительно» и ждём, что произойдёт дальше.

Вторая мысль. Если в процессе подготовки КП разработчик не задал ни одного вопроса по проектной документации, значит, скорее всего, он толком с ней не ознакомился. Максимум что сделал — это пробежал по-диагонали, прикинул, что что-то подобное он уже когда-то делал, и, не вдаваясь в детали, прикинул часы и стоимость.

И здесь произошёл ровно тот случай, когда студия взяла проектную документацию, две недели молчала, а затем выкатила КП на много миллионов, не попросив за свой труд ни рубля.

Продолжаем поиски. Кстати, если меня читает кто-то из студии, которая использует подходы к работе, схожие с моими, — стучитесь в личку, поделюсь вашим контактом с клиентом.

С 2023 года я фиксирую все сделки

Я завёл несколько табличек в экселе. По проектированию интерфейсов, созданию одностраничных сайтов, консультациям, продажам рекламы и так далее. И добавляю в них все состоявшиеся и несостоявшиеся сделки. Имена, контакты, даты, суть сделок, суммы, комментарии.

Всё началось с главы из Книги нормального фрилансера, в которой я рассказывал о том, что настоятельно рекомендую вести базу клиентов, хотя сам её никогда и не вёл. И вот для того, чтобы убедиться в правильности своей рекомендации, проверил её в деле.

Какие выводы?

Во-первых, это удобно. У меня теперь всегда есть под рукой история всех сделок за почти год в удобном формате.

Во-вторых, я увидел, что ко мне обращается гораздо больше людей, чем кажется. Например, я думал, что в 2023 пришло два клиента на проектирование интерфейсов. А их было семь. Я думал, что сделал пять одностраничных сайтов, а на самом деле десять. И так далее.

В-третьих, я теперь могу открыть такую табличку и быстро решить, кому напомнить о себе и попытаться предложить свои услуги в случае нехватки входящих заказов. Или возродить «подвисшие» сделки, которые я сам не очень активно вёл к продаже, потому что был чем-то занят.

В-четвёртых, таблички растут и растут, и я понимаю, что с каждой новой записью я увеличиваю свой актив под названием «клиентская база», ничего не теряя, не упуская и, видя этот рост, чувствуя уверенность в завтрашнем дне.

Если бы я вёл такие таблички в предыдущие 20 лет, сейчас мог бы получить не меньше десятка входящих заказов на проектирование интерфейсов, просто постучавшись к самым релевантным контактам. А без табличек пришлось бы проделать огромную ретроспективную работу по восстановлению контактов, договорённостей и результатов.

Поэтому совет считаю верным и очень эффективным. Фиксируйте все сделки. Особенно если только начали самостоятельно искать клиентов на фрилансе. Через десять лет скажете себе спасибо. А я говорю спасибо себе в январе 2023 года, когда я, наконец, собрался и последовал собственному совету.

Как, не выходя из машины, убедиться в том, что колёса смотрят прямо?

Хотел сначала рассказать, как понять, с какой стороны лючок бензобака, но мне кажется, что сегодня уже все и так об этом знают (рядом с иконкой на приборной панели есть стрелочка, которая указывает сторону, а если стрелочки нет, то смотрим на то, с какой стороны иконки нарисован «пистолет»).

Итак, к колёсам. На некоторых современных автомобилях есть специальный индикатор, который показывает, куда смотрят колёса. Но это большая редкость, поэтому вспоминаем дедовский способ:

1. Крутим руль до упора в какую-нибудь сторону;
2. Затем крутим руль до упора в противоположную сторону и считаем, за сколько оборотов нам это удалось сделать;
3. Делим это число на два и крутим руль обратно на получившийся результат.

Всё, колёса смотрят прямо.

При чём здесь фриланс? Так суббота же, давайте сегодня не про фриланс.

Как клиент понимает, что я не сделаю ему какую-нибудь дичь?

Когда я сам заказываю какую-нибудь сложную услугу (что это такое — можно почитать в главе Книги нормального фрилансера), исполнители делятся на две группы:

Первая (большая): «Мы не готовы работать без чёткого технического задания (ТЗ)! Возвращайтесь, когда оно появится!»

Вторая (крошечная): «У вас есть ТЗ? Нет? Давайте поможем вам его подготовить!»

Многие клиенты не в состоянии составить ТЗ, т.к. не разбираются в том, что заказывают. Описать идею и суть задачи в нескольких словах — это пожалуйста. Сделать что-то большее, учитывающее специфику профессии, — нет.

Например, я могу пойти в автосервис и попросить поменять мне масло в двигателе. А исполнитель в ответ запросит подробную инструкцию замены этого самого масла, включая работу с подъёмником. Допустим, я всё это ему предоставлю, а в итоге выяснится, что замена масла и не требовалась вовсе. Выяснится, что у меня накрылась одна из катушек, а я думал, что дело в масле. Чтобы такого не происходило, желательно специалисту сначала продиагностировать мою проблему. Либо сразу где-то подписаться, что он действует по заданию исполнителя и не несёт ответственности за его адекватность.

У клиента, пришедшего с хорошо проработанным ТЗ, может оказаться проблема, которую с помощью этого ТЗ не решить. Как с такой ситуацией справляюсь я (чаще всего речь идёт об услуге по проектированию интерфейсов)?

— Прежде чем браться за любую, даже самую маленькую, задачу, я общаюсь с клиентом голосом. Живой разговор синхронизирует лучше любой переписки;

— Прикидываю, сколько времени мне понадобится, чтобы «въехать» в задачу клиента. Если меньше трёх часов — делаю это бесплатно. Если больше — предлагаю оплатить моё время.

При этом я так и говорю: «У вас объёмный проект, я не смогу его изучить и оценить в короткий срок. Мне понадобится не меньше десяти часов и я не готов делать это бесплатно. К сожалению, я предлагаю вам заплатить денег за то, чтобы узнать, сколько стоит моя дальнейшая работа. Сделать оценку, не погружаясь в ваш проект, я не могу».

Но такое бывает редко. Один проект из пяти, не чаще.

— Предлагаю составить ТЗ, даже если клиент пришёл ко мне со своим и оно в порядке. И только так он поймёт, что я не сделаю ему какую-нибудь дичь. Ведь я своими словами пересказываю суть задачи. Как в школе: «Камелев, ты меня вообще слушал? Повтори своими словами, что я сейчас рассказывала?». Я повторял — и учитель понимал, что да, слушал.

Если приходят со 100-страничным ТЗ, нет смысла писать новые сто страниц своими словами. У меня собственный формат — функциональные требования — который может уместить даже описание ERP на пять ролей в пределах десяти-пятнадцати страниц.

— Мы обсуждаем мой документ, клиент оставляет комментарии, я их вношу, и он на 100% убеждается в том, что мы с ним на одной волне и я не буду делать что-то неожиданное.

Напоследок насчёт платности оценки (многих это возмущает). Я до 2017 года негативно относился к самой мысли о том, что за оценку можно брать деньги. «Что?! Брать деньги за то, чтобы узнать, сколько стоит работа?! Что за бред?». Но позже, с опытом и взрослением, мои взгляды поменялись:

— Любой труд должен оплачиваться;
— Клиент, который выбирает подрядчика в пределах значительного бюджета (например, 10 миллионов), не побоится заплатить крошечную часть исполнителю, который честно признается, что для оценки понадобится несколько дней работы умных спецов. Что без них это будет не оценка, а гадание с заложенными рисками в несколько стоимостей проекта;
— К оплаченной работе больше доверия. Один исполнитель пообщался со мной часик, поработал бесплатно в течение двух недель (а может и не поработал) и сказал, что проект стоит 7 миллионов рублей. А второй поработал 10 часов за 50к (из которых пять часов ушли на переговоры), спросил о нюансах, подкорректировал первоначальное ТЗ и сказал, что проект стоит 13 миллионов рублей. И не только сказал, а всё подробно расписал. Вот второму доверяешь больше, чем первому, даже когда цена кусается.

Как я сливал деньги на дорогие подарки

Понятие «дорого» — относительное. В моей жизни был затяжной период, когда я сколько зарабатывал — столько и тратил, при этом ничем не компенсируя такое поведение (например, я мог бы вместо этого накапливать капитал или работать над чем-то, что принесёт дивиденды в будущем).

И именно тогда мне важно было дарить близким людям дорогие подарки. С одной стороны, хотелось сделать человеку невероятно приятно, подарив что-то что он сам себе не мог позволить. С другой — показать, что я могу, что я молодец. «Дорого» — это понятие относительное. Будем считать, что в моём случае — это половина зарабатываемых за месяц денег. Среди подарков были ноутбуки, телефоны, планшеты, вот это всё.

И вот близкие люди радовались, я радовался, но это был слив денег. Взрослея, я увидел, что близким гораздо важнее не внезапные подарки, а надёжное плечо рядом. Пускай человек ничего никому не дарит, но зато в случае беды к нему можно обратиться за помощью, потому что он финансово устойчив.

Можно сегодня потратить деньги на дорогой подарок, а завтра остаться без денег на врача для родителей или обед для друга. А можно, наоборот, никому ничего не покупать, зато спокойно и уверенно смотреть в завтрашний день-неделю-месяц-год и распространять это спокойствие на окружающих. В общем, всё снова упирается в финансовую грамотность. Если ещё не читали об этом главу из Книги нормального фрилансера, то вот, пожалуйста, читайте.

Вчера выложил на Хабр статью, которая попала в топ-10 лучшего за неделю и набрала уже больше 25к просмотров

Как это получилось и что мне дало? Рассказываю. С каждым месяцем я всё лучше понимаю, как писать тексты, которые будут не только полезны, но и интересны читателям. Каким образом? У меня есть базовое понимание в проектировании интерфейсов (тексты — это тоже интерфейсы) и в компоновке постов, а дальше я просто улучшаю его с помощью ежедневной практики и тестов. Да, с голой теорией у меня бы ничего не получилось. За последний год я написал более двух миллионов символов в виде постов — и эта практика и усидчивость и приносят результаты.

Итак, как моя статья попала в топ Хабра?

1. Я пробежался по последним постам в этом Телеграм-канале и выбрал один из самых залайканных аудиторией;
2. Опубликовал этот пост на Хабре в половину четвёртого утра, чтобы получить максимальное внимание тех, кто проснётся утром и посвятит специально выделенное время на вдумчивое чтение лент (а ещё ночью мало кто публикуется, поэтому ниже конкуренция за внимание с другими постами; и да, это всё мои предположения, а не факты);
3. Не ссылался в посте на свой канал. И вообще никуда не ссылался, чтобы это не казалось рекламой.

С утра меня ждало автоматическое письмо от Хабра о том, что статья попала в топ-5 лучшего за сутки. А на следующее утро, что публикация в топ-10 лучшего за неделю.

Что мне это дало?

Только охваты. Я предполагал, что из 25к человек, увидевших статью, многие пойдут ко мне в профиль на Хабре, увидят ссылки на представительства (в том числе и на Телеграм-канал) и присоединятся. Но нет. Думаю, что получил не больше одного подписчика на 10 000 охвата.

Для сравнения. Любой заминусованный пост с 1000 охвата на том же Хабре, но с прямой ссылкой на канал прямо в статье (как раз за это обычно и минусуют) даёт в среднем три-пять подписчиков.

Кстати, той же ночью я опубликовал тот же пост и на VC. В личный блог. И не просил никого из друзей поддержать меня лайком. Он получил 7.4К показов и 1.4К открытий. Тоже неплохо.

Эксперимент на этом не заканчиваю. Потому что гугловские исследователи считают, что человек принимает решение о сделке в среднем после 10-12 касаний. А значит, мне надо 10-12 раз попасть в топ, если я рассчитываю на получение подписчиков через ссылку в профиле. Почему бы и нет?

Чем мои нынешние посты отличаются от прошлых?

Я всегда старался писать по такой схеме:

— Писать о том, в чём я сам неплохо разбираюсь;
— Писать о личном опыте, а не чужом;
— Писать так, чтобы это было нескучно читать.

Последний пункт выделен жирным, потому что именно над ним я сейчас и работаю. Предыдущие два и так использовал, даже не задумываясь над этим. Просто потому что это самый безопасный подход. Какие ко мне могут быть вопросы, когда я рассказываю о том, что сам сделал, а не учу, как «надо» делать?

В комментариях покажу картинку с распределением оценок за статью на Хабре (сколько плюсов, сколько минусов и за что именно минусовали).

Я живу на двадцатом этаже…

…и часто заказываю пиццу на ужин. Так часто, что меня уже, наверное, можно считать черепашкой-ниндзя.

Курьер звонит в домофон, я открываю парадную и после этого у меня есть 50 секунд, прежде чем в дверь раздастся звонок. Как раз за это время курьер поднимается на лифте на мой этаж.

В течение этих пятидесяти секунд я обычно прислоняюсь спиной к стене прихожей так, чтобы пятки, затылок и лопатки касались её поверхности, и считаю про себя. Таким образом почти каждый раз, заказывая пиццу, я чуть-чуть исправляю свою ужасную осанку. По ощущениям эти пятьдесят секунд длятся гораздо дольше. Получается, когда я занимаюсь физическим трудом, время для меня течёт медленнее.

Но иногда бывает так, что звонок в домофон отвлекает меня от какой-то задачи за компьютером. Например, я пишу пост, звонит курьер, я подрываюсь, открываю дверь парадной, а затем возвращаюсь за клавиатуру. Мне хватает времени на одно-два предложения — и раздаётся звонок в дверь. Создаётся ощущение, что курьер добирается до моего этажа секунд за 20-30.

Получается, когда я занят умственным трудом, время, наоборот, летит быстрее. А у вас как?

UPD
Перечитал пост. И мне очевидно, что время летит быстрее, когда я занят чем-то интересным и вовлекающим. И медленнее, когда я очень ожидаю какого-то события. Тут даже не нужно спрашивать, так ли это у вас. Ясен пень, что так :)

Как я объясняю клиенту, что он неправ

Очень просто: работаю не над разрушением его позиции, а над повышением доверия к своей.

Например, заказчик хочет нарисовать в прототипе какую-то дичь.

1. Сначала я мягко скажу, что, возможно, это плохая идея и объясню почему;

2. Если это его не убедит, при нём, прямо во время созвона, нарисую его вариант, чтобы мы оба убедились в том, что это выглядит не очень. Тут архиважно постараться реализовать в его варианте всё лучшее, а не подчёркивать неудачные моменты. А ещё важно делать это именно у него на глазах, чтобы делиться мгновенной обратной связью и чтобы он мог сам понять, какие вещи легко проверить, а какие нет с точки зрения трудозатрат;

3. Если я искренне старался поработать над видением клиента, может произойти одна из двух вещей:

— Клиент оценит мою готовность поработать над его идеей, наглядно убедится в её нежизнеспособности и дальше будет больше прислушиваться к моим мнениям;

— Вариант клиента окажется вовсе не таким плохим, как мне казалось. Мой арсенал проектировщика пополнится ещё одним удачным приёмом. Клиент будет доволен, что я не сопротивляюсь его идеям, и станет относиться ко мне ещё более лояльно.

Чем более лояльно и доверительно ко мне относится клиент, тем легче будет прислушиваться к моему мнению в дальнейшей работе.

Чем больше у нас будет таких касаний, тем лучше я буду понимать, на что именно он обращает внимание и какие аргументы для него действительно важны.

В итоге любое моё объяснение, почему клиент неправ, будет восприниматься им как попытка помочь общему делу, а не отстоять собственную позицию.

Небольшой трюк, который позволил мне выполнять ту же работу в несколько раз быстрее

Сначала расскажу, как было. Перед началом работы я просил у клиента референсы. Ссылки на пару-тройку проектов, которые ему нравились. Иногда уточнял, что именно ему приглянулось в этих проектах. И отталкивался от этого.

Например, клиенту нравится карточка товара в каталоге на сайте конкурента и он присылает ссылку на неё. Чем навится? Лаконичностью и кнопкой добавления в избранное. Ок.

Я рисовал карточку, очень похожую на референтную, и получал в ответ пачку комментариев. «Всё не так! Вот здесь выглядит не очень. Вот тут было бы неплохо попробовать что-то другое. Тут слишком мало места оставили. Тут слишком много». И так далее и тому подобное.

— Но я же нарисовал вариант буквально как в референсе, который вам нравится!

Что-то тут было не так. И в какой-то момент меня осенило!

А теперь рассказываю, как стало. Клиент присылает ссылки на пару референсов. И я не открываю их до тех пор, пока мы не окажемся в онлайн-созвоне. Там вместе смотрим на них — и я начинаю задавать вопросы. Мне, по сути, всё равно, как выглядят референсы и из каких элементов состоят. Мне важно понять только одно — почему клиент выбрал именно их. Разобравшись с логикой его оценки, я, во-первых, могу работать уже без референсов, а, во-вторых, как-то эту самую логику скорректировать в процессе. Но уж точно не заниматься угадыванием, предлагая разные варианты.

— Мне нравится, как здесь оформили карточку товара.
— Что конкретно?
— Ну смотрите, большая картинка, мало текста с описанием.
— Вам именно нравится размер картинки? То, что она занимает много места на экране?
— Ой, нет, конечно, нет. Я имел в виду не размер картинки, а то, каким крупным планом сфотографирован товар. Наши клиенты любят прям разглядывать текстуру поверхности — а тут это можно сделать.

И вот я уже не нарисую картинку большого размера, которая потенциально не понравится клиенту, а учту желание посетителя поразглядывать текстуры поверхностей и придумаю для этого более удачный интерфейс.

—
В итоге я перестал заниматься гаданиями и отправлять разные варианты на выбор и начал больше времени посвящать «синхронизации» с клиентом.

— Уточняю значения некоторых слов и стараюсь говорить на языке, понятном заказчику;
— Трачу время не на переборы вариантов в макетах, а на общение (15-минутный диалог может сэкономить часы работы);
— В начале работы общаюсь очень часто, а к концу в этом обычно нет необходимости, потому что я уже хорошо понимаю, как мыслит клиент и что ему нужно.

Стоит ли говорить, что достичь такой синхронизации с помощью переписок у меня никогда не получалось? Получасовой разговор, да ещё и в режиме демонстрации экрана, когда мы вместе смотрим на чужой проект или когда я показываю, как вношу изменения в наш, экономит часы молчаливой работы, переборов вариантов и угадываний.

Одну и ту же задачу в проектировании можно решить миллионом способов. Я предпочитаю сразу сузить эти способы до одного — того, который субъективно понравится клиенту. И это в разы уменьшает время на правки и повышает скорость сдачи проектов.

Какую пользу я получил от осознанных сновидений

Для начала о том, что это такое. Это феномен, когда спящий человек во сне вдруг осознаёт, что спит, и начинает совершать осознанные действия. Например, снится мне, как я гуляю по городу. Вдруг, осознаю, что это сон, и начинаю летать над крышами или рисовать на стенах радугой, вот это всё.

Огромное поле для эзотерики и фантазий. Я сам научился видеть осознанные сны в юности под влиянием не очень хороших людей, которые внушили, что они открывают море возможностей.

Таких как: выход из физического тела, получение новых знаний, закрепление уже имеющихся навыков, доступ к памяти из прошлых жизней, совместные осознанные сны (это меня привлекало больше всего).

Я как человек системный и усидчивый честно попытался достичь высот в этом искусстве, но стоит ли говорить, что у меня почти ничего не получилось? Почему почти? Потому что я действительно довольно быстро научился осознавать себя во сне. Просто это не дало ничего, кроме возможности повосхищаться картинами, которые рисовало моё воображение, да поделать всякие глупости.

Убедившись самостоятельно в том, что эзотерическая составляющая — это, пожалуй, развод для доверчивых людей, а прикладная несёт не особо много смысла, я успокоился и расслабился. Но вскоре понял, что на самом деле этот навык дал мне огромную пользу.

Дело в том, что один из этапов обучения осознанным сновидениям — это ведение дневника снов. Он развивает способность без усилий вспоминать то, что мне снилось прошлой ночью.

До этого я иногда мог проснуться в плохом настроении и весь день ходить хмурым и угрюмым, сам не понимая, что со мной происходит. А после того, как научился запоминать сны — уже с утра понимал, что мне приснилась какая-то мерзкая дичь, которая очень здорово била по эмоциям. Я говорил себе, что это просто сон и что в реальности мне ничего не грозит — и настроение улучшалось.

И в итоге я получил пользу от осознанных сновидений — в моей жизни стало меньше дней с плохим настроением из-за ужасных снов, которых я даже не помнил. А сами осознанные сновидения — это клёвый опыт с «вау-эффектом» поначалу, а затем, когда понимаешь, что никаких чудес в этом нет…

Это как шлем виртуальной реальности. После покупки я был в полном восторге и с упоением проходил Half Life Alyx. А через два-три месяца он перекочевал на полку и до сих пор там пылится.

«Это он прислал мне документ в два часа ночи!»

Когда в разговоре участвует несколько собеседников, невежливо говорить о присутствующих в третьем лице. Используя третье лицо, мы как бы подразумеваем, что оно не участвует в разговоре.

Невежливо: «Елена подложила мне свинью». Здесь мы говорим о Елене в третьем лице. Лучше обратиться к Елене напрямую: «Елена, вы же помните, что недавно подложили мне свинью?»

Иногда я вынужден сказать о присутствующем в третьем лице. Такую ситуацию может сгладить отсутствие местоимений в реплике. Невежливо: «Это он прислал мне документ в два часа ночи!» Допустимо: «Алексей прислал мне документ в два часа ночи».

Вроде, мелочь, а навык ведения переговоров как раз и состоит из таких простых мелочей. И чем больше я их усваиваю и довожу до автоматизма, тем приятнее со мной общаться.

Смотрите, сколько я уже написал постов по некоторым из них:

— Не делать вид, что знаешь ответ на вопрос
— Не перебивать собеседников
— Брать ответственность на себя
— Обращаться на вы
— Улыбаться во время общения
— Не использовать слово «согласитесь»
— Не критиковать публично
— Говорить на языке собеседника
— Не записывать переговоры без предупреждения
— Помнить о цели разговора
— Расставаясь, не хлопать дверью
— Не спорить со своей командой при посторонних

И это далеко не всё. По отдельности эти навыки не делают большой погоды, но чем больше их накапливается, тем спокойнее, проще и эффективнее удаётся договариваться с людьми.

Почему я почти никогда не начинаю проектирование (или дизайн) сайта с главной страницы

По той же причине, по которой не начинаю писать книгу с придумывания обложки, статью с заголовка, создавать курс с введения и рассказа об авторе, рисовать портрет человека с глаз.

Главная страница сайта — это вишенка на торте. Я буду точно знать, из чего она состоит и как работает после того, как будут спроектированы все остальные разделы.

Проектирую я снизу-вверх. Возьмём, например, интернет-магазин. Сначала карточка товара, затем список товаров в каталоге, затем список разделов каталога. Потом корзина и прочие важные разделы. И в самом конце — главная страница.

В противном случае мне бы приходилось вносить дополнительные правки каждый раз, когда я проваливаюсь на уровень глубже и понимаю, что там другой состав параметров, нежели я предполагал.

Например, спроектировал список товаров, а затем страницу отдельного товара. И на последней понял, что некоторые параметры, о которых я сразу не подумал, необходимо показать и в списке. Поэтому приходится возвращаться к предыдущему макету и вносить правки. Если же проектировать снизу-вверх, такого почти не происходит.

Чего уж говорить о главной странице! Посвятив ей несколько часов в самом начале, я могу быть уверен в том, что это время выкинуто в мусорное ведро. Потому что через неделю я вернусь к ней с полным пониманием проекта и всё нафиг переделаю (разумеется, я сейчас не говорю об одностраничных сайтах и сервисах из одного экрана).

Когда ко мне приходит новый клиент и говорит «Давайте прикинем главную страницу» (кстати, такого давненько не было), я отвечаю: «Давайте взглянем на статистику». Это если пришли за редизайном существующего проекта. И почти всегда мы видим, что на главную заходит не больше 10-15% посетителей. Остальные начинают знакомство с каких-либо других разделов. Например, с карточек товаров или статей, хорошо проиндексированных поисковыми системами.

«Зачем начинать с главной, если на неё смотрят 15% ваших клиентов?» — спрашиваю я. «Давайте лучше нарисуем карточку товара. На ней всё те же навигация и дизайн-решение, а ещё мы будем уверены в том, что её не придётся перерисовывать, когда будет спроектирован весь сайт. А значит сэкономим время и ресурсы».

«Ого!» — говорят клиенты, — «Круто! Конечно, давайте так и сделаем. Странно, что вы первый, кто предложил нам такой подход».

Почему я никогда не списывал в школе и университете

Начал было расписывать про безопасность такого подхода, про ответственность за свои действия, про репутацию, осознание того, что мне нужно было образование, а не отметки.

Но, камон, мне было слишком мало лет для таких рассуждений! Однако, если я был не готов к проверочной работе, то смирялся с этим, сдавал пустой листок, получал двойку и закрывал пробелы в знаниях уже позже. Даже если рядом сидел кто-то, кто разрешал с него списать. Кстати, списывать с себя окружающим я разрешал без вопросов.

Поэтому, и правда, почему?

¯\_(ツ)_/¯

Как я проектирую нормальные формы

На скриншоте — форма в одном из моих прошлогодних прототипов. Циферками подсвечиваются кликабельные элементы (я всё перелинковываю, чтобы клиент мог примерить на себя роль посетителя будущего сайта). Даже если в форме есть всего одно поле, процесс у меня всегда примерно один и тот же.

— Задаюсь вопросами откуда берутся данные, куда они попадают и в каком виде будут храниться и отображаться после завершения работы с формой. Например, если я проектирую форму регистрации, то обязательно прикидываю структуру приветственного письма (ведь оно формируется после отправки данных и частично использует их: «Здравствуйте, %Юзернейм%»);
— Показываю, что произойдёт после отправки формы (в том числе предусматриваю «крутилки», которые показывают, что что-то происходит при медленном коннекте);
— Показываю, где отображать сообщение об ошибке, если что-то пойдёт не так;
— Описываю в функциональной спецификации (ФС), какие типы ошибок возникают для конкретной формы.

Например, вот типы ошибок для формы на скриншоте (пишу уже даже не задумываясь, это не особо сложная наука):
— Ошибка по тайм-ауту;
— Неверный формат данных в текстовом поле;
— Текстовое поле не заполнено.

Реже я расписываю в ФС формат данных и ограничение по количеству вводимых в поля символов.

Почти всегда в ФС приходится писать для формы какие-нибудь тезисы уже после того, как все основные моменты описаны. Вот, например, тезис для формы на скриншоте: «Импортируются только те монетки, которых до этого не было в вочлисте, дубликаты игнорируются».

Помимо коротких описаний, в ФС также есть раздел «Общие принципы работы форм» на несколько тысяч символов с ответами на десятки мелких вопросов (в каком поле фокус по умолчанию, как выглядит валидация полей, нужны ли крестики для очистки данных, нужно ли блокировать кнопку после нажатия и т.д).

Если десять лет назад я продавал ФС к каждому десятому проекту, то сегодня к каждому первому. Мне очень легко объяснить клиенту, почему без неё проект будет разрабатываться дольше и дороже.

Как писать клиентам так, чтобы они не «отваливались». Практика

5 октября я опубликовал в этом канале запрос на поиск исполнителя. На скриншоте — отклик. А в заголовке — название главы из книги нормального фрилансера. Хочу указать на ошибки в отклике, а также показать, как написал бы я сам.

Ошибки:
— Может быть непонятно, откуда отклик. У меня несколько каналов, в них много постов, в том числе и с запросами на поиск исполнителя. Желательно, откликаясь, сразу давать ссылку, на что откликаешься;
— Информации больше, чем нужно для принятия решения. Я бы перед отправкой перечитал сообщение и удалил всё лишнее. Например, пассаж про прекращение сотрудничества с США. Чтобы текст издалека не показался клиенту из-за объёма крепким орешком, который лучше отложить на потом;
— Нет ответа на вопрос, что клиенту делать, если он согласен с предложением.

Моя версия:
«Здравствуйте, меня зовут Григорий, откликаюсь на ваш запрос в Канале нормального фрилансера. У меня есть небольшая команда — и мы готовы помочь вашему клиенту в разработке. Предлагаю сразу назначить переговоры в гугл.мит минут на 15: познакомиться друг с другом и с проектом. Например, в четверг, 19 октября, в 15:00 МСК. Как вам такой вариант?».

Комментарии:
— В моём варианте я не говорю, что был бы рад возможности сотрудничества, а предлагаю познакомиться;
— Не уточняю актуальность задачи. Если что, клиент просто напишет что-то вроде: «Спасибо, но задача уже не актуальна»;
— Не рассказываю ни о наборе компетенций, ни об опыте разработки, потому что не уверен в том, что клиент в этом разбирается и что это не будет лишней информацией. Единственно, я бы сослался на пример реализованного интернет-магазина, если бы он у меня был был.
— Моё сообщение оканчивается вопросом, поэтому проигнорировать его было бы невежливо.

Во время переговоров я бы уже рассказывал о компетенциях, показал портфолио в удобном формате, поотвечал на вопросы. И даже если бы ни о чём не договорились, то моя копилка потенциальных клиентов пополнилась бы ещё одним контактом.

Проверяю на деле рекомендацию о том, что нужно писать проще

Что значит проще? Использовать только те слова, которые понятны ученику пятого класса. Где-то выкручиваться с помощью синонимов (слов с похожим значением), где-то расшифровывать сложные слова в скобочках (например, как я это сделал для слова «синоним»). Если удастся писать ещё проще, на уровне первоклашек — то вообще идеально.

Информацию о разных классах я получил из американского ютуба. От авторов с сотнями миллионов просмотров. В первую очередь это Jenny Hoyos (материалы для уровня пятого класса) и Mr Beast (уровень первого класса). Ещё стоит упомянуть такого автора как Alex Hormozi. Все они анализируют свои тексты на наличие сложных слов в онлайн-сервисах, и правят их до тех пор, пока те не станут понятны школьникам.

Я пока что не дошёл до такого уровня, чтобы искоренять все сложные слова в своих постах, но стал осознанно писать проще. Как в Телеграме, так и в публикациях на Хабре и VC. У меня нет каких-то точных данных, на которые я мог бы уверенно опереться, но умозрительно охваты действительно вырастают. Реакции тоже. Я явно привлекаю внимание большего числа читателей, чем раньше.

Почему так? Мне кажется, что пара-тройка сложных слов, которые по какой-то волшебной причине не были знакомы тем или иным людям, могут отпугнуть их от чтения. При этом простые слова не отпугивают людей с большим словарным запасом. И получается, что от упрощения одна польза.

Кстати, вчера во время прогулки с другом впервые услышал слово пангасиус. Хотя всю жизнь увлекался биологией и в рыбах тоже неплохо разбираюсь. И вот я, увидев это слово в чьём-нибудь тексте до вчерашнего дня, не понял бы, что речь идёт о рыбе из семейства сомообразных.

Возможно и мои читатели, натыкаясь на «прототипы», «диафрагмы» и «акты сверки» без разъяснений, грустили и листали дальше.

А ещё я думаю, что структура повествования всё-таки будет поважнее словарного запаса. Если писать проще, но логически запутанно, то толку от этого мало.

Если бы я мог отправить какие-то советы самому себе в прошлое…

Этот пост я опубликовал в сообществе проектировщиков интерфейсов (UX-дизайнеров) аж в 2016 году. Публикую без изменений:

«Мои рекомендации самому себе, которые хотел бы переслать в прошлое, лет на шесть назад. На экспертность не претендую, делюсь личным опытом работы на фрилансе.

— Чтобы повысить качество своей услуги, отстроиться от конкурентов и увеличить поток входящих заказов, стоит однажды самому оказаться на месте заказчика и посмотреть его глазами на то безобразие, которое творится на нашем рынке. Попробуйте заказать себе корпоративный сайт или блог и прочувствовать на себе мысль: «А зачем мне проектировщик? Здесь и так всё понятно!»;

— Не надо сравнивать себя с профессионалами, работающими в Яндексах, Контактах, Авито и прочих гигантах. Также не надо сравнивать себя с основателями и руководителями студий. К ним никогда не придут те клиенты, с которыми вы работаете на фрилансе. У вас своя доля рынка, у неё свои потребности. Большие люди, перечисленные выше, эти потребности удовлетворять не будут. Хотите быть программистом за 500 000 в месяц в команде Контакта? Вперёд на должность помощника левой руки джуниора и стройте карьеру. Хотите зарабатывать столько же на фрилансе? Начинайте работать над персональным брендом и сервисом;

— Ваша оперативность, фиксированное ценообразование и дисциплинированность ценятся значительно выше сотен проектов в портфолио и опыта работы с государством и крупняками. Хорошие специалисты видны издалека даже в начале своего пути;

— В проектировании на фрилансе сервис и прозрачное ценообразование приносит больше прибыли, чем качество интерфейсов (которое само по себе субъективно на этом этапе);

— Если вы задавите клиента своей экспертностью, он разойдётся с вами после завершения работы, и вы так и не узнаете, как повлияли ваши труды на конверсии и прибыли. Тем более что он всё равно сделает так, как считает нужным. Но если вы сделаете клиента довольным, сдав работу в срок и в том виде, в котором она ему понравится, то у вас будет шанс поучаствовать в дальнейшей жизни проекта и проявить свои амбиции;

— Упакуйте свою услугу таким образом, чтобы она была понятна вашей целевой аудитории. «UX-проектирование» и «Юзабилити аудита» — это настолько абстрактные процессы, что даже наши коллеги по-разному представляют себе их результаты. Продавайте более понятные и конкретные «Прототипы мобильных приложений» или «Рекомендации по исправлению ошибок на сайтах»;

— Если вы что-то сделали, то важно мнение вашего клиента о качестве работы, а не мнение ваших коллег и конкурентов. Страшная на ваш или чей-то ещё взгляд работа в портфолио или методология проектирования, идущая наперекор устоявшимся стандартам, не характеризует вас как плохого специалиста, если к вам выстроилась очередь из клиентов за аналогичными проектами».

——

Прошло почти восемь лет и я по-прежнему согласен со всеми пунктами. Единственно, сегодня задаюсь вопросом: почему обращаюсь к себе в прошлом на вы? :)))

Чем отличается авторизация от аутентификации?

Аутентификация — это процесс проверки подлинности пользователя (слово произошло от греческого «реальный, подлинный»). Система должна убедиться в том, что он является тем, за кого себя выдаёт. Для этого система может попросить ввести логин-пароль, биометрические данные, код из смски и так далее.

Когда пользователь жмёт на кнопочку «Войти» — он запускает процесс аутентификации. Или, другими словами, пытается аутентифицироваться в системе.

Авторизация (от английского «разрешение; уполномочивание») — это процесс предоставления прав доступа пользователя к тем или иным ресурсам или функциям. Он проводится после успешной аутентификации. Грубо говоря, после того, как пользователь вошёл в систему, его необходимо авторизовать в рамках той или иной роли. Например, в качестве покупателя. Или модератора. Или администратора. Или того, другого и третьего сразу.

Итого:
1. Пользователь входит в свой аккаунт — пользователь аутентифицируется;
2. Пользователь может управлять своим каналом в Телеграме — пользователь авторизован в роли администратора канала.

Большинство людей в моём окружении называют аутентификацию авторизацией. Даже в технической документации я иногда могу использовать именно термин «авторизация», предполагая, что читателю он будет более понятен (хотя и неверно трактован). Самый безопасный вариант для простых обывателей — называть аутентификацию входом.

Конкуренцию в ошибочном использовании этих двух терминов может составить, пожалуй, только пара UI-кит и дизайн-система.

Для кого я на самом деле проектирую интерфейсы?

Для разработчиков. Моя задача проектировщика — пообщаться с клиентом, собрать его идеи и бизнес-запросы, а затем превратить в макеты и сопроводительную документацию для разработчиков. Если я плохо её оформлю или что-то забуду детализировать — пострадают именно они. Им придётся самим решать, как должен работать тот или иной участок системы.

Часто ли дизайнеры или проектировщики получают обратную связь от тех, кто дальше работает с документацией и макетами? Вопрос открытый. Когда я сам сдаю работу, то не ленюсь и через клиента спрашиваю, что думают разрабы о моих макетах и документации. Ответ обычно такой: «Мы не знаем. Раньше не сталкивались с такой подробной постановкой задачи. Если вопросы и возникали, то решали их сами».

Получается, что проектировщики и дизайнеры готовят задачу для разработчиков, но обычно не интересуются, насколько последним было удобно работать с макетами и документацией. А разработчики не могут адресовать вопросы по проекту дизайнерам и проектировщикам, потому что… Если честно, не понимаю, почему. Но ко мне за 300+ проектов вопросы от разработчиков прилетали всего два раза.

Для клиентов. Если я не сделаю довольным клиента, то результат моей работы может никогда и не добраться до разработчиков. Обычно клиент не в состоянии оценить мои навыки проектирования интерфейсов, зато сразу может оценить уровень сервиса и ответственность. Именно за счёт них я и повышаю уровень доверия к профессиональной составляющей своих услуг. Это первый этап.

Второй этап — сделать так, чтобы разработчики, которым легко и приятно работать с моей проектной документацией, быстрее и эффективнее справлялись бы со своей задачей. Ведь в конечном итоге именно за это клиент и платит проектировщику: сократить издержки на разработку за счёт уменьшения неопределённостей. Если это получилось — клиент будет довольным ещё раз уже через много месяцев после того, как получил от меня проектную документацию и передал своей команде.

Для пользователей. Несмотря на то, что это основа моей профессии, я придаю ей наименьшее значение. Если я не сумею сделать клиента довольным — никаких пользователей не будет. Если я не сумею предоставить грамотную проектную документацию для разработчиков — пользователи увидят не совсем тот интерфейс, который я задумывал.

От результата моей работы больше зависит то, с какой скоростью будет выпущен продукт. И вот когда он будет выпущен — тогда и появится первая обратная связь от пользователей. Если я сделал довольным клиента и разработчиков, то в этот момент я всё ещё буду рядом и смогу получить доступ к статистике и предложить внести изменения в получившийся результат, чтобы сделать его лучше.

Десять-двадцать таких проектов — и каждый следующий будет уже вполне сносным для всех участников процесса. В период обучения знаю только один реальный способ проектировать интерфейсы более-менее сносно: смотреть на уже работающие проекты (которым не меньше двух-трёх лет) и заимствовать их интерфейсы, стараясь понять, почему были использованы те или иные решения.

Итого. Для кого я проектирую интерфейсы?

В первую очередь — для разработчиков. Людей, которые будут брать мою проектную документацию и на её основе выполнять свою работу. От того, что я им предоставлю, будет зависеть качество и скорость разработки.

Во вторую очередь — для клиентов. Несмотря на то, что от них зависит оплата и дальнейшие обращения, клиенты всё-таки будут слушать, что разработчики скажут о результате моей работы. И если они скажут, что давно не работали с такой крутой проектной документацией, то лояльность клиента почти гарантирована.

В третью очередь — для пользователей. Они никогда не увидят мою проектную документацию и будут взаимодействовать с уже готовым проектом, который является результатом коллективного труда. И этот результат будет тем больше похож на задуманный мной изначально, чем больше будут довольны разработчики и клиент.