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

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

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

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

Итого:
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. У меня был выбор — описывать в ФС небольшой участок системы или отдать прототип в разработку. Я выбрал второй вариант — и в процессе разработки возник ряд мелких вопросов, которые я как проектировщик решил бы буквально за несколько часов. Эти вопросы были вынесены на обсуждение, согласованы, затем реализованы. Причём пришлось переделывать небольшую часть уже спрограммированных функций. Эта вылилось в дополнительный месяц работы разработчиков, который обошёлся моей казне в несколько сотен тысяч рублей.

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

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

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

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

«Чем толще техническая документация — тем лучше»

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

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

Поэтому первое, что я сделал в своих функциональных спецификациях, — избавился от 10% объёма, просто отказавшись от вводных слов типа:

— В этом разделе находятся следующие элементы
— Меню навигации состоит из
— Карточка товара включает в себя следующие составляющие
— Ссылка ведёт в раздел такой-то

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

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

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

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

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

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

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

Суммарно эти оптимизации привели к тому, что мои функциональные спецификации заметно «похудели», при этом не теряя полноты описания. Вместе с ними без следа исчез и подход «Чем толще техническая документация — тем лучше». ФС должна быть ровно такой толщины, которая позволяет минимальным количеством текста максимально описать систему.

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

Сегодня в 21:30 по МСК готов провести для вас трансляцию в гугл.мите по функциональным спецификациям.

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

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

Придёте? Вот ссылка: https://meet.google.com/hxv-kjxs-jvy

--
В итоге пришёл один человек. Ещё двое присоединились и ушли через какое-то время. Что и следовало ожидать от темы функциональных спецификаций :)

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

А встреча в целом была классной! Люблю, когда мало народу и все могут высказаться.

Метод Джинна или как на лету формулировать торговые предложения для чего угодно

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

Я часто использую этот метод при создании одностраничных сайтов. Суть метода Джинна:

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

2. Спросите, чего желает ваш хозяин, ни в чём его не ограничивая. Представьте себе его ответ. Например: «Хочу большую пиццу прямо сейчас и бесплатно».

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

4. Используйте оба его ответа, чтобы сформулировать торговое предложение. Первый ответ приведите в соответствие с вашими возможностями. Например: «Доставим большую пиццу в течение часа от 500 рублей». Второй ответ используйте, чтобы усилить торговое предложение: «Доставим пиццу «Сытную» в течение часа от 500 рублей».

Примеры:

Основа: Хочу, чтобы мой телефон никогда не разряжался, чтобы не остаться без навигатора или мессенджера в неподходящий момент.
Результат: Лёгкий павербанк за 3 000 ₽ подарит вам дополнительные 60 часов работы телефона, и вы не останетесь без навигатора или мессенджера в неподходящий момент.

Основа: Хочу мгновенно научиться закупать рекламу в Телеграм-каналах по 5 копеек за подписчика и чтобы это были не боты.
Результат: Курс по закупу рекламы в Телеграм канал: 2 часа теории, 2 часа практики — и после этого вас не смогут обмануть мошенники и вы сможете закупаться выгоднее, чем раньше.

Дальше остаётся сократить и «причесать» получившийся результат — и готово.

Главное — сформулировать фантастические желания клиентов, а затем «приземлить» их до реальных.

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

Идет мужик по пустыне. Жарко, пить хочется, силы на исходе. Вдруг видит — лампа Алладина валяется. Схватил мужик лампу, потёр, из неё джинн появляется и говорит:
— Ну, мужик, любое желание выполню.
— Джинн, домой хочу.
— Хорошо, пошли.
— Да нет, я быстро хочу.
— Ну тогда побежали.

В апреле 2011 года я пришёл на собеседование в компанию Exigen Services

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

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

И вот я приехал такой в пиджачке и при галстуке куда-то на Пулковское шоссе (мне туда полтора часа пришлось добираться) и началось собеседование. Со мной одновременно общались три барышни. Как сейчас помню их первый вопрос: «Вы давно занимаетесь UX?». А я такой: «Чем?».

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

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

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

Раскина и Купера, кстати, прочитал.

С каким способом развода в Телеграме я встречался чаще всего в 2023-м

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

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

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

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

Вы только посмотрите, какое я откопал видео!

Март 2018 года, я беру интервью у своего партнёра по Проекторату и автора Телеграм-канала UX Notes — Антона Григорьева.

Мы с Антоном каждую неделю прогуливались, обсуждали проекты, клиентов и делились опытом. Именно тогда у меня зародилась идея написать «Книгу нормального фрилансера».

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

В интервью Антон рассказывает о своём опыте выхода и работы на фрилансе. Я сегодня с удовольствием пересмотрел его (на скорости х2 вообще отлично зашло). Это были хорошие времена. На следующий 2019 год грянул ковид, а дальше вы сами знаете…

Приятного просмотра: https://youtu.be/u2uKcJHWi2w?si=VuwM5qRgnotKk3ew