Привет всем! Меня зовут Таня Конюшенко, я продуктовый дизайнер в Купере. В этой статье рассказываю о том, как открыла для себя дизайн-Discovery и внедрила его в своей продуктовой команде. Думаю, мой опыт будет полезен дизайнерам, которые много слышали о Disco, но не понимают, в чём его смысл.
Ещё год назад я ничего не знала о Discovery, потому что работала в заказной разработке. О том, в чем разница между дизайнерами в агентстве и продукте, рассказывала в своей прошлой статье.
Когда я пришла в Купер (тогда он был ещё СберМаркетом), меня сразу познакомили с понятием Discovery, но смысла я в нем не увидела. Сейчас мое отношение кардинально другое. Discovery хорош, но нужно правильно его выстроить. Мой путь к идеальным процессам был тернистым…
Но давайте по порядку. Что входит в дизайн-Discovery и чем это отличается от общего Discovery команды?
Азы дизайн-Discovery
Все, кто работает в IT, знают, что в разработке новых фич продукта и поддержке старых выделяются два последовательных процесса:
Discovery — это все действия до начала разработки.
Delivery — все, что касается создания кода.
В Disco входит:
генерация идеи;
аналитика по существующим событиям, то есть по статистике, которую уже собрал продукт;
изучение проведенных исследований;
создание дизайнерских макетов;
количественные тесты макетов;
UX-интервью с респондентами;
согласования с командами;
заключительная подготовка макетов.
Если смотреть на этот процесс с точки зрения дизайнера, то обнаружатся два частично параллельных процесса: дизайн-Disco (этапы 1–3, 5 и 6) и дизайн-планирование (этапы 4, 7 и 8). В дизайн-Disco, помимо дизайнера, участвует продакт, аналитик и исследователь.
Design-диско заканчивается в тот момент, когда мы ответили на вопросы «что?» и «почему?» — дальше остаётся отшлифовать решение, составить роадмеп обновления и реализовать то, что задумано.
Покажу, что такое дизайн-Disco, на конкретном примере.
История из жизни
На заключительном этапе оформления заказа в Купере покупатель должен выбрать временной диапазон, в который курьер привезет ему заказ.
Иногда люди пропускают этот блок, что мешает завершить заказ и ломает конверсию.
Мы провели A/B-тестирование, в котором реализовали предвыбор первого из возможных слотов. Количество ошибок упало, но при этом сильно выросло количество отмен.
На Discovery-встрече:
С аналитиком вывели гипотезу, что блок плохо заметен, поэтому пользователи его пропускают, но само время доставки имеет для них значение, а поэтому автоматический предвыбор ведет к росту отмен.
C продактом провели большой бенчмаркинг (анализ конкурентов), и я отрисовала множество самых разных решений.
Затем с продактом и исследователем выбрали несколько вариантов, которые должны были отправиться в исследования.
Главные критерии выбора — понятность, упрощение флоу и масштабируемость. Масштабируемость означает, что новый вариант отображения временных слотов вписывается в планы на развитие экрана (а мы можем планировать в рамках 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-менеджеров.
