Привет всем! Меня зовут Таня Конюшенко, я продуктовый дизайнер в Купере. В этой статье рассказываю о том, как открыла для себя дизайн-Discovery и внедрила его в своей продуктовой команде. Думаю, мой опыт будет полезен дизайнерам, которые много слышали о Disco, но не понимают, в чём его смысл.

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

Когда я пришла в Купер (тогда он был ещё СберМаркетом), меня сразу познакомили с понятием Discovery, но смысла я в нем не увидела. Сейчас мое отношение кардинально другое. Discovery хорош, но нужно правильно его выстроить. Мой путь к идеальным процессам был тернистым…

Но давайте по порядку. Что входит в дизайн-Discovery и чем это отличается от общего Discovery команды?

Азы дизайн-Discovery

Все, кто работает в IT, знают, что в разработке новых фич продукта и поддержке старых выделяются два последовательных процесса:

• Discovery — это все действия до начала разработки.

• Delivery — все, что касается создания кода.

В Disco входит:

1. генерация идеи;

2. аналитика по существующим событиям, то есть по статистике, которую уже собрал продукт;

3. изучение проведенных исследований;

4. создание дизайнерских макетов;

5. количественные тесты макетов;

6. UX-интервью с респондентами;

7. согласования с командами;

8. заключительная подготовка макетов.

Если смотреть на этот процесс с точки зрения дизайнера, то обнаружатся два частично параллельных процесса: дизайн-Disco (этапы 1–3, 5 и 6) и дизайн-планирование (этапы 4, 7 и 8). В дизайн-Disco, помимо дизайнера, участвует продакт, аналитик и исследователь.

Design-диско заканчивается в тот момент, когда мы ответили на вопросы «что?» и «почему?» — дальше остаётся отшлифовать решение, составить роадмеп обновления и реализовать то, что задумано.

Покажу, что такое дизайн-Disco, на конкретном примере.

История из жизни

На заключительном этапе оформления заказа в Купере покупатель должен выбрать временной диапазон, в который курьер привезет ему заказ.

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

Мы провели A/B-тестирование, в котором реализовали предвыбор первого из возможных слотов. Количество ошибок упало, но при этом сильно выросло количество отмен.

На Discovery-встрече:

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

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

3. Затем с продактом и исследователем выбрали несколько вариантов, которые должны были отправиться в исследования.

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

Для этой задачи мы сделали выбор в пользу количественных исследований, чтобы убедиться, что на практике у людей не возникнет проблем с изменением времени доставки. Было несколько итераций: отдельно проверяли на понимание, отдельно — на First Click, отдельно — на текстовые формулировки (какая читается однозначно).

На исследованиях два варианта показали почти одинаково хорошие результаты, поэтому вместо A/B-теста мы решили сделать A/B/C-тест и сравнить старый дизайн сразу с двумя новыми версиями.

Выглядит логично, правда? Но есть нюанс: идеальный процесс не рождается сам по себе, его должен кто-то наладить…

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

Стадия принятия: отрицание

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

А потом я пошла внедрять Disco в своих четырех небольших командах. Поставила встречу по Discovery на первый понедельник раз в две недели, а встречу по планированию — на второй понедельник. Получились спринт на Discovery и спринт на планирование, которые идут параллельно, со сдвигом в неделю.

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

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

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

Процесс Discovery был признан нерабочим и непонятным. Я заподозрила, что это бесполезная встреча ради встречи.

Без отладки Disco далеко не убежишь

Через пару месяцев после того, как я отвергла процесс дизайн-Discovery, у меня изменился состав команд: их осталось всего две на регулярной основе (если не считать периодическую помощь коллегам).

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

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

У Даши есть статья о лайфхаках, как продуктовому дизайнеру улучшить Discovery-процессы в команде, это именно тот опыт, который стал отправной точкой для меня.

Мы созвонились. Мне было интересно не столько Discovery (я по-прежнему не видела в нем смысла), сколько то, как повысить продуктивность и сделать работу более понятной. А еще я хотела узнать, как она дважды получила оценку А+ по итогам Perf Review — это у нас аналог 5+.

Даша помогла мне составить список проблем:

• бардак с приоритезацией задач;

• гипотезы и требования теряются в личных сообщениях;

• непонятно, чем занимается разработка;

• нет отдельного места для хранения аналитики и результатов исследований;

• аналитики и исследователи получают задачи без возможности поучаствовать в составлении гипотез;

• никому не понятен результат работы (что происходит с задачей потом);

• нет обсуждения итогов A/B-тестов — и непонятно, когда они начинаются и заканчиваются.

И тогда Даша предложила вернуть встречи по Discovery. Но для начала — только для одной команды.

Второй подход

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

Я собрала всех участников Disco-команды. Помимо меня, это продакт, исследователь, три аналитика и (урывками) редактор. И подготовила рабочую среду:

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

• Завела страничку во внутренней вики, где стала публиковать темы, а также ссылки на все результаты ресерчей и прошедших A/B-тестов.

• Вернула регулярную встречу по Disco, чтобы обсуждать задачи, которые пойдут в работу, приоритеты, текучку, результаты A/B-тестов и исследований. Так как бэклог большой, собираться решили раз в неделю.

На титульной страничке в разделе Discovery в вики:

• План задач на квартал

• Планирование дизайна по спринтам

• Задачи в Jira

• Проджи в Jira

• Все про инклюзивность

• UX-исследования (разворачивающийся список ссылок с датами)

• Аналитика (разворачивающийся список ссылок с датами)

• А/б тесты (разворачивающийся список ссылок с датами)

• Договоренности с другими командами

• Беклог

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

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

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

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

В этот момент я наконец-то поняла смысл дизайн-Discovery!

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

Спустя полтора месяца в новом режиме я собрала фидбэк от коллег. Явных проблем не было, однако точки роста мы выделили. Не хватало структурированности встреч: четкой адженды, то есть списка тем, и тайминга (мы на протяжении всей встречи могли обсуждать только одну тему).

С хаосом в A/B-тестах покончено

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

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

Я собрала прямо в Фигме таблицу для всех известных A/B-тестов, прямо или косвенно относящихся к нашей команде, и раз и навсегда перестала путаться, где актуальные, а где устаревшие макеты.

Все просто: заголовок, ссылка на макеты в Фигме, период A/B-теста, результат теста и имя продакта.

Такая табличка не только помогает в синхронизации, но и визуализирует рабочий процесс и дает возможность потом обсудить с командой, сколько всего сделано и какие мы молодцы :) Вдобавок мне есть что принести на Performance Review.

Что еще я добавила

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

Кроме того, я чаще стала ходить на дейли-встречи команды Delivery, чтобы держать руку на пульсе и как можно более прозрачно транслировать цели для команды Discovery. Это тоже эффективно: всем нравится видеть, как наработки превращаются в конечный продукт.

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

Так в чем профит Discovery-процессов?

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

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

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

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

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

Больше ясности — больше удовлетворенности, согласны? А ещё после того, как я настроила этот процесс, смогла получить A+ за свою работу и наконец-то стала Senior-ом :)

Расскажите в комментариях о своих лайфхаках в выстраивании дизайнерских процессов!

Product&data команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.