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

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

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

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

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

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

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

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

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

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

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

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

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

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

¯\_(ツ)_/¯

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

——

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подождите, сейчас я вас переключу на другого сотрудника…

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

Этот другой снова задаёт те же вопросы — и ты уже общаешься с ним раздражённый и разочарованный.

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

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

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

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

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

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

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

«Утро вечера мудренее», — подумал поздним вечером фрилансер с горящими сроками. И уселся за компьютерные игры. Утра дожидаться.

Эта заметка принесла мне больше пяти заявок от потенциальных клиентов летом 2015 года

Я опубликовал её в сообществе проектировщиков, а через несколько часов в личку начали писать клиенты. Двое пошли в работу. Показываю заметку без изменений:

—

Почасовая или попроектная оценка при работе на фрилансе? Поделюсь своим опытом. Сразу оговорюсь, что я UX-дизайнер в чистом виде. То есть, со шрифтами не играюсь и Фотошопом не пользуюсь.

В своё время уйдя на вольные хлеба, я назначил стоимость своего часа для клиентов. 1 000 рублей. Это было больше, чем в среднем по рынку, но в целом со мной не отказывались работать, ибо сарафанное радио. В портфолио было около сотни прототипов. Особенно интересовались студии. Всё было прозрачно и красиво.

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

Сюда входили и переговоры, и пара итераций с комментариями. Итого: 10-15к за работу, которую легко можно было бы продать под ключ за 50-70к. Увеличение стоимости часа до 4−5 тысяч рублей приводило к тому, что с тобой отказывались работать, ибо цена превышает среднерыночную в разы. Резюме по часам:

— За почасовую оплату лучше учиться на клиентах, ибо точность оценки рисков и объёмов работ увеличится только с увеличением работ в портфолио;
— На практике, делая работу за 10-15 часов многие спокойно называют 20-30 часов просто потому, что работа реально выглядит на эти 40-50 тысяч. Причём, тут до абсурда доходит. У меня были случаи, когда я платил дизайнеру по часам так, словно он работал по 15 часов в сутки в течение трёх дней. Было понятно, что на работу уходило гораздо меньше;
— Когда вы называете свою цену за час, её всегда будут сравнивать со средней ценой по рынку. И даже если вы очень хороши в своём деле, без рекомендаций с вами никто работать не будет, если речь идёт о стоимости 5+ тысяч рублей в час.

Теперь про попроектную оценку. Я перешёл на неё, как только понял, что меньше 3к в час с моими опытом и скоростью работы запрашивать не стоит. Теперь интересное. По типовым проектам на рынке тоже есть своя средняя стоимость. У фрилансеров одна, у студий другая, чуть побольше. Если у проектировщика не хватает опыта и паттернов, он будет называть среднюю стоимость по рынку, браться за эту работу и, собирая шишки и затягивая процесс из-за потока комментариев, приближать стоимость своего часа к той самой тысяче рублей. А если это уже десятый подобный проект, то он, наоборот сделает 50-тысячный проект сильно быстрее, чем за 10 часов, используя наработки и предвосхищая комментарии, таким образом приближая стоимость своего часа к отметке 5+ тысяч рублей. И вот вторые, которые опытные, даже могут позволить себе немного демпинговать, называя 40 вместо 50 и при этом за час зарабатывая в несколько раз больше, чем те, которые называют 50-60. Резюме по попроектной оценке:

— Нужен определённый опыт, чтобы не ошибаться в объёмах работ и потенциальных итерациях с комментариями (под опытом подразумевается именно похожий проект, сделанный и выпущенный в прошлом);
— Нужен доступ к клиенту. Работая на субподряде и общаясь только с менеджером проекта, вы не получите ответов на некоторые вопросы, влияющие на ценообразование. Редкие исключения есть. В качестве примеров могу привести Анну Третьякову из Елегиона или Елену Божек из московской компании Айпартнер;
— Из приятного: предоплата. Вы получаете часть денег перед началом работы. При работе по часам обычно платят по факту;
— Работая по рекомендациям, вы можете называть стоимости работ выше среднерыночных, что увеличивает стоимость вашего часа ещё больше. Сюда же, наверное, стоит добавить, что пользоваться ИП (или любой другой формой собственности), работая с ценниками больше 50к, удобнее и белее и пушистее.

Смотрю на список тем для публикаций в этом канале и вздыхаю…

«Различия между UI-китом и дизайн-системой» — тут лучше показывать, а не описывать текстом, поэтому пропускаю. Лучше в статье с картинками раскрою. Или в видеоролике.

«Разработчик: не хочу обучать дизайнера делать его работу!» — история слишком личного характера и без каких-либо однозначных выводов, пропускаю. Как-нибудь в другой раз поделюсь.

«Рассказать об Alex Hormozi» — я так и не проверил факты. Действительно ли это долларовый мультимиллионер, который классно делится опытом на Ютубе, или инфоцыган. А пока не проверил — лучше не рассказывать о нём.

«Что отличает мечту от цели?» — что это вообще делает в моём списке тем? :)

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

«Как я пишу функциональные спецификации» — половина читателей уснёт.

«Как я выбираю базовое разрешение макетов перед началом проектирования» — тут уснёт вторая половина читателей.

Ааа!!111

20% работы приносят 80% результата

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

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

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

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

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

—
В комментариях к предыдущему посту почему-то просите рассказать о функциональных спецификациях. Можете объяснить, в чём идея? В моём окружении техническую документацию к прототипам и дизайнам пишут… никто! Это работа, требующая усидчивости, въедливости, желания развиваться в профессии и постоянно править собственный результат. Несмотря на то, что ФС стоит столько же, сколько и сам прототип, я не знаю почти никого, кто выбрал бы путь «сделать прототип и описать его в ФС» вместо «сделать прототип и идти к следующему клиенту делать новый прототип».

Антон Григорьев, мой партнёр по Проекторату, писал функциональные спецификации (кстати, есть прекрасное выступление Антона, где он рассказывает о том, почему надо писать ФС к интерфейсам). И Арина Герман, которую я привлёк в качестве проектировщика на LP151. Но у неё не было выбора :)

Как и зачем я делал скринкасты прототипов

Скринкаст — это видеозапись с захватом экрана, в которой проектировщик под гусли и балалайку рассказывает о прототипе. В качестве примера прикладываю один из первых своих скринкастов от 2011 года.

Как я их делал?
Включал микрофон, запускал программу захвата видео с экрана и проходил по интерактивному прототипу, попутно объясняя что и для чего там было спроектировано.

Зачем я это делал?
— Продемонстрировать результат работы под нужным мне углом группе людей;
— Сэкономить на поездке на демонстрацию (тогда видеосозвоны было организовать гораздо труднее, чем сегодня);
— Удорожить этап проектирования эдакой новомодной доп. услугой.

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

Как я конфликтовал со своими клиентами и к чему это привело

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

На основе этого горького опыта я стал называть сроки с запасом. А затем научился сообщать о потенциальном срыве задолго до того, как он произойдёт. На этом, через пару лет работы на фрилансе, подобные конфликты и закончились.

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

Первая: взял предоплату 50% за прототип, выполнил и сдал работу, но остаток так и не получил. Цена всей работы — 30 000 рублей. Работал вообще без договора, а также не имел доступа к финальному заказчику, общался через менеджера. В какой-то момент менеджер сообщила мне, что заказчик пропал, а вместе с ним и шанс на оплату. После этого я, во-первых, перестал работать с посредниками, которые только передают чужие деньги, а не платят мне напрямую, и, во-вторых, перестал работать без договоров.

Вторая: взял предоплату 50% за прототип (снова 30 000 рублей), а к моменту сдачи проекта вернул её и больше не работал с тем клиентом. Это был сайт для бюро переводов. Я заключил договор на проектирование с владельцем небольшой питерской студии. А сайт бюро переводов принадлежал его жене. Вводные по сайту я собирал у клиента, а принимала работу и давала обратную связь жена. Разумеется, в первой же пачке комментариев оказалось, что я делал совсем не то, что ей нужно. Я на этом просто завершил сотрудничество и вернул деньги, чтобы не тратить нервы. Клиента добавил в чёрный список. Фактически он обо всём со мной договорился перед началом работ, а в процессе переложил свою ответственность на плечи жены. После этого случая в приложении к моему договору появился раздел с информацией о том, сколько часов требуется от представителя клиента на промежуточные переговоры.

Третья: взял предоплату 50% за прототип (175 000 рублей), выполнил работу, а остаток не получил, потому что клиент просто решил не платить. Договор был оформлен с гендиром компании, имеющей отношение к заказчику. Проблема в том, что я взялся за работу, не дождавшись подписанного экземпляра (тогда ещё обменивались бумажными копиями). В этой истории я уже был опытным и все процессы были выстроены грамотно. Поэтому в результате я просто принял решение больше не работать по 50% предоплате и перешёл на 100% аванс. А должника оставил в покое. Кстати, свои деньги всё-таки случайно получил спустя семь лет (можно почитать об этом здесь).

Цели переговоров с админами Телеграм-каналов при покупке у них рекламы

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

1. Узнать условия
2. Изменить условия в свою пользу
3. Заключить сделку
4. «Остаться друзьями»

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

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

Заключить сделку. Договориться обо всех деталях, зафиксировать их в одном финальном сообщении, получить реквизиты для оплаты и оплатить.

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

Цели последовательно сменяют друг друга. Мне не нужно заключать сделку до того, как я узнаю условия и поторгуюсь. Исключение — цель «остаться друзьями». Она действует всю дорогу и требует самоконтроля.

—
Это из моего курса по закупу рекламы для авторского Телеграм-канала. Я там раскладываю по полочкам всё, что узнал, собирая подписчиков в этот канал. Не теоретизирую и не рассказываю, как надо, а прям показываю всё, что сделал сам. Сел за создание курса ещё в конце августа, думал, это будет лёгкое приключение на пару дней, туда-обратно… Но нет! До сих пор пишу!

Статистика канала нормального фрилансера за октябрь 2023

Продал рекламных объявлений: 2 на общую сумму 6 000 ₽ (до уплаты налога)
Отказал в размещении объявлений: 2
Всего за октябрь написало рекламодателей: 10
Купил рекламных объявлений в других каналах: 20 на 23 000 ₽
Прирост подписчиков за месяц: +237 (с 3 198 до 3 435)
Продал книг: на своём сайте — 5 на сумму 2 495 ₽ (до уплаты налогов), на Литресе — 0
Продал табличек со списком площадок, где рекламировался канал: 0

Написал постов: 35.

Итого потратил за месяц (расход): 23 000 ₽
Заработал за месяц (доход): 8 495 ₽
Прибыль: -14 505 ₽

Это без учёта моего затраченного времени. С каждым месяцем я его вкладываю всё меньше, т.к. всё реже сталкиваюсь с чем-то новым и непонятным.

Получил одну входящую заявку на проектирование. Потенциальный клиент прочитал мою заметку «Почему я почти никогда не начинаю проектирование (или дизайн) сайта с главной страницы» то ли на Хабре, то ли на VC. Пообщались 20 минут. Я взглянул на проект и объяснил, что проблема номер один — это не удобство интерфейса, а то, что каждая страница загружается дольше пяти секунд, и что лучше начинать не с проектирования, а оптимизации кода. Так я «отфутболил» единственную заявку за октябрь :)

О рекламе
Стоимость рекламы в сентябре не изменилась — 3 000 ₽ — но теперь я размещаю её на 2/48, как и большинство других каналов.

Любой рекламодатель, который обращается без маркировки рекламы, бесплатно получает эту маркировку от меня. Я разобрался, как работать с ОРД Вконтакте и встроил этот этап в услугу размещения.

Чего сделал интересного за месяц?
— Написал несколько статей на Хабр и VC (если быть точным, не написал, а скопировал их из этого канала: у меня такие длинные посты, что они вполне себе тянут на небольшие статьи). Два раза попал в топ-10 Хабра за сутки и один раз за неделю. Получил около 80 000 показов суммарно на всех статьях. Это дало мне не больше +30 подписчиков в канал;
— После долгой паузы сдвинулся вперёд в создании курса по закупу рекламы в авторский Телеграм-канал;
— Случайно выяснил, что у части моих читателей есть интерес к теме написания функциональных спецификаций. Удивился;
— Внимательно ознакомился с договорами Политехнического университета на оказание услуг. Таких несправедливых условий по отношению к исполнителям не встречал ни разу за всю карьеру.

Что делать, если план работ разрастается по мере их выполнения?

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

Допустим, я должен был в какой-то день спроектировать страницу со списком товаров в каталоге. И по плану нужно было нарисовать и описать два экрана:

— Список товаров
— Фильтрация списка товаров (модальное окно)

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

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

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

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

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

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

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

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

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

— Общая схема ведения переговоров
— Фиксация договорённостей
— Проблема 10 одновременных переписок

Теперь он выглядит так:

— Цели переговоров
— Тактика ведения переговоров
— Начало общения
— Демонстрация поста и создание пригласительных ссылок
— Торг
— Выбор даты и времени публикации
— Фиксация договорённостей
— Оплата

И так далее. Это сильно удручает и снижает мотивацию, но я не вешаю носа и не опускаю рук.

В главе «Как работает сарафанное радио» я рассказываю о правилах, которые помогали мне поддерживать это самое сарафанное радио в рабочем состоянии. Одно из них звучит так: «Напоминать о себе».

«Чтобы клиенты почаще рекомендовали фрилансера, ему необходимо постоянно находиться в их информационном поле. Можно регулярно спрашивать, как идут дела и как развивается проект, в котором тот принимал участие. Или делиться ссылками на полезные публикации. Либо похвастаться какими-нибудь профессиональными достижениями. Можно даже просто поздравлять с основными праздниками, этого будет достаточно. Главное, чтобы контакт фрилансера был у них под рукой и они помнили, чем он может быть полезен».

На скриншоте к посту — пример того, как лучше не делать.

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

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

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

«Егор, добрый день. У нас тут за два месяца сильно выросла аудитория, да и каналов прибавилось. Если надумаете разместиться в каких-нибудь из них, то вот вам названия и условия. Как постоянный клиент можете рассчитывать на скидку в 10%!».

Я специально не задаю вопроса в своём сообщении, чтобы «холодный» клиент мог спокойно его проигнорировать.

Вебинар «Вопросы клиенту для сбора функциональных требований»

Один из самых классных моих вебинаров. Провёл и опубликовал его на Ютубе в конце 2018 года. Он не потерял актуальности и по сей день. В течение двух часов я детально рассказываю:

— Как собираю функциональные требования к проектам
— Как пользоваться шпаргалкой по составлению документа с функциональными требованиями
— Как формировать пользовательские сценарии «на лету»

Если кто-то интересовался вопросами составления проектной документации на ранних стадиях проектирования интерфейсов — желаю приятного просмотра.

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

Пост про функциональные спецификации (ФС)

Вы сами этого просили. Готовьтесь зевать.

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

Обычно первую версию ФС я создаю во время проектирования информационной системы. Сразу после создания интерактивного прототипа и до дизайна.

ФС может пригодиться во многих случаях:

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

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

Самое страшное в ФС — это то, что никто не любит её писать. Поставьте себя на место проектировщика интерфейсов или дизайнера. Нарисовал за месяц сто макетов, с горем пополам отстрелялся со всеми этими правками. И тут возникает выбор. Распрощаться с клиентом и идти рисовать следующий проект, либо взять все свои сто макетов и детально описать текстом, рассматривая их при этом под другим углом и внося в них новые и новые правки (некоторые мои прототипы получали до 50% изменений в результате описания в ФС и иногда разрастались чуть ли не в два раза).

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

В общем, поначалу я тоже не любил это дело. Когда клиенты спрашивали моего мнения, нужно ли описывать получившийся прототип в техническом задании (термин ФС появился у меня чуть позже), я говорил, что нет, не нужно. Проект и так простой, разрабы разберутся сами, глядя в прототип и макеты. С таким подходом ФС мне приходилось писать на каждом десятом проекте. Как же я ошибался!

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

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

И я понял, что ФС стоит очень мало по сравнению с разработкой. И что пренебрегать ей — это буквально воровать у себя деньги.

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

Продолжение следует?