Или как дизайнеру продукта решать проблемы бизнеса и причём тут заводы с конвейерами

Представь, к тебе пришли с задачей: в приложении низкие показатели активации пробной подписки. Пользователи скачивают приложение, но мало кто начинает триал. Тебя просят сделать что-то с онбордингом, ведь именно там последняя возможность донести ценность.

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

Привет я продуктовый дизайнер в Альфа-Инвестициях, хочу поделиться знаниями о фундаментальной вещи, которая лежит в основе продуктового дизайна и гораздо важнее навыков UI, ведь кто будет пользоваться вашей красотой, если пользователь не видит ценности всего продукта в целом? Обо всём по порядку.

Откуда вообще возникает потребность в интерфейсах?

Всегда надо держать в голове, что пользователям не нужен ваш продукт как таковой, им нужно решение проблемы, которую ваш продукт продаёт (вспоминаем Jobs To Be Done). Исходя из этого — любая бизнес или дизайн‑задача исходит из потребности заработать на решении проблемы пользователя. Иначе откуда у вас зарплата? Это не цинизм, а реальность из которой исходит экономика любой компании.

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

Осознавая такое положение дел и подход, шестерёнки в голове начнут крутиться иначе. В начале перед рисованием макетов нужно всегда задавать себе вопрос: «Какую проблему пользователя я решаю и как это влияет на деньги компании?», а не «Как сделать этот экран/лендинг/форму лучше?».

Что происходит в продукте на самом деле?

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

Тем, что мы можем решать проблему там, где её просто нет. 

Путь пользователя — это связанная цепочка шагов. От момента, как пользователь впервые услышал о нашем или схожем продукте и до того, как словил «Ага‑момент» и стал платящим пользователем, генерируя прибыль компании.

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

А теперь представь, что твой диджитал IT продукт (или любой другой) — это завод. С конвейерами, станками, рабочими. Как бы круто ни работали все остальные звенья завода, производительность всего предприятия упирается в самый медленный из конвейеров и не важно как работают все остальные. Или же скорость всей стаи волков определяется самым медленным членом стаи.

Этот феномен Эллияху Голдратт, описал в своей книге «Цель», как Теория ограничений, о которой и пойдёт речь дальше.

Теория ограничений, как база продуктового мышления

Теория ограничений — это способ смотреть на любую систему как на конвейер. Весь завод становится убыточным из‑за самого неэффективного конвейера. Ускорять быстрые конвейеры бессмысленно — общая эффективность завода от этого не вырастет.

Допустим, путь пользователя в нашем продукте выглядит так: страница сайта (с трансляцией основной ценности продукта, с целью перевести пользователя в регистрацию) → регистрация (важно: здесь он ещё не активирован) → онбординг (с самой явной ценностью и решением основной боли пользователя) → использование продукта (осознание выгоды и пользы — «Ага момент») → оплата (активация в продукт).

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

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

1. Понимаем проблему и ищем ограничение

Это самый важный и самый недооценённый шаг. Дизайнеры могут его пропускать и сразу приступать к генерации решений и макетов.

Что делать: 

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

• Смотрим на весь путь и опыт пользователя в целом, а не на отдельный экран. Работай с метриками, посмотри воронку от начала до конца. Например, собери VOC по всему сценарию, узнай о возражениях пользователей в поддержке. Где самый большой отвал и самый низкий VOC? Это и есть кандидат в узкое место.

Важный нюанс: если за метрику успешности сценария мы берём CR, то считать её нужно в абсолюте. Например, если приложение скачало 100 000 человек, а купили подписку 500 — это 0,5%. Не имеет значения, что между шагами онбординга CR 80%. Имеет значение, что из 100 000 осталось 500. Где потерялись остальные 99 500?

Где искать проблемы: аналитика продукта (метрики), поведение пользователей внутри сессии, жалобы в поддержку, отзывы, интервью с целевыми клиентами (важно — желательно общаться с теми, кто не купил подписку, а не с лояльными пользователями).

2. Формируем гипотезу и решаем, как использовать узкое место эффективно

Узкое место найдено. Теперь нужно понять, почему оно узкое.

Не факт, что решение плохое — возможно, оно просто не работает на пользователя. Люди не доходят до шага, где раскрывается ценность. Видят форму из 8 шагов без объяснения, что получат в конце — и уходят. Не потому, что форма длинная (хотя может быть такой из‑за специфики продукта), а потому что нет мотивации заполнять 8 шагов. Или мы просим заплатить, не дав попробовать продукт и почувствовать выгоду.

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

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

Гипотеза должна иметь: действие, результат которого влияет на заранее определённую метрику успешности. «Если изменим сторителлинг на продуктовой странице сайта (действие), то пользователи будут лучше понимать ценность продукта (результат) и CR в открытие брокерского счёта вырастет на 20% (влияние на метрику успешности)»

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

3. Исключи противоречия в остальном сценарии

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

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

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

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

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

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

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

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

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

• Объяснив коллегам сколько стоит привлечение пользователя, который никогда не заплатит можно добиться многих компромиссов в принятии решений.

• Если не выходит напрямую — можно выбрать путь эскалации, привлеки продакта со стороны бизнеса или тимлида из Центра Компетенций.

4. Следи за успешностью своего решения и повторяй цикл

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

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

Запустили решение — смотрим, сдвинулась ли она. Не «кажется, стало лучше», а конкретно: было 5%, стало 7%. Если не сдвинулась — это тоже результат. Значит, либо решение не попало в проблему, либо ограничение было не там, где думали. Возвращаемся к первому шагу.

Если сдвинулась — смотрим, куда переместилось по сценарию узкое место. Подняли конверсию в регистрацию, а что с активацией в оплату подписки? Пользователи регистрируются, но не возвращаются. Поработали над первой сессией — вылез низкий Retention. Улучшили удержание — упёрлись в средний чек.

И так по кругу.

А точно ли это зона ответственности продуктового дизайнера?

Может показаться, что это всё компетенции продакта или аналитика. Но дело в том, что каждый макет, который ты рисуешь, — это изменение в продукте. А каждое изменение в продукте стоит денег.

Посчитай: команда из десяти человек в условной корпорации обходится бизнесу в 5 миллионов рублей в месяц (суммы взяты из головы). Если за месяц команда проверяет четыре гипотезы, то это значит, что одна гипотеза стоит больше миллиона. А по статистике, из десяти гипотез «выстреливает» лишь одна. Это значит, что цена ошибки, когда ты решаешь не ту проблему, измеряется миллионами.

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

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

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

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

Читайте также: