Как аутстафф дизайн-команды может усилить команду продукта

Привет, я Вова Сайков, дизайн-лид в студии pinkman.

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

Забегая вперед, скажу, что в данном кейсе аутстафф продлился всего 3 месяца, что не много для таких проектов — тем интереснее оценить, что может сделать команда за такой короткий срок.

Итак, в мае 2022 года в студию обратилась компания bioniq. Это британский healthcare-стартап с русскими корнями. На тот момент ребята занимались доставкой витаминных комплексов в Европе.

Первоначальный запрос казался простым и понятным: надо было сделать Android-версию приложения и спроектировать новую концепцию приложения, а по дороге «чуть-чуть наладить дизайн-процесс».

Дизайн-команда выглядела так: от pinkman — я как дизайн лид + дизайнер Влад; от клиента — дизайнерка Соня.

Когда мы приступили к работе, всплыли новые подробности (никогда такого не было, ага), а именно:

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

Вместе с CPO мы решили, что совместим «наведение порядка» c созданием новых дизайн-артефактов. Мы сформулировали 4 задачи, которые помогут закрыть цели продукта и настройку процессов. Также у нас было и много мелких задачек, но для нашей истории это не так важно. Вот большие задачи:

Далее, расскажу, что конкретно мы сделали в рамках этих задач.

Эту задачу взял на себя студийный дизайнер Влад. Напомню, что у bioniq уже было приложение на iOS, но нигде не было макетов приложения и карты экранов. Точнее, некоторые макеты были разбросаны по разным файлам Фигмы, а некоторых вообще не было.

Как мы решили эту задачу:

В итоге появились:

Предыстория задачи: дизайнерка Соня из команды клиента начала работу над задачей за два месяца до нашего появления. Основная сложность заключалась в том, что она работала над задачей не системно, а как получится. Т.е. не было плана работ, понимания объема и DoD задачи. Мы решили помочь ей, добавив системности в работу.

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

Фактически помимо отрисовки макетов нужно было познакомить Соню с особенностями digital-разработки. Как я уже говорил, она пришла из промышленного дизайна и не до конца понимала флоу создания продукта. Под флоу создания продукта я понимаю то, как прорабатываются задачи, собираются компоненты, раскладываются и передаются в разработку макеты и тд.

Я решил действовать последовательно, не накидывая на дизайнерку гору новой информации, а «взял за ручку» и предложил вместе поделать задачи.

Далее по шагам расскажу, что мы сделали, чтобы вывести Соню на новый уровень:

Шаг 1. Преобразование рабочей среды

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

Чтобы дать Соне поработать над основной задачей, мы:

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

Шаг 2. Внедрение системы раскладки макетов

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

Как-нибудь потом я подробнее расскажу об этой системе...

Шаг 3. Синхронизация с разработкой

Далее нужно было научиться передавать макеты в разработку. Потому что без реализации макеты так и остаются красивыми картинками. Здесь не было больших сложностей. Я помодерировал пару встреч с разработкой, показал как демонстрировать макеты и отвечать на прилетающие вопросы. Потом передал эту роль Соне, а сам «отошел в сторонку» и наблюдал.

Шаг 4. Убираем лишние переживания

Так как я на 3 месяца стал лидом всех дизайнеров компании, то логично было внедрить 1:1 и для штатного дизайнера. Мы начали созваниваться с Соней каждые 2 недели, чтобы ускорить процесс передачи обратной связи и оперативнее корректировать свою работу.

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

Шаг 5. Учимся у старших

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

Итог

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

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

Шаблоны

В отношении шаблонов для email-рассылок запрос от разработки звучал так: «Все блоки письма должны быть шаблонизированы, чтоб их можно было бы использовать меняя только контент». Чтобы загрузить разработку и начать внедрение рассылок, я собрал шаблоны для 5-и типов писем и к ним оформил небольшой UI-kit, в котором описал детали, анатомию и отступы.

Флоу

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

Далее я разбил схему по 3-м основным продуктам и добавил точки контакта с пользователями. А именно, «после какого события мы отправляем письмо или пуш» и что делает юзер после. В итоге, каждую схему можно было поделить на 2 части: 1) сверху — действия юзера; 2) снизу — действия компании. После, я перенес эти схемы в гугл-табличку и отдал копирайтерам для заполнения.

Итог

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

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

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

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

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

За короткий промежуток времени аутстафф-команда упорядочила дизайн-процесс, и как следствие ускорила time to market продукта.

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

Плюсы построения процессов аутстафф-командой:

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

___________________________________________________________________________________

Подписывайтесь на мой телеграм-канал ↓↓↓