Привет, я Егор Камелев, проектировщик интерфейсов (UX-дизайнер). За последние 20 лет я поработал с командами десятков агентств, IT-отделов, действующих проектов и продуктов, стартапов (и запущенных, и незавершённых). Я знаком с сотней команд, не меньше. И среди них не нашлось и двух, использующих одинаковые подходы к работе. Верно говорят: «У каждого додика — своя методика!».
У всех свои названия должностей, артефактов, процессов. Свои требования и наборы компетенций. Где-то проектированием занимается маркетолог и разработчик (потому что в команде больше никого и нету), а где-то эта задача распределена между десятью разными специалистами (системные- и бизнес-аналитики, технические писатели, UX-дизайнеры, продакт оунеры и так далее).
Поэтому в этой статье я не буду заявлять, что мой подход к работе — единственно верный. Он один из тысяч и в моём случае прекрасно работает: клиенты не заваливают меня правками, платят 100% предоплату и рекомендуют окружающим. Я распишу во всех деталях свой процесс предоставления услуги проектирования (создания интерактивного прототипа информационной системы на заказ). Уверен, что многим пригодятся мои знания.
Прежде, чем начать, немного введу в контекст. Основной мой клиент — это человек, которому нужно спроектировать что-то новое с нуля («хочу сделать приложение, которое поможет мне автоматизировать бизнес-процесс»). Чуть реже — переделать под корень что-то устаревшее («старый магазин был хорош, но у нас есть видение, как сделать новый, ещё лучше»). И ещё реже — улучшить что-то актуальное и работающее («мы внезапно выяснили, что у нас клиенты на чек-апе отваливаются, не могли бы вы взглянуть?»).
Я снял получасовой видеоролик, где детально рассказываю обо всём жизненном цикле предоставления услуги: от обработки заявки до подписания акта сдачи-приёмки работ. Рекомендую смотреть на скорости х2. А в статье постараюсь осветить самое важное.
В результате моей работы обычно получается три артефакта:
Функциональные требования
Интерактивный прототип в Axure
Функциональная спецификация (ФС)
Они оцениваются и создаются последовательно. То есть я не могу сказать, сколько будет стоить интерактивный прототип, пока не соберу функциональные требования. И сколько будет стоить ФС, пока не закончу работать над прототипом.
Всё потому что проектирование — это процесс с непредсказуемым результатом. Если бы проектировщик в самом начале знал, что должно получиться на выходе, то он бы назывался как-нибудь по-другому. И если делать оценку под ключ, то в случае ошибки в объёмах работы на первом этапе, последующие загонят бедного проектировщика в минуса.
Здесь я поведу рассказ именно об интерактивном прототипе. ФС оставим на другой раз. А ещё в моём рассказе этап со сбором функциональных требований — бесплатный. Но иногда бывает так, что проект — среднего или высокого уровня сложности. И тогда этот этап тоже оценивается отдельно.
Из каких этапов состоит услуга
Обработка заявки
Обычно тут два варианта. Либо потенциальный клиент пишет мне сам что-то вроде: «Егор, здравствуйте, читал о вас, хотел бы с вами поработать». Либо его контакт скидывает мне кто-то из коллег: «Егор, тут чел ищет проектировщика, вот тебе его контакт».
И там, и там моя задача простая: вывести человека на разговор голосом. Моя услуга сложная, растянутая во времени, требующая огромного количества согласований. Невозможно договориться обо всём в переписке. Поэтому я пишу своё стандартное сообщение с предложением созвониться. Назначаю дату, время по Москве, спрашиваю, удобен ли этот вариант. Предупреждаю, что на разговор понадобится полчаса и что мы познакомимся и обсудим проект.
Я не прошу заполнять брифа и не прошу прислать мне каких-либо материалов. Зачем мне тратить своё и чужое время на эти действия, если может оказаться, что мы по каким-то причинам не сможем работать? А ещё никто не любит делать «домашнюю работу». Я хочу, чтобы сотрудничество со мной клиент начинал не с того, что я его «припахал», а с непринуждённой и хорошо организованной беседы.
Иногда на этом этапе клиент сам сразу присылает какие-то материалы. Если их можно изучить за десять минут, я это делаю. А если там ТЗ на 100 страниц, я не открою его до тех пор, пока мы не познакомимся и не договоримся.
Переговоры-знакомство
На этом этапе у меня три цели. Две последовательные и одна сквозная. Сначала моя цель — узнать о проекте, чтобы понять, могу ли я тут быть полезен. Только после неё может подключиться вторая цель — совершить продажу (а может и не подключиться, если я сразу вижу, что ничем помочь не могу). А третья цель, сквозная, — расстаться друзьями. Даже если собеседник мне не понравился, я виду не подам. Меня никто не заставляет с ним работать и общаться в дальнейшем, но я проделал большой труд, чтобы этот разговор состоялся. Поэтому глупо было бы перечеркнуть его, создав неприязненные взаимоотношения. В конце концов потенциальный клиент уже бережно добавлен в большую табличку и кто знает, когда мы пригодимся друг другу в будущем?
Готовлюсь к переговорам заранее. Если есть возможность — гуглю клиента и его компанию. Вы не поверите, насколько умнее кажется собеседник, если он в курсе основных моментов вашей деятельности!
Не опаздываю (а если опоздания не избежать, предупреждаю об этом очень заблаговременно, а не в момент начала переговоров). За десять минут до старта нахожусь в боевой готовности. За пять минут пишу «набирайте как будете готовы», чтобы дать возможность стартануть чуть раньше или позже.
Если собеседник задержался и не предупредил меня об этом заранее, я сразу делаю себе пометку и в будущем при оценке проекта использую повышающий коэффициент. Это не потому что я обиделся и хочу кого-то наказать, а потому, что, если человек опаздывает на первое же знакомство вне деловых отношений, то он точно будет нарушать сроки и обязательства в дальнейшем. Я умею с этим эффективно работать, но это требует чуть больше моих ресурсов и хотелось бы компенсировать их деньгами.
Я представляюсь, улыбаюсь и прошу рассказать, с чем ко мне пожаловал собеседник. А дальше внимательно слушаю, не перебивая и ничего не уточняя. Это тот самый момент, когда я должен понять, как клиент умеет излагать мысли и контролировать время. Ну и разумеется я должен получить представление о проекте. В общем, я не модерирую эту часть, я позволяю высказаться от души.
После этого уже начинаю задавать уточняющие вопросы. Причём меня в первую очередь интересует общая картина, а не детали.
Во время рассказа о проекте и во время уточняющих вопросов я записываю важные моменты в заметках. Эта привычка позволяет мне ничего не упускать и каждый раз удивлять клиентов, когда я сам напоминаю им о чём-то, что казалось важным для них (и, кстати, не особо важным для меня самого).
Принимаю решение о потенциальном сотрудничестве. Если нет, то вежливо завершаю переговоры. Если да, то приступаю к рассказу о том, чем могу быть полезен.
Шарю экран, открываю пример ФТ, прототипа и ФС и рассказываю, что это такое, для чего это нужно и что пришлось провернуть, чтобы это воплотилось в жизнь.
Объясняю, что для оценки проектирования мне нужно глубже погрузиться в задачу и что мы можем это провернуть на следующих переговорах. Сколько эти переговоры займут по времени я обычно оцениваю «на лету», но бывают и сложные случаи-исключения.
Причём бывает и так, что уже к концу переговоров-знакомства я знаю о задаче достаточно, чтобы составить функциональные требования без дополнительных переговоров. Бывает так, что мне нужен ещё час разговора с клиентом — и готово. А бывает, что приходится оценивать этап сбора ФТ отдельно (например, когда мне нужно разобраться с десятками сложных бизнес-процессов в компании клиента), но этот случай я сегодня не хотел бы рассматривать.
Клиент обычно поддерживает мой подход к ведению дел — и мы согласуем следующую дату переговоров. Начиная с этого момента сотрудничества со мной, клиент уже никогда не останется в ситуации, когда ему неизвестно, какой следующий шаг и какого числа и во сколько он произойдёт. И вы не представляете, как сильно этот подход влияет на успех всего мероприятия!
Переговоры — сбор функциональных требований
Готовлюсь заранее, составляю список вопросов, которые важно не забыть задать. Прихожу вовремя, ожидаю того же и от потенциального клиента.
Эти переговоры я жёстко модерирую. Мне важно получить от клиента конкретную информацию, поэтому я его активно направляю в нужное мне русло. Задаю кучу вопросов, важных для проектирования, фиксирую ответы в заметках. Делаю это демонстративно. Если на переговорах-знакомстве клиент не догадывается, что я за ним записываю, то тут он должен это видеть воочию. Так я демонстрирую свою надёжность в работе с информацией.
Не буду раскрывать здесь, какие именно вопросы я задаю и для чего, т.к. это тема для отдельного материала (тем более, который я уже публиковал несколько лет назад), но все они направлены на то, чтобы я хорошенько «въехал» в проект и сумел превратить абстрактные «хотелки» клиента в прикладные функциональные требования.
В процессе я снова шарю экран, мы смотрим на конкурентов, на референсы, вот это всё. Иногда обходимся и без этого.
В конце переговоров я называю дату и время, когда документ будет готов. Обычно это занимает не дольше суток. Наоборот, чаще даже бывает так, что я сразу после переговоров, пока ничего не выветрилось из головы, сажусь и пишу «по-горячему».
Ещё один важный момент. И на переговорах-знакомстве, и во время сбора ФТ я должен удостовериться в том, что клиент понимает весь процесс. Я заранее объясняю, какие ещё будут этапы впереди и сколько они стоят, чтобы потенциальный заказчик был вооружён и принимал взвешенное решение.
Я говорю: «Сейчас мы готовимся к созданию интерактивного прототипа, но после этого я обязательно предложу вам приобрести функциональную спецификацию. И она будет стоить плюс ещё столько же. И по времени плюс ещё столько же займёт».
Среди агентств, с которыми я работал, многие предпочитали скрывать подобную информацию от своих заказчиков. Им важно было втянуть клиента в сделку, а затем постепенно ставить его перед фактом, что есть ещё этапы и что они стоят денег. Я много раз видел, как этот подход приводил к тому, что бедный заказчик сливал несколько миллионов в проект, но в итоге не доводил его до конца, потому что заранее не знал, сколько ему понадобится денег. По мне так это как-то… мерзко что ли.
Подготовка и согласование документа с ФТ
Тут всё просто. Открываю гугл.доки, создаю новый документ, называю его «%Название проекта%, ФТ» (чтобы было легко потом найти среди десятков других таких документов) — и погнали.
Умещаю в одно предложение описание проекта, составляю его структуру (обычно это карта сайта в виде многоуровневого списка), перечисляю пользовательские роли и расписываю функциональные требования для каждой из этих ролей. «Неавторизованный посетитель может…» — и давай перечислять. Я недавно выкладывал видео с живым примером функциональных требований. И в целом за карьеру опубликовал немало материалов на эту тему.
В конце указываю, сколько часов понадобится на работу и сколько на переговоры. Но не отношусь серьёзно к этим цифрам, пока клиент не согласует содержание документа.
Когда всё готово — скидываю ссылку клиенту и прошу его прочитать и подтвердить, что я ничего не упустил и не перепутал. В режиме онлайн он оставляет свои комментарии, если что-то находит. Часто на документ смотрят сразу несколько человек из его команды.
Я всегда радуюсь, получая комментарии. Это показывает, что с документом кто-то ознакомился. И повышает причастность клиента к работе. Чем выше причастность к финальному результату, тем ценнее в его глазах будет этот результат.
Обрабатываю полученные комментарии, дополняю документ и получаю финальный ответ: «В документе всё правильно, давайте делать оценку!». И только после этого я ещё раз прикидываю, сколько времени мне потребуется на прототип, и фиксирую это дело в функциональных требованиях.
Подготовка коммерческого предложения
Первое, что я делаю — скидываю потенциальному клиенту сообщение в мессенджер. В нём указываю:
Что я буду делать («Для создания интерактивного прототипа нового интернет-магазина мне понадобится…»);
Срок в календарных днях;
Часы, которые потребуется провести в переговорах;
Стоимость;
Порядок оплаты (100% предоплата).
Жду ответа от клиента. И после того, как он кивнул, что всё в порядке, запрашиваю его реквизиты и email (если у меня их ещё нет) и приступаю к подготовке договора. В качестве Приложения №1 к договору использую тот самый документ с функциональными требованиями.
Вместе с договором готовлю счёт. Потому что работаю по 100% предоплате.
Отправляю на клиентский email письмо с заголовком «Договор и счёт на проектирование». В теле письма повторяю коммерческое предложение, чтобы клиенту не пришлось искать нужную информацию в разных местах. Прикрепляю к письму файлы с договором и счётом.
Про подготовку коммерческих предложений у меня тоже ролик найдётся. Если честно, когда начинал писать эту статью, не думал, что вставлю в неё столько видеоматериалов.
Оформление договора и получение предоплаты
Я сразу предлагаю клиенту обменяться договорами с помощью электронного документооборота (ЭДО). Я работаю как ИП на упрощёнке, у меня есть электронная подпись. При этом мне даже не нужно оплачивать диадок или что-то вроде того. У моих клиентов, которые готовы к ЭДО, всегда есть свои оплаченные аккаунты и я просто прошу скинуть мне документ на подпись. В очень редких случаях приходится действовать по-старинке: распечатывать экземпляры в бумажном виде и подписывать их.
После того, как договор подписан, я ожидаю предоплату. Я ни за что не приступлю к работе без подписанного договора. И без предоплаты.
По договору срок работы начинается именно с момента предоплаты, поэтому бывают ситуации, когда старт немного отложен. Этот риск заложен в расчёты, календарь я составляю с учётом потенциальных поправок, поэтому здесь обычно без неожиданностей. Если клиент слишком сильно затягивает с оплатой, я могу сообщить ему об этом и сделать переоценку, но в реальности такого ни разу не случалось.
Когда предоплата поступает на мой счёт, я не прикасаюсь к ней до тех пор, пока работа не будет закрыта актом. Эту привычку я завёл для душевного спокойствия. Хорошо, когда в случае какой-нибудь непредвиденной катастрофы у тебя есть запасной выход в виде возврата предоплаты. За всю карьеру (более 350 проектов) мне приходилось возвращать предоплату лишь однажды. Но насколько же меньше стресса в работе, когда знаешь, что можешь так поступить.
Разумеется, такой подход неактуален для грамотных людей с пухлой финансовой подушкой безопасности.
Как только деньги пришли — я сразу сообщаю об этом клиенту и объявляю о старте работ. Тут же назначаю дату и время следующих переговоров, создаю для проекта групповой чат в Телеграме (если на стороне клиента несколько участников) и сажусь за работу.
Проектирование навигационного решения
Работаю я быстро и эффективно. И в этом кроется опасность. Мне не хочется сразу садиться за работу, т.к. я уверен, что успею всё сделать, даже если приступлю через недельку. Чтобы не допускать таких сценариев, я искусственно ставлю себя в условия, когда затягивать невозможно. Переговоры для первой демонстрации я назначаю на буквально первый-второй день после начала работ.
Чтобы без внутреннего сопротивления приступить к работе над прототипом, у меня тоже есть отдельная рутина. Создать файл, дать ему название, создать титульную страницу, вытащить направляющие. Пока всё это сделаешь — вроде уже и влился в процесс и по инерции двигаешься дальше.
Беру структуру проекта, изучаю все его разделы, раскидываю их по важности, частотности и здравому смыслу и создаю меню навигации. Причём не одно, а несколько. Основное, в шапке. Пользовательское, для аутентифицированных пользователей. Отдельно компоную меню для подвала. Сколько проектов — столько разных вариантов.
Спроектировав навигацию, я создаю для каждого раздела отдельную страницу в прототипе и перелинковываю все ссылки в шапке, подвале и прочих сквозных местах. И это первое, что я показываю клиенту. Потому что дальнейшие правки в навигацию — они самые болезненные и трудоёмкие — и с ними надо разобраться прежде, чем браться за отдельные страницы.
Если бы я работал в Фигме (а не в Axure, как сейчас) — процесс бы ничем не отличался. Я бы создал все необходимые фреймы для каждой страницы проекта (в том числе и для того, чтобы понимать объём грядущих работ), сделал компоненты для шапки, подвала и каких-то других навигационных сквозных элементов — и перелинковал бы их. Кстати, про это у меня тоже когда-то был снят отдельный ролик.
Первая демонстрация
Итак, через пару дней после начала работ, я уже демонстрирую клиенту получившийся результат. Сразу объясню, к чему такая «спешка».
Если пропасть на две недели и вернуться с готовым проектом, то, во-первых, на изучение результата понадобится очень много времени. Проектировщик не может рассчитывать на то, что результат его пятидесяти часов работы клиент посмотрит за полчасика и даст обратную связь.
Во-вторых, можно настолько сильно не угадать с решением, что клиенту даже не за что будет зацепиться, чтобы формулировать обратную связь. Тут либо всё переделывать, либо опустить руки.
В-третьих, даже если клиент настолько упорный, что потратит несколько дней на изучение результатов и будет в течение этих дней порционно выдавать обратную связь, то руки опустятся уже у проектировщика.
Всего этого можно избежать, если двигаться к цели очень короткими итерациями. Каждая итерация позволит корректировать курс, предотвращать серьёзные правки, позволит лучше понять, что именно хочет клиент получить в результате. А ещё такая вовлечённость клиента в процесс повысит ценность результата в его глазах.
На первой демонстрации я шарю экран, показываю как всё работает и почему я это спроектировал именно так. Отвечаю на вопросы, записываю комментарии.
Многие правки вношу «на лету». Более того, мои клиенты с удовольствием смотрят не только на сгенерированные интерактивные прототипы, но и на их исходники в Axure. И то, как я в них работаю. В конце концов, наблюдать за чужой работой — это одна из маленьких радостей жизни.
В общем, мелкие правки я вношу сразу, а что-то крупное буду исправлять уже после разговора.
После демонстрации я делюсь ссылкой на опубликованный прототип, закрепляю сообщение с этой ссылкой в нашей переписке, чтобы она всегда была под рукой, и, как обычно, назначаю следующую дату переговоров. Идеально, когда эта дата наступает на следующий день.
Серия последующих демонстраций
Частенько я работаю непосредственно перед следующими переговорами. За час-два я могу проделать достаточно большой объём работы, чтобы это выглядело так, словно я работал весь прошлый день. Такой подход оказался очень эффективным. Я даже не скрываю его от своих клиентов и никого это ни разу не смутило. Да, я работаю в последний момент, перед переговорами, но этот момент не значим для судьбы всего проекта. Наоборот, гораздо хуже, если бы я работал в последние дни перед сдачей проекта в конце месяца.
Двигаясь по прототипу, сначала я прорабатываю важные разделы, затем второстепенные, а в самом конце — тупиковые и крайние сценарии.
Я стараюсь не думать о динамических элементах в прототипе. Моя главная задача — не создавать сущностей, в которые потом сложно будет вносить правки. Этим можно будет заняться позже, в самом конце работы.
Не ограничиваю клиента в «виражах» (когда в середине работы приходит какая-то мысль, о которой мы не думали раньше, и надо что-то переделывать). Опыт показал, что можно долго пытаться спасти неправильное решение с помощью кучи «костылей». И в итоге всё равно получится не очень. А можно сразу договориться, что мы пошли не тем путём и что тот или иной участок нужно «снести» и перепроектировать. В этом случае всё происходит быстрее и эффективнее. В таком подходе мне помогает знание о том, что проектирование — это процесс создания чего-то нового, мы не всегда сразу знаем, к чему придём. И поэтому не стоит сильно себя ограничивать.
Каждый раз, когда приходится удалять что-то спроектированное и переделывать это заново, я сохраняю прототип под новым названием. Чтобы, в случае чего, можно было восстановить предыдущее решение. Разумеется, я завёл эту привычку после того, как клиенты пару раз говорили: «Не, всё-таки предыдущее решение было лучше. Давайте к нему вернёмся?». А оно уже было удалено с концами и приходилось восстанавливать его по памяти.
Всю дорогу я продолжаю вести заметки. У меня перед каждой демонстрацией есть план и перечень вопросов. А после демонстрации — список заметок и комментариев от клиента, которые нужно отработать к следующему разу.
В процессе я готовлю клиента к покупке следующего этапа — функциональной спецификации. Обращаю внимание на те участки интерфейса, по которым невозможно понять, как они работают, не прочитав документации. Например, сколько максимум элементов может быть в списке, сколько попыток у пользователя на аутентификацию, какие сообщения об ошибках могут быть в той или иной форме и так далее.
Завершение работы и подписание акта
Какая-то из демонстраций становится финальной. Все разделы, сценарии и нюансы проработаны, дальше проектировать просто нечего. На таких переговорах я предлагаю завершать этот этап и приступать к следующему.
В начале карьеры на этом этапе могла повиснуть какая-то недосказанность. Вроде всё готово, а вроде неплохо было бы ещё разок перепроверить свою работу. Доработать какие-нибудь мелочи в редких разделах. Поправить какую-нибудь неважную опечатку на главной странице.
Сегодня же мои процессы организованы так чётко, что мне достаточно пройтись по списку заметок и удостовериться, что напротив каждого пунктика стоят плюсы. А правок от клиента ближе к концу работы над прототипом не может быть, потому что он буквально делал его вместе со мной.
После я готовлю акт, обмениваюсь им с клиентом с помощью ЭДО и вот теперь я могу тратить честно заработанные деньги.
Дальше я подготовлю клиенту КП на написание функциональной спецификации, а после неё предложу авторский надзор, но это уже тема для другой статьи.
Клиент попадает в мою базу. В будущем я буду периодически спрашивать, как у него дела и поздравлять с некоторыми праздниками. Это нужно для работы сарафанного радио. И это не выглядит навязчиво, потому что за десятки часов, проведённых в переговорах, мы уже довольно неплохо узнали друг друга.
Если прочитанное и увиденное показалось вам полезным — за моей деятельностью можно следить в Телеграм-канале. Я в последнее время всё чаще пишу там на тему проектирования.
