Как стать автором
Обновить

Как я проектирую интерфейсы

Время на прочтение13 мин
Количество просмотров22K

Привет, я Егор Камелев, проектировщик интерфейсов (UX-дизайнер). За последние 20 лет я поработал с командами десятков агентств, IT-отделов, действующих проектов и продуктов, стартапов (и запущенных, и незавершённых). Я знаком с сотней команд, не меньше. И среди них не нашлось и двух, использующих одинаковые подходы к работе. Верно говорят: «У каждого додика — своя методика!».

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

Поэтому в этой статье я не буду заявлять, что мой подход к работе — единственно верный. Он один из тысяч и в моём случае прекрасно работает: клиенты не заваливают меня правками, платят 100% предоплату и рекомендуют окружающим. Я распишу во всех деталях свой процесс предоставления услуги проектирования (создания интерактивного прототипа информационной системы на заказ). Уверен, что многим пригодятся мои знания.

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

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

В результате моей работы обычно получается три артефакта:

  1. Функциональные требования

  2. Интерактивный прототип в Axure

  3. Функциональная спецификация (ФС)

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

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

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

Из каких этапов состоит услуга

  1. Обработка заявки

  2. Переговоры-знакомство

  3. Переговоры — сбор функциональных требований (ФТ)

  4. Подготовка и согласование документа с ФТ

  5. Подготовка коммерческого предложения (КП) на создание интерактивного прототипа

  6. Оформление договора и получение предоплаты

  7. Проектирование навигационного решения

  8. Первая демонстрация

  9. Серия последующих демонстраций

  10. Завершение работы, подписание акта

Обработка заявки

Обычно тут два варианта. Либо потенциальный клиент пишет мне сам что-то вроде: «Егор, здравствуйте, читал о вас, хотел бы с вами поработать». Либо его контакт скидывает мне кто-то из коллег: «Егор, тут чел ищет проектировщика, вот тебе его контакт».

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

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

Иногда на этом этапе клиент сам сразу присылает какие-то материалы. Если их можно изучить за десять минут, я это делаю. А если там ТЗ на 100 страниц, я не открою его до тех пор, пока мы не познакомимся и не договоримся.

Переговоры-знакомство

На этом этапе у меня три цели. Две последовательные и одна сквозная. Сначала моя цель — узнать о проекте, чтобы понять, могу ли я тут быть полезен. Только после неё может подключиться вторая цель — совершить продажу (а может и не подключиться, если я сразу вижу, что ничем помочь не могу). А третья цель, сквозная, — расстаться друзьями. Даже если собеседник мне не понравился, я виду не подам. Меня никто не заставляет с ним работать и общаться в дальнейшем, но я проделал большой труд, чтобы этот разговор состоялся. Поэтому глупо было бы перечеркнуть его, создав неприязненные взаимоотношения. В конце концов потенциальный клиент уже бережно добавлен в большую табличку и кто знает, когда мы пригодимся друг другу в будущем?

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

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

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

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

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

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

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

Шарю экран, открываю пример ФТ, прототипа и ФС и рассказываю, что это такое, для чего это нужно и что пришлось провернуть, чтобы это воплотилось в жизнь.

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

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

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

Переговоры — сбор функциональных требований

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

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

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

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

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

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

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

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

Подготовка и согласование документа с ФТ

Тут всё просто. Открываю гугл.доки, создаю новый документ, называю его «%Название проекта%, ФТ» (чтобы было легко потом найти среди десятков других таких документов) — и погнали.

Умещаю в одно предложение описание проекта, составляю его структуру (обычно это карта сайта в виде многоуровневого списка), перечисляю пользовательские роли и расписываю функциональные требования для каждой из этих ролей. «Неавторизованный посетитель может…» — и давай перечислять. Я недавно выкладывал видео с живым примером функциональных требований. И в целом за карьеру опубликовал немало материалов на эту тему.

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

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

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

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

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

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

  1. Что я буду делать («Для создания интерактивного прототипа нового интернет-магазина мне понадобится…»);

  2. Срок в календарных днях;

  3. Часы, которые потребуется провести в переговорах;

  4. Стоимость;

  5. Порядок оплаты (100% предоплата).

Жду ответа от клиента. И после того, как он кивнул, что всё в порядке, запрашиваю его реквизиты и email (если у меня их ещё нет) и приступаю к подготовке договора. В качестве Приложения №1 к договору использую тот самый документ с функциональными требованиями.

Вместе с договором готовлю счёт. Потому что работаю по 100% предоплате.

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

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

Оформление договора и получение предоплаты

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

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

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

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

Разумеется, такой подход неактуален для грамотных людей с пухлой финансовой подушкой безопасности.

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

Проектирование навигационного решения

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

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

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

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

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

Первая демонстрация

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

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

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

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

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

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

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

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

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

Серия последующих демонстраций

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

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

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

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

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

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

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

Завершение работы и подписание акта

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

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

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

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

Дальше я подготовлю клиенту КП на написание функциональной спецификации, а после неё предложу авторский надзор, но это уже тема для другой статьи.

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


Если прочитанное и увиденное показалось вам полезным — за моей деятельностью можно следить в Телеграм-канале. Я в последнее время всё чаще пишу там на тему проектирования.

Теги:
Хабы:
Всего голосов 24: ↑20 и ↓4+21
Комментарии20

Публикации

Истории

Работа

Веб дизайнер
50 вакансий

Ближайшие события

19 августа – 20 октября
RuCode.Финал. Чемпионат по алгоритмическому программированию и ИИ
МоскваНижний НовгородЕкатеринбургСтавропольНовосибрискКалининградПермьВладивостокЧитаКраснорскТомскИжевскПетрозаводскКазаньКурскТюменьВолгоградУфаМурманскБишкекСочиУльяновскСаратовИркутскДолгопрудныйОнлайн
3 – 18 октября
Kokoc Hackathon 2024
Онлайн
24 – 25 октября
One Day Offer для AQA Engineer и Developers
Онлайн
25 октября
Конференция по росту продуктов EGC’24
МоскваОнлайн
7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань