Раннее вовлечение

Когда я пришёл в команду в 2021 году, был всего один дизайнер. Его работа сводилась к очень простой схеме: продукт писал бизнес-требования, перекидывал задачу в дизайн, а тот отрисовывал макет. На этом участие заканчивалось.

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

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

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

Вот так выглядел предыдущий процесс разработки:

1. Менеджер создает и описывает задачу.
2. Дизайнер готовит артефакты в соответствии с требованиями.
3. Разработка оценивает задачу и приступает к реализации.
4. Катим на прод.
5. Убираем фичефлаги, если есть.

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

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

Подход к процессу проектирования. Пересмотрели его полностью.

Мы сместили роль дизайна на более ранние этапы, чтобы дизайнеры начали участвовать в исследованиях и системном маппинге: вместе с продактами они строят общую картину потребности и вместе выявляют потенциальные проблемы ещё до этапа проектирования. Также мы добавили несколько промежуточных этапов – Research Review и Solution Approval, где решения обсуждаются совместно и получают оценку до передачи в разработку.

Избавились от «Задачи» в пользу «Запроса» – потребности клиента, пользователя, ПМа и т.д. на доработку или решение какой либо проблемы. Запрос не всегда может касаться доработки и не всегда будет решен через неё.

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

Заинтересованно лицо (саппорт, проджект менеджер, продакт и т.д.) создает запрос через единую точку входа - Jira. У сотрудников есть доступ к бэклогу запросов, где они могут отследить статус своего запроса и решение по нему.

Регулярно, раз в 2 недели, рабочей группой (лиды) проводится актуализация приоритетов и оценка плановых дат на каждом этапе по бэклогу с запросами начиная со статуса Backlog.

Коротко об обновлённых и новых этапах:

1. Backlog - приоритезация запросов для этапа исследования, назначение ответственного продакт менеджера, экспертная оценка сроков реализации запроса и плановой даты начала исследования.
2. Current focus - по итогам приоритизации запрос переход в этот статус, по нему назначается дизайнер.
3. Research - по итогам исследования запрос может быть отклонен (Rejected) либо отложен или отправлен на уточнении требований (Postponed), либо перейти на следующий этап Solution Approval и в этом случае для него обновляется приоритет с точки зрения актуальности его дальнейшей проработки.
4. Solution Approval (запрос прошел этап исследование и перешел на этап определения оптимального решения) - по итогам встречи рабочей группы запрос либо переходит в статус отклонен (Rejected) либо отложен или отправлен на уточнении требований (Postponed) либо переходит на этап проработка требований и интерфейсного решения. В этом случае по запросу оцениваются трудозатраты в дня на этап Description & Design, которая включает в себя оценку от продакта и дизайна, разработка оценивает верхнеуровнево реализацию выбранного решения и устанавливаются плановые сроки начала проработки требований, проектирования интерфейса и разработки.
5. Description & Design (проработка требований и интерфейсных решений) - в соответствии с плановыми сроками и приоритетами по запросу начинается проработка требований и интерфейсного решения.
6. Description & Design Review - на этом этапе рабочая группа смотрит проработанное финальное решение.

Сейчас дизайнеры также вовлечены в System Mapping Workshop на этапе Research и Research Review: помогают фиксировать и визуализировать процессы, обращают внимание на пробелы в пользовательских путях. На Research Review они вместе с продуктами проверяют, хватает ли информации для перехода к проектированию и помогают сформулировать подход к решению до отрисовки. И только после этого переходят к детальной проработке экранов.

Теперь дизайнер сопровождает запрос на всём пути: от начала исследования и описания до передачи в разработку, а затем вместе с продактом проверяет результат реализации на предмет выполнения спроектированных сценариев, визуальных ошибок, неточностей во взаимодействии (что не увидели QA или посчитали допустимым дефектом).

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

Да, первые 2−3 месяца процесс несколько замедлился, посколько потреболось время на обкатку и устранение недопонимания в мелких вопросах, но в перспективе скорость доставки ценности заметно выросла. Это видно без всяких цифр по глубине знаний о логистике у дизайнеров, по более «проблемоцентричному» описанию потребностей в запросе и сокращению доделываний или переобуваний уже в процессе написания кода.