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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

Итого, было:

Стало:

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

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

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

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

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


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

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

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

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

@Serebrennikov_i

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

November 6, 2018
by Ваня Серебренников