Через гипотезы к проду. Как быть дизайнером в Growth Team

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

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

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

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

• Поговорить с друзьями об их опыте, например, как используют Кошелёк, что мотивирует пользоваться, есть ли то, что раздражает, что нравится в других приложениях и т.п. Учитываю, что выборка может быть нерепрезентативна, но это уже толчок к размышлениям и быстрая проверка правильности направления.
• Поговорить с пользователями. Для меня интервью с пользователями — это большой источник вдохновения и идей. У нас в команде был интересный опыт, когда мы с продакт-менеджером после запуска продукта писали в соцсети пользователям с просьбой дать фидбек по новой функциональности. Это не лучший способ набрать респондентов на интервью, и мало кто нам ответил. Но те, кто ответили, подсветили наиболее критичные моменты в фиче, например, что без сортировки предложений по гео фича попросту не взлетит.

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

• Аналитика. В Кошельке я начала пользоваться системой продуктовой аналитики Amplitude. Могу разобраться в дашборде и воронке от аналитика. Могу собрать простейший срез по тому, как сейчас пользуются фичей пользователи. Полезно видеть не только конкретные цифры по итогам эксперимента, но и откуда приходят в целевой раздел пользователи, на каком шаге сценария происходит отвал аудитории, на какие экраны ходят больше всего и где до пользователей проще дотянуться. Сразу появляется масса идей, как на это можно повлиять.
• Общение с другими командами. В любом продукте есть идеи, о которых все знают, говорят, но до их реализации руки не доходят. Я фиксирую такие идеи, могу собрать по ним референсы, накидать драфты, потом обсудить с командой, и тогда у них есть шанс стать экспериментом.

После того, как мы в команде выбрали идею для эксперимента, я начинаю проектировать сценарии. Каждый день мы синкаемся с бизнес-аналитиком, проговариваем основные и корнер-сценарии. В сложных случаях могу подготовить прототипы в Figma или ProtoPie, чтобы понимать путь пользователя от точки А в Б. Примерно раз в неделю я показываю свой прогресс команде разработки и получаю фидбек по реализации, иногда показываю части интерфейсов на стендапе. На этом этапе моя работа не сильно отличается от процессов в обычной продуктовой команде, кроме того, что мы стараемся максимально часто синхронизироваться, чтобы быть в одном контексте. Я выстраиваю свою работу так, чтоб команда разработки была в курсе моих задач, и у них уже на этапе проектирования создавалось ощущение, что мы работаем вместе над проектом.

У команды Growth есть свои особенности, но на дизайн-процессы это не влияет. Я наравне с другими ребятами прохожу груминги с дизайнерами, показываю промежуточные решения, заношу компоненты в дизайн-систему, готовлю для них документацию и получаю апрувы на дизайн-чеках от дизайн-гильдии. Эти процессы не быстрые, но позволяют мне творить в коннекте с командой, а другим дизайнерам давать свежий взгляд на проект. Чтобы сохранять дизайн консистентным и быстро проходить этапы согласования, я стараюсь использовать компоненты из дизайн-системы. Если всё-таки приходится заводить новую сущность, например, карточку товара, то завожу компонент в дизайн-систему, готовлю состояния, пишу техническую документацию и гайды. Такой подход позволяет переиспользовать компоненты из наших проектов другими продуктовыми командами.

Чтобы приступить к проверке гипотез, мы верстаем новый экран в стиле нашего приложения и размещаем его в вебе. На собранную веб-страничку ведём часть пользователей прямо из приложения — она открывается в WebView, и пользователь считает, что он всё ещё внутри приложения, в Кошельке.

Если всё просто, сами собираем тестовый экран на Tilda, если нужно что-то посложнее, подключается продакт-менеджер и собирает всё нужное на Python — хотя бы несколько разделов. Чтобы рассказать о новой фиче мы используем пуш-сообщения. И вуаля, минимальный набор для тестирования гипотез готов. Дальше приведу примеры экспериментов.

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

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

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

Посмотрели на результаты и сильно переосмыслили этап, когда пользователь — новичок и ещё только знакомится с разделом, пока не пользуется избранным, не выводил деньги. Сделали блок баланса компактным, добавили подборку с самыми выгодными предложениями. Раздел работает, им занимается другая команда, его продолжают совершенствовать.

Когда мы генерим гипотезы, то часто фантазируем, каким бы хотели видеть Кошелёк в идеальном мире. Какую пользу он мог бы приносить людям? Так мы обсуждали, как просто бывает попросить скидочную карту на кассе у соседа и как было бы круто повторить этот сценарий в Кошельке. Так мы решили проверить идею, будут ли пользователи делиться своей картой, если им придет запрос от другого человека в приложении. Я собрала экран в Tilda с объяснением для пользователя, что будет с его скидочной картой, если он ею поделится. Важно было подсветить, что тот, кто запрашивает, сможет получить по карте скидку, а накопленные баллы списать не сможет. Настроили пуши, которые вели на страничку в Tilda и запустили тест. Получили результат: 70% пользователей поделились своей картой.

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

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

Как команда роста мы готовы к тому, что большинство наших экспериментов провалятся, поэтому нужно пробовать многое, чтобы эксперимент вырос в полноценный проект с качественной реализацией. Самое сложное в работе, и чему я продолжаю учиться, — это фокус на действительно важных вещах. Не тратить время на полишинг деталей, чтобы потом на A/B-тестировании выяснить, что у версии экрана с коротким текстом и кнопкой конверсия выше в два раза. Не нужно обсуждать цвет скамеек при проектировании атомной электростанции.

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

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