Growth-подход в продуктовом дизайне

Дмитрий Смирнов, Commercial Product Designer Lead в Skyeng

Знаю, что правильнее начинать материал с проблемы, но хочется подойти к ней через небольшую подводку: )

Занимаясь дизайном продукта, мне достаточно часто приходится наблюдать одну и ту же картину: продуктовому дизайнеру прилетает задача, и он начинает ее решать. Куча вариантов и правок, авторитарные мнения… часто на продуктовую команду приходит озарение, и вариант переделывается полностью, а затем или разбивается об тестирование или оказывается провальным по ключевым метрикам и — самое плохое — остается жить на продакшене, потому что «ну что-то показывает». Руки доходят до этого места только когда приходит время расти. Вижу в этом проблему и хочу подвести к комплексному решению — в дизайне продукта важнее понять, как делать правильно, до того как начать ломать голову над решением задачи. Надеюсь, что несколько тезисов, которые я сформулировал исходя из личного опыта, значительно сэкономят ваше время и усилят предлагаемые изменения.

Если перед вами стоит задача что-то улучшить, не стоит сломя голову предлагать решения, которые «точно сработают». Скорее всего, проблемы пользователя будут отличаться от тех, которые видите вы.

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

Спроектируйте свой вариант, основываясь на гипотезах из предыдущего исследования, и запустите новый тест.

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

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

Очень часто в транскрипциях немодерируемых исследований можно увидеть тезисы вроде: «О Боже, я вообще ничего не понял, но сделал то, о чем меня просили». При этом сам ответ на вопрос может показаться вам ценным. В модериуремых же рисерчах через какое то время респондент может просто «выгореть» и начать механически проходить задания. Уметь оценивать это поведение тоже очень полезно.

Целевая аудитория не ограничена скриптом или заданием, и с большой вероятностью будет вести себя по-другому. Поэтому если вы можете подкрепить свое исследование инсайтами с вебвизоров (Яндекс.Метрика, hotjar, fullstory), это значительно усилит качество вашего решения.

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

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

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

Положите результаты бенчмарка в любое удобное пространство (Miro/Figma/Notion) и зафиксируйте решения, которые считаете хорошими, а какие — сомнительными. Это станет источником инсайтов для решения задачи.

Если же бенчмарк получен от коллег, то полезно будет обратить внимание не на конкретную фичу как решение, а на процессы, которые привели к подобной реализации. Простое копирование может не сработать на вашем сегменте пользователей (об этом расскажу дальше).

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

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

Например, на участке, который вы хотите усилить, есть конверсия в 50%. Перед вами стоит комит в увеличении этой метрики на пять процентных пунктов.

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

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

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

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

Если вы сможете учитывать это при проектировании решений, у вас точно получится усилить продукт.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другой пример — команда, которая отвечает за первую оплату, и поэтому продает агрессивно. От этого может страдать продолжительность жизни пользователя в продукте (сделал первую оплату → вернул деньги/не оплатил в дальнейшем).

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

Если в вашей компании нет подобной культуры, то ее внедрение само по себе станет сильной точкой роста.

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

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

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

Риск неправильного решения будет существовать всегда, shit happens. Если ваша фича не отработала так, как вы задумали — не расстраивайтесь, сядьте и вместе с командой проанализируйте причины. С каждой разобранной ошибкой вы будете становиться профессиональнее, получать новые инсайты, и ваша экспертность будет накапливаться как снежный ком.

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

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

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

Каким бы сильным специалистом вы ни были, все ваши решения принимаются, оцениваются и реализуются с помощью команды. Выстраивайте доверительные отношения, челенджите друг друга, регулярно делитесь друг с другом инсайтами и совместно занимайтесь скорингом гипотез (ICE). Тогда ваши продукты всегда будут расти и приносить крутой импакт.