Первая фича на новой работе. Показываю свою кухню.

Привет-привет! Как я уже говорил в своем телеграм-канале — у меня новая работа. Перешел в британскую компанию DSX.uk и променял биотехнологии на крипту :)

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

Помимо непосредственного "пиления скринов" у меня было много высокоуровневого проектирования, общения с командой, тестирования и пр. Может показаться странным — но работу в целом это только ускорило :)

В этой статье тебя ждет:

Описание фичи (чтобы тебе понимать, о чем вообще речь)
Как правильно начинать работу над фичей (вводная, стейкхолдеры, материалы-наработки, данные, текущая имплементация, декомпозиция задачи на мелкие таски и пр.)
Высокоуровневое проектирование (флоу, набор данных)
Метрики
Проектирование интерфейсов
Юзабилити-тестирование
Взаимодействие с командой разработки
Как я обрезал фичу (важно не только то, что вы делаете, не менее важно то, от чего вы отказываетесь)

Ну что, поехали? :)

Исходная ситуация

На момент моего прихода процесс выглядел примерно так:

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

Мне нужно было спроектировать фичу, при этом улучшив процесс.

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

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

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

Еще одним направлением я увидел работу над дизайн-системой.

Опираясь на это я за две недели спроектировал фичу, провел юзабилити-тестирование, внес правки и согласовал с командой и стейкхолдерами.

В двух словах о фиче:

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

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

Вот именно в этом благородном деле и должна была помочь моя первая фича.

1. Я получил подробную вводную:

Я созвонился с CEO и выяснил:

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

Я попросил сделать запись вводной, и мне было очень удобно это все переслушивать.

Я разобрал эту запись, разобрал и вот что получилось:

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

В результате, я понял, как мне построить свой процесс, на что сделать упор в фиче (высокоуровневое проектирование, создание основы для дизайн-системы, юзабилити-тестирование и метрики, качественная передача в разработку, итеративное развитие фичи).

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

2. Познакомился со стейкхолдерами и командой

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

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

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

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

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

3. Сделал скриншоты и описание текущей имплементации

Я прокликал весь сценарий, начиная с самой регистрации, сделал скрины каждого шага и написал свои мысли. Опять-таки — в notion.so :)

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

4. Рассортировал имеющиеся наработки, решил, что с ними делать.

��то вообще имею по фиче?

Имплементированная форма, которую нужно было обновить и переделать;
достаточно подробное описание в Dropbox Paper;
объемная экселька про данные (причем отличающиеся для разных стран, а стран было несколько десятков);
дизайн в фигме, в котором была реализована часть нового визарда.

Чтобы дать самое общее понимание, вот такой набор скринов я получил на старте:

В конце статьи я покажу для сравнения, какой набор получился в результате :)

То есть, не чистое поле. Что будем делать с каждой из наработок?

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

Все это я декомпозиролвал на микрозадачки в notion. Забегая вперед, вот так выглядит кусочек моего "done" по этой фиче в notion:

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

5. Нарисовал флоу

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

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

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

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

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

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

Поэтому — схемы решают :)

Что я увидел после создания логической схемы:

Точки входа. Я понял, откуда пользователь должен попадать на верификацию. А значит — какие интерфейсы надо включить в прототип и доработать.
Шаги и данные (включая специфику стран). На какие конкретные шаги делится виззард, какие данные заполняем на каждом, какая есть спецфика по странам, и главное — я легко могу шарить это знание с другими, не рискуя, что человек не осилит сложную эксельку. В частности, есть различия в составе имени (в Бразилии и Испании есть такие поля как paternal и maternal name), адреса (с десяток вариантов состава), гражданства и пр.
Доп вопросы. Опциональный шаг с дополнительными вопросами. По нему было достаточно много вопросов, и в итоге было решено от него отказаться (возможно, временно).
Подтверждение телефона. Уже после виззарда мы просим подтвердить номер телефона, чтобы включить двухфакторную авторизацию.
Реджекты. Пользователи часто вносят данные неправильно (кстати, точка для будущей доработки, поскольку ошибки в интерфейсе надо предотвращать, а не исправлять), мы отклоняем их запрос и просим поправить.
Правки. После реджекта пользователю надо предоставить нам поправленные данные. Хорошо бы не повторять шаги виззарда, а просто вывести именно те поля, которые ему нужно отредактировать.
Ожидание верификации. Нужно показать состояние интерфейса, когда данные уже ушли, но ответа еще нет.
Успешная верификация. Все получилось, мы предлагаем пользователю закинуть нам деньги (причем, у этого состояния тоже есть варианты)

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

6. Написал список задач

Точнее, все время работы над фичей я вел список задач по ней.

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

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

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

Вот кусочек отложенных задач:

7. Написал будущие метрики

Да, я сначала составил список метрик, а уже потом стал проектировать интерфейс.

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

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

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

Какие метрики я выбрал? Стандартные, описывающие воронку:

8. Спроектировал интерфейс

Как я и говорил, для фичи уже было неплохое основание для работы, в виде вот такого набора скринов:

Я всегда начинаю с того, чтобы удобно организовать свое рабочее пространство.

Я создал библиотеку:

Стили цвета
Стили текста
Простые компоненты (кнопки, шаги виззарда, инпуты и пр)

Сложные компоненты (множество видов шапок, футеры, полуя подгрузки файлов, и пр.)

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

Но для этого нужно правильным образов сформировать файл, что я и сделал:

Вот так на данный момент выглядит моя библиотечка компонент.

После этого я проектировал интерфейс.

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

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

Набор компонент для всех состояний шапки.

Когда это было сделано — я довольно быстро причесал интерфейс.

Вот пара кусочков:

Форма редактирования данных после реджекта. С выравниваниями надо поиграть, иконки еще предстоит нарисовать нормально, но как прототип ок.

Попап с апрувом телефона

Профиль после успешной верификации основных данных, но телефон пока не верифицирован.

После этого я сделал сделал кликабельный прототип и провел пробное тестирование

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

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

Кроме того, я прокликал прототип вместе с командой, собрал их идеи и каменты. Поправил прототип.

Дальше — написал план-скрипт теста

Обратите внимание — респондентов трое, а рекомендуют обычно пятерых. Почему? — у меня уже было тестирование на двух "пробных" респондентах и я решил его засчитать, поскольку критичных багов не было.

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

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

Итого, было:

Стало:

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

Что имеем в результате?

Стало лучше с точки зрения процесса. Разработка получает внятную сопроводиловку, схемы, описания. Дизайн также получит удобную постановку задачи (об этом — в следующей статье). Копирайтинг впервые получит постановку задачи :)
Организована дизайн-система, стили, компоненты, включая шапки, футеры и пр. В результате мне сильно проще будет дальше собирать подобные формы, а разработчикам будет проще снимать стили, цвета и прочее.
Протестировано. Интерфейс провалидирован с помощью юзабилити-тестирования.
По пути много и регулярно взаимодействовали с разработкой и руководством, для всех все было прозрачно.
Описаны метрики, еще на начальном этапе. Мы сможем в цифрах узнать, в каком месте интерфейсы будут работать плохо и сможем лучше фокусировать в дальнейшей работе над фичей.
Спланировано развитие фичи. Я донес, что мы по сути только началаи работу. Мало выкатить функиционал, надо сделать, чтобы им пользовались так, как нужно бизнесу и как хорошо пользователю.
Скорость производства получилась вполне нормальная (2 недели, типичная итерация), а учитывая, что я только вышел на работу и параллельно решал другие вопросы — хорошая.
Я получил одобрение и кредит доверия для дальнейшего развития отдела. Когда вы приходите на новое место — важно как можно скорее принести первую пользу делу. Тогда построить работу хорошо и удобно будет гораздо проще. Теперь я могу нанять первого участника моей команды, который вместе со мной будет проектировать фичи, проводить юзабилити-тесты и развивать дизайн-систему.

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

как я передавал эту фичу в разработку, дизайн и копирайтинг
как я в целом начинал работу, поскольку эта фича — только часть моих дел :)

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

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

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

Пиши в личку в телеграме, если интересно:

@Serebrennikov_i

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