Первая фича — передача в разработку

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

Какие же артефакты я предоставил и что получилось в результате?

1. Карта переходов и данных
2. Кликабельный прототип с основным сценарием
3. Прорисовка разных состояний (два экрана имеют довольно много вариантов данных в зависимости от того, какую страну выбрал пользователь)
4. Набор компонентов+адаптивность
5. ТЗ для дизайна
6. ТЗ на разработку
7. Задача на метрики
8. Список отложенного на будущее

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

Карта переходов

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

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

Что поменялось? Поменялось самое главное — предназначение.

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

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

В чем разница?

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

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

А вот схема, которую я передаю команде, достаточно стандартна. Список скринов (при необходимости, блоки в скринах), основные состояния, логика переходов. И решает она задачу — объяснить скрины-связи-данные.

Работает ли такая схема? Да, она отлично работает. Я пришел на новое место, к новой команде, впервые передал им фичу, и у них практически не всплыло вопросов, когда они сели ее делать (практически — это значит, что мы 2-3 раза поговорили во второй день их работы над фичей, в-основном по мелочам).

Кликабельный прототип с основным сценарием

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

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

Прорисовка разных состояний экранов

В этом плане было довольно много работы, приведу пример:

Это шаг виззарда, данные на котором могут сильно отличаться (в зависимости от того, какую страну указал пользователь). Я решил нарисовать все состояния, а заодно указал сверху над каждым скрином — к какой стране относится, и на какие поля обратить внимание. Ребята потом порадовались.

Набор компонент и адаптивность

Вот что я насоздавал за время работы над фичей. Зачаток дизайн-системы :) Шапки правда организованы пока не вполне оптимально — долго вносить изменения в адаптивные версии.

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

ТЗ и постановка задачи для дизайна

Задача не сразу было принята в работу нашим подрядчиком и претерпела некоторую эволюцию:) Покажу картинки и расскажу о процессе.

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

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

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

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

В результате задача на дизайн похудела и стала вот такой:

Отдельно я написал в Notion текстовое, более подробное, ТЗ.

В результате ТЗ было принято и сейчас мы ждем результатов дизайна.

ТЗ на разработку

ТЗ, возможно, слишком громкое название.

Я написал подробную доку, где описал все скрины и основные компоненты.

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

Задача на метрики

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

Отложенное на будущее

Правильно определять, чего мы сейчас делать НЕ будем — так же важно, как решать, что именно мы сделаем. Задач и доделок всегда больше, чем сил и времени у меня и команды.

Вот маленький кусочек "беклога" данной фичи:

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

Что помогло мне определять вещи, которые можно "порезать"?

1. Понимание бизнес-задачи
2. Понимание, как это повлияет на отношения с командой и подрядчиком

Бизнес-задачу я для себя сформулировал примерно так:

1. Создать основу, многошаговый виззард, который легко будет модифицировать и развивать, с точки зрения проектирования, дизайна и разработки
2. Начально настроить продуктовый процесс. Где у нас есть постановка цели фичи, исследование, настройка метрик, юзабилити-тестирование, используется верхнеуровневое проектирование (схемы и пр.) и дизайн-система, фича внятно и подробно описывается при передаче в разработку. И все это происходит во вменяемые сроки (в дальнейшем две недели, на первый раз можно три с копейками).
3. Актуализировать процесс верификации пользователя (данные должны соответствовать текущим бизнес-требованиям)
4. Наладить свое взаимодействие с бизнесом
5. Наладить свое взаимодействие с командой
6. Наладить свое взаимодействие с дизайн-подрядчиком

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

В следующих статьях:

1. как я в целом начинал работу на новом месте (эта фича — только часть моих дел)
2. опрошу вас и добавлю несколько злободневных тем :)

Понравился мой подход к работе?

Я учу ему в своих менторинговых группах и на интенсивах.

В ноябре-декабре 2018 стартуют интенсивы по аналитике (воронкам), и по юзабилити-тестированию, а также новый набор в менторинговую группу. Пиши в личку, если интересно.

@Serebrennikov_i

И не забывайте подписываться на мой канал о UX!