Как сделать так, чтобы продукт или фича работала для пользователя? Ответ в этой статье.

Привет, на связи Саша Солдатов, CEO REB8T! Сегодня расскажем про четыре инструмента, которые наша команда использует в работе на каждом проекте: JTBD, ICE-приоритизацию, User Flow и UX-гипотезы.

Огромное спасибо нашему Lead UX/UI дизайнеру Вере Ксенофонтовой, которая собрала этот материал и разложила всё по полочкам для вас и нашей команды!

А теперь, начнём!

1. Jobs To Be Done: думаем о пользователе

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

Когда заказчик приходит с ТЗ «добавьте личный кабинет», первое желание — открыть Figma и рисовать. Но в такие моменты надо себя останавливать и задавать вопросы:

Зачем пользователю личный кабинет? Что он хочет сделать? Что его не устраивает?

Ответы могут быть разными:

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

Всё это — разные работы, и под каждую нужно своё решение.

Два ключевых инструмента внутри JTBD

Job Story — формулируем решение через ситуацию. Это задача в конкретном контексте.  Например:

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

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

Как приоритизировать работы пользователя

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

— Насколько задача важна для пользователя (1–10 баллов)
— Насколько он доволен тем, как сейчас решает её (1–10 баллов)

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

• «Хочу получить конкретные инструменты для работы» — важность 10, довольство 2

• «Знать бэкграунд спикера, чтобы понять, насколько он научит» — важность 9, довольство 5

• «Быстро понять, есть ли нужный курс» — важность 7, довольство 3. 

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

2. ICE-приоритизация: берём в работу то, что даст максимум

Когда фичей много, а ресурсы ограничены, нужен способ выбрать, с чего начать. ICE (Impact, Confidence, Ease) — фреймворк для приоритизации. Каждую фичу оцениваем по трём критериям от 1 до 10, а итоговый балл считается как их произведение.

• Impact (влияние) — влияение фичи на ключевые метрики. LTV (суммарный доход от одного пользователя), Long-Term Retention (процент пользователей, которые остаются через N месяцев), Time to Value (время до первой полученной пользы).

• Confidence (уверенность) — шанс, что фича сработает. Основывается на результатах интервью и опросов, наличии похожих решений у конкурентов, сильных пользовательских сигналах.

• Ease (простота) — время и ресурсы на реализацию MVP-версии фичи.

Два корректирующих коэффициента

Помимо базовой формулы, добавляем два множителя, которые делают оценку точнее.

• Операционный коэффициент (0.1–1.0) — снижаем приоритет, если фича требует постоянной поддержки, модерации или производства тяжёлого контента. Например, UGC с ручной модерацией получает коэффициент 0.8.

• Ad hoc корректировка (0.1–2.0) — дополнительный множитель от команды или клиента. Если фича стратегически важна или уже есть договорённости с партнёрами — поднимаем выше 1.0. Если откладываем на потом — снижаем.

Пример из нашего проекта Mum’s Club

Mum’s Club — приложение для молодых родителей. Нам нужно было выбрать, что добавить в него в первую очередь. Думали между двумя вариантами:

• Статьи от экспертов. Impact 9, Confidence 10, Ease 7. ICE = 630. Коэффициенты: 1.0 × 1.5. Итог: 945. Контент уже частично готов, эксперты проверены, клиент считает это ключевой частью бренда — поднимаем в приоритете.

• UGC-контент. Impact 6, Confidence 7, Ease 8. ICE = 336. Коэффициенты: 0.8 × 0.1. Итог: 26.88. Идея интересная, но требует постоянной модерации, а клиент не готов запускать UGC в MVP — откладываем.

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

3. User Flow: карта пути пользователя от А до Б

Когда мы знаем, что хочет сделать пользователь (JTBD), и выдвинули гипотезы о том, как это лучше реализовать, самое время нарисовать карту пути. User Flow — это схема движения пользователя внутри продукта. На этом этапе определяем, какие экраны видит, где принимает решения, как выбор меняет состояние интерфейса.

С помощью User Flow можно увидеть, какие действия спрятаны слишком далеко, где пользователь теряется, а какие шаги можно убрать или объединить.

Из чего состоит User Flow

Момент первого контакта, будь то открытие приложение, переход по ссылке, нажатие на баннер. Дальше идут шаги — конкретные действия по пути к цели. В моментах выбора появляются развилки: пользователь принимает решение, и Flow разветвляется — например, авторизован он или нет, выбрал доставку или самовывоз. Финал — точка, в которой цель достигнута и человек получил то, за чем пришёл. Также указываем возможные ошибки и корнер-кейсы.

Как это работает на практике

Рассмотрим на примере нашего проекта «Самолёт Сити», геймификация онбординга сотрудников. Клиент обозначил 7 главных задач пользователя: последовательное прохождение материалов, возможность повторного просмотра, рейтинг, ачивки, техподдержка и мини-игры.

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

Четыре признака хорошего User Flow:

1. Важные функции доступны в один клик от стартового экрана.Запуск онбординга, повтор обучающих материалов, просмотр прогресса.

2. Задачи с общим контекстом объединены в один Flow. Просмотр ачивок и своего места в турнирной таблице.

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

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

Как построить User Flow

4. UX-гипотеза: формулируем предположение так, чтобы его можно было проверить

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

UX-гипотеза — это формализованное предположение о том, как конкретное изменение в интерфейсе повлияет на наблюдаемое поведение пользователя в контексте.

Как выглядит хорошая гипотеза?

Хорошая UX-гипотеза должна отвечать «да» на два вопроса.

1. Понятно ли, что именно меняется и в какой ситуации?

2. Понятно ли, как мы это заметим и на основе чего примем решение?

Если хотя бы на один ответ «не очень» — гипотеза сырая.

Пример

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

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

Виды гипотез:

Поведенческая — если мы изменим переменную X в сценарии Y, то пользователи сегмента Z начнут или перестанут делать А, что можно зафиксировать через B. Например: если заменить свободное поле выбора доставки на список с предустановленными вариантами, пользователи, оформляющие заказ впервые, будут реже останавливаться на этом шаге более чем 5 секунд и перестанут возвращаться назад.

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

Про приоритеты внимания — что пользователь замечает первым и что игнорирует. Например: если основной CTA визуально отделить от вторичных действий, пользователи станут реже выбирать второстепенные сценарии.

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

Через гипотезы мы принимаем более взвешенные решения и минимизируем влияние собственных когнитивных искажений.

Чек-лист перед запуском фичи

Четыре инструмента, которые мы разобрали, хорошо работают в связке. Вот вопросы, которые стоит задать себе до того, как открывать Figma.

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

Всем добра!