Привет всем! Меня зовут Таня Конюшенко, я продуктовый дизайнер в Купере. В этой статье рассказываю о том, как открыла для себя дизайн-Discovery и внедрила его в своей продуктовой команде. Думаю, мой опыт будет полезен дизайнерам, которые много слышали о Disco, но не понимают, в чём его смысл.
![](https://habrastorage.org/getpro/habr/upload_files/b02/cfe/252/b02cfe252dd147c4e81004363aca08a8.png)
Ещё год назад я ничего не знала о Discovery, потому что работала в заказной разработке. О том, в чем разница между дизайнерами в агентстве и продукте, рассказывала в своей прошлой статье.
Когда я пришла в Купер (тогда он был ещё СберМаркетом), меня сразу познакомили с понятием Discovery, но смысла я в нем не увидела. Сейчас мое отношение кардинально другое. Discovery хорош, но нужно правильно его выстроить. Мой путь к идеальным процессам был тернистым…
Но давайте по порядку. Что входит в дизайн-Discovery и чем это отличается от общего Discovery команды?
![](https://habrastorage.org/getpro/habr/upload_files/8a9/d1e/547/8a9d1e5471d627d947acf4f63345452a.png)
Азы дизайн-Discovery
Все, кто работает в IT, знают, что в разработке новых фич продукта и поддержке старых выделяются два последовательных процесса:
Discovery — это все действия до начала разработки.
Delivery — все, что касается создания кода.
В Disco входит:
генерация идеи;
аналитика по существующим событиям, то есть по статистике, которую уже собрал продукт;
изучение проведенных исследований;
создание дизайнерских макетов;
количественные тесты макетов;
UX-интервью с респондентами;
согласования с командами;
заключительная подготовка макетов.
Если смотреть на этот процесс с точки зрения дизайнера, то обнаружатся два частично параллельных процесса: дизайн-Disco (этапы 1–3, 5 и 6) и дизайн-планирование (этапы 4, 7 и 8). В дизайн-Disco, помимо дизайнера, участвует продакт, аналитик и исследователь.
![](https://habrastorage.org/getpro/habr/upload_files/48c/76e/903/48c76e9037521dec6dfda44dfa40534b.jpeg)
Design-диско заканчивается в тот момент, когда мы ответили на вопросы «что?» и «почему?» — дальше остаётся отшлифовать решение, составить роадмеп обновления и реализовать то, что задумано.
Покажу, что такое дизайн-Disco, на конкретном примере.
История из жизни
На заключительном этапе оформления заказа в Купере покупатель должен выбрать временной диапазон, в который курьер привезет ему заказ.
![Старая реализация Старая реализация](https://habrastorage.org/getpro/habr/upload_files/952/982/97b/95298297b820f44d5745f179e8783bca.png)
Иногда люди пропускают этот блок, что мешает завершить заказ и ломает конверсию.
Мы провели A/B-тестирование, в котором реализовали предвыбор первого из возможных слотов. Количество ошибок упало, но при этом сильно выросло количество отмен.
На Discovery-встрече:
С аналитиком вывели гипотезу, что блок плохо заметен, поэтому пользователи его пропускают, но само время доставки имеет для них значение, а поэтому автоматический предвыбор ведет к росту отмен.
C продактом провели большой бенчмаркинг (анализ конкурентов), и я отрисовала множество самых разных решений.
Затем с продактом и исследователем выбрали несколько вариантов, которые должны были отправиться в исследования.
Главные критерии выбора — понятность, упрощение флоу и масштабируемость. Масштабируемость означает, что новый вариант отображения временных слотов вписывается в планы на развитие экрана (а мы можем планировать в рамках Discovery и на квартал, и на несколько кварталов вперед).
Для этой задачи мы сделали выбор в пользу количественных исследований, чтобы убедиться, что на практике у людей не возникнет проблем с изменением времени доставки. Было несколько итераций: отдельно проверяли на понимание, отдельно — на First Click, отдельно — на текстовые формулировки (какая читается однозначно).
На исследованиях два варианта показали почти одинаково хорошие результаты, поэтому вместо A/B-теста мы решили сделать A/B/C-тест и сравнить старый дизайн сразу с двумя новыми версиями.
![Варианты для теста Варианты для теста](https://habrastorage.org/getpro/habr/upload_files/0f7/3db/4f3/0f73db4f33c0e9d807bd98a05cc61488.png)
Выглядит логично, правда? Но есть нюанс: идеальный процесс не рождается сам по себе, его должен кто-то наладить…
И чаще всего это тот человек, который больше других страдает от неопределенности. Потому что построить процесс и управлять им может кто угодно, не только продакт. Нужно только иметь желание систематизировать информацию, ставить задачи, уточнять у всех статусы и вести встречи.
Стадия принятия: отрицание
Во время адаптации в Купере я по совету своего лида поставила встречи с тремя старшими дизайнерами, которые уже наладили такие процессы в своих командах. Они рассказали, что и как делают, а я с умным видом выслушала их и даже задала несколько вопросов.
А потом я пошла внедрять Disco в своих четырех небольших командах. Поставила встречу по Discovery на первый понедельник раз в две недели, а встречу по планированию — на второй понедельник. Получились спринт на Discovery и спринт на планирование, которые идут параллельно, со сдвигом в неделю.
Вверенные мне команды ранее состояли только из разработчиков и не работали с дизайнерами, поэтому дизайн-процессы были полностью в моей зоне ответственности.
В итоге каждую неделю я получала новые задачи на две недели вперед, они путались в голове и в спринтах. Ситуацию осложняло то, что продакты из моих команд периодически пропускали встречи, а потом ставили мне отдельные созвоны. Аналитики честно приходили, но я не понимала, что и когда у них спрашивать. А еще у нас на тот момент не было выделенного исследователя, и приходилось стучаться за помощью к другим командам.
Пожив в таком режиме около пяти месяцев, я приняла волевое решение удалить встречу по Disco из календарей. Все равно на ней мы делали то же самое, что и на планировании, — обсуждали задачи и прогресс по ним.
Процесс Discovery был признан нерабочим и непонятным. Я заподозрила, что это бесполезная встреча ради встречи.
![](https://habrastorage.org/getpro/habr/upload_files/bc0/776/cd9/bc0776cd907b2d43c68b63642531d7e5.png)
Без отладки Disco далеко не убежишь
Через пару месяцев после того, как я отвергла процесс дизайн-Discovery, у меня изменился состав команд: их осталось всего две на регулярной основе (если не считать периодическую помощь коллегам).
Казалось бы, так проще сфокусироваться. Но нет, переключение между задачами продолжилось: мы планировали одно, потом резко меняли курс на другое, а потом возвращались к первому.
И тут случилась демо-встреча, на которой старший дизайнер из нашей компании рассказала про свой опыт отладки Discovery-процессов внутри команды и предложила помочь всем заинтересованным.
У Даши есть статья о лайфхаках, как продуктовому дизайнеру улучшить Discovery-процессы в команде, это именно тот опыт, который стал отправной точкой для меня.
Мы созвонились. Мне было интересно не столько Discovery (я по-прежнему не видела в нем смысла), сколько то, как повысить продуктивность и сделать работу более понятной. А еще я хотела узнать, как она дважды получила оценку А+ по итогам Perf Review — это у нас аналог 5+.
Даша помогла мне составить список проблем:
бардак с приоритезацией задач;
гипотезы и требования теряются в личных сообщениях;
непонятно, чем занимается разработка;
нет отдельного места для хранения аналитики и результатов исследований;
аналитики и исследователи получают задачи без возможности поучаствовать в составлении гипотез;
никому не понятен результат работы (что происходит с задачей потом);
нет обсуждения итогов A/B-тестов — и непонятно, когда они начинаются и заканчиваются.
И тогда Даша предложила вернуть встречи по Discovery. Но для начала — только для одной команды.
Второй подход
Было бы нечестно сказать, что одна встреча прояснила все. Это не так. Скорее, я увидела дорогу, по которой могла пойти, чтобы что-то наладить.
Я собрала всех участников Disco-команды. Помимо меня, это продакт, исследователь, три аналитика и (урывками) редактор. И подготовила рабочую среду:
Завела отдельный чат, чтобы мы могли обсуждать задачи и новости, а также фиксировать резюме по встречам и договоренности на спринт.
Завела страничку во внутренней вики, где стала публиковать темы, а также ссылки на все результаты ресерчей и прошедших A/B-тестов.
Вернула регулярную встречу по Disco, чтобы обсуждать задачи, которые пойдут в работу, приоритеты, текучку, результаты A/B-тестов и исследований. Так как бэклог большой, собираться решили раз в неделю.
На титульной страничке в разделе Discovery в вики:
План задач на квартал
Планирование дизайна по спринтам
Задачи в Jira
Проджи в Jira
Все про инклюзивность
UX-исследования (разворачивающийся список ссылок с датами)
Аналитика (разворачивающийся список ссылок с датами)
А/б тесты (разворачивающийся список ссылок с датами)
Договоренности с другими командами
Беклог
Первые встречи прошли не идеально, но удачно. Аналитики принесли результаты последних ресерчей. Исследователь получил понимание, когда ему принесут макеты на исследование, и сориентировал нас по своей загрузке (так как он работает также с другой командой).
Вся команда стала не просто получать задачи, а обсуждать их уместность. Мы начали спорить!
Продакт как будто поверил в мои силы и предложил отныне самой фиксировать в функциональных требованиях для разработчиков изменения в дизайне и логику. И это оказалось полезным: разработчики внимательно смотрят ФТ и не очень внимательно — макеты.
Уже к четвертой встрече мы разгребли бэклог и поймали ритм, чтобы успевать проанализировать все необходимые данные до начала непосредственной работы над макетами.
![Пример тем, которые обсуждаются на встрече по итогам недели Пример тем, которые обсуждаются на встрече по итогам недели](https://habrastorage.org/getpro/habr/upload_files/907/4e2/2b8/9074e22b8ffcc41676edc607729ea3cd.png)
В этот момент я наконец-то поняла смысл дизайн-Discovery!
Дизайн-Discovery — это процесс, который помогает объединить команду, сделать работу над задачами прозрачной, вовремя информировать друг друга о результатах, систематизировать уже полученные данные и нормально планировать на несколько спринтов вперед.
Спустя полтора месяца в новом режиме я собрала фидбэк от коллег. Явных проблем не было, однако точки роста мы выделили. Не хватало структурированности встреч: четкой адженды, то есть списка тем, и тайминга (мы на протяжении всей встречи могли обсуждать только одну тему).
С хаосом в A/B-тестах покончено
У нас постоянно идут тесты. Поэтому в макетах одновременно живет десяток итераций, которые внезапно становятся (или нет) актуальными.
Более того, тесты идут не только у нас. Другие команды могут запускать что-то, относящееся к нашей зоне ответственности. Например, команда лояльности может добавить что-то в дизайн корзины, чтобы повысить свои метрики. У лояльности новый компонент в дизайне есть, а у меня — нет.
Я собрала прямо в Фигме таблицу для всех известных A/B-тестов, прямо или косвенно относящихся к нашей команде, и раз и навсегда перестала путаться, где актуальные, а где устаревшие макеты.
Все просто: заголовок, ссылка на макеты в Фигме, период A/B-теста, результат теста и имя продакта.
![](https://habrastorage.org/getpro/habr/upload_files/de8/d01/4b6/de8d014b6847fa970947502f2df08da7.jpeg)
Такая табличка не только помогает в синхронизации, но и визуализирует рабочий процесс и дает возможность потом обсудить с командой, сколько всего сделано и какие мы молодцы :) Вдобавок мне есть что принести на Performance Review.
Что еще я добавила
Я стала показывать команде промежуточные макеты, чтобы повысить чувство причастности. Это действительно работает, ребята смотрят с удовольствием!
Кроме того, я чаще стала ходить на дейли-встречи команды Delivery, чтобы держать руку на пульсе и как можно более прозрачно транслировать цели для команды Discovery. Это тоже эффективно: всем нравится видеть, как наработки превращаются в конечный продукт.
High level — выносить на встречи новости других команд, которые так или иначе нас касаются, и тоже повышать таким образом прозрачность.
Так в чем профит Discovery-процессов?
Нашу команду покинула неопределенность. У всех появилось четкое понимание, кто над чем работает, что случится после, что уже сделано к настоящему моменту, когда ждем следующие результаты и какие это результаты.
Мы ускорили дизайн-планирование, поскольку все задачи обсуждены и происследованы заранее. Продакт может менять приоритеты, но дополнительных встреч по обсуждению функционала в этом случае не требуется.
Также мы обдуманно отказываемся от части возможных задач, если аналитика показывает, что их бессмысленно брать в работу.
Некоторые фичи уходят в бэклог — опять же потому, что мы так решили, а не потому, что провалили планирование. Так бывает, если фича зависит от многих команд; например, если ошибка тянется с главной страницы, странно начинать ее чинить с корзины
![Пример аналитического ресерча, где видно, что конверсия ломается задолго до корзины с чекаутом (нашей зоны ответственности). Фича требует кросскомандной работы, а значит — сдвигается в планах Пример аналитического ресерча, где видно, что конверсия ломается задолго до корзины с чекаутом (нашей зоны ответственности). Фича требует кросскомандной работы, а значит — сдвигается в планах](https://habrastorage.org/getpro/habr/upload_files/e88/f72/a41/e88f72a417956845769e3f02ff67193f.png)
Новые члены команды быстрее вливаются в процесс, потому что он уже продуман и структурирован. И все члены команды знают, на что они могут влиять и в чем смысл их работы. Когда Discovery-процессы у нас уже устаканились, я получила обратную связь, что в нашей команде ребята более проактивны и чаще что-то от себя предлагают.
Больше ясности — больше удовлетворенности, согласны? А ещё после того, как я настроила этот процесс, смогла получить A+ за свою работу и наконец-то стала Senior-ом :)
Расскажите в комментариях о своих лайфхаках в выстраивании дизайнерских процессов!
Product&data команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.
Комментарии (8)
lair
13.08.2024 11:39+2Все, кто работает в IT, знают, что в разработке новых фич продукта и поддержке старых выделяются два последовательных процесса:
Discovery — это все действия до начала разработки.
Delivery — все, что касается создания кода.
Я вот работаю в IT и не знаю этого. Ну и да, вопрос, как вы это собираетесь делить в любой сколько-нибудь активной современной разработке, мне не понятно.
Tandjessa Автор
13.08.2024 11:39+3Предположу, что вы имеете в виду:
То, что, когда макеты уходят в разработку, работа дизайнера не заканчивается? Не заканчивается - могут вылезти доработки, например. Но это будет относиться в моем понимании к этапу Деливери.
Далее после успешного или неуспешного теста фича может снова вернуться на этап Дискавери, пройти его и пойти в Деливери.
Вот глобально и получается два процесса.
У вас иначе?
lair
13.08.2024 11:39+1Да, у нас иначе. Нет никакого смысла делить работу на дискавери и деливери, если больше половины времени эти процессы (анализа и разработки) идут параллельно.
Tandjessa Автор
13.08.2024 11:39Поняла, о чем вы – если говорить про команды, в которых процессы идут параллельно (например, в агентствах, где с одной стороны дизайнер рисует макеты, а с другой разработка сразу их кодит), то там действительно процессы нонспом перетекают из одного. в другой. Но в такой ситуации происходит много двойной работы.
Мы стараемся делать так, чтобы после того, как разработчик получил ФТ (функциональные требования), правки в макеты фичи не вносились. Не всегда получается, но очень стараемся.
И, когда, допустим, начинается вторая итерация, то это уже новый файл для дизайнеров, новое диско и новое ФТ для разрабов
lair
13.08.2024 11:39+1Поняла, о чем вы – если говорить про команды, в которых процессы идут параллельно
...то может быть станет понятно, что ваше утверждение про "все в IT знают" избыточно обобщено?
Но в такой ситуации происходит много двойной работы.
Или, наоборот, не происходит лишней. Но это старый спор.
Мы стараемся делать так, чтобы после того, как разработчик получил ФТ (функциональные требования), правки в макеты фичи не вносились.
То есть чистый водопад? Ну... можно, конечно, так работать, и есть люди, которым такого хочется, но жизнь обычно не согласна. Ну, в моем опыте.
exTvr
О, ну здравствуйте, дорогие синьористые дезингеры сбермаркета, вы как нельзя кстати.
Вам не икалось сегодня с утра? Почти при каждом входе лезет ваша сраная капча (что на десктопе - фиксированный оператор, что на планшете - мобильный инет, прокси и впн не используются ни там, ни там), которую и на десктопе не всегда с первого раза пройдёшь, что уж говорить про пенсионера, который с планшета пытается заказ в вашей лавке набить в браузере, не может зайти из-за капчи - она на планшете вообще нечитаема, плюётся и ругаясь последними словами оформляет заказ напрямую в ашане, без этой вашей купер-прокладки. Но зато у вас диско, фичи, бэклог, дейли и прочая модная словесность, ага.
Tandjessa Автор
Здравствуйте. Я переслала вашу проблему разработчикам. Надеюсь, помогут.
exTvr
Это не моя проблема - это ваша проблема, это вы теряете клиентов на ровном месте. Не думаю, что такое поведение вашего сайта наблюдается только у меня.