Источник
Как продакты, аналитики и дизайнеры создают ценность через мышление
Конспект выступления Кирилла Николаева о JTBD, качестве решений пользователя и осмысленном трении в интерфейсах.
Источник
Как продакты, аналитики и дизайнеры создают ценность через мышление
Конспект выступления Кирилла Николаева о JTBD, качестве решений пользователя и осмысленном трении в интерфейсах.
Продуктовая ценность рождается не только из скорости сценария, но и из качества решений, которые пользователь принимает внутри продукта. В ряде доменов «сделать в один клик» не улучшает опыт, а увеличивает риск ошибок. Поэтому ключевой фокус этой главы: как проектировать осмысленное трение, которое помогает пользователю принять более точное и безопасное решение.
TL;DR
- JTBD смещает фокус с «какую фичу сделать» на какую работу пользователь пытается выполнить.
- Простота интерфейса полезна не всегда: в рискованных действиях нужна осознанность, а не мгновенный клик.
- PM, аналитик, дизайнер и инженерная команда совместно отвечают за качество решения, а не за отдельные локальные метрики.
- Сильная продуктовая система измеряет не только конверсию, но и цену ошибок, возвраты, отмены и долгосрочные эффекты.
JTBD как рамка продуктового мышления
В подходе Jobs To Be Done команда стартует не с backlog фич, а с формулировки работы, которую пользователь пытается выполнить в конкретном контексте. Это переводит обсуждение из плоскости output в плоскость outcome: изменилось ли поведение пользователя, снизился ли риск ошибки и выросла ли полезность результата.
Output-режим
«Сделать быстрее», «добавить кнопку», «поднять конверсию» без связи с качеством решения пользователя.
Outcome-режим
«Помочь пользователю принять корректное решение» с учетом риска, контекста и долгосрочного эффекта.
Ключевой тезис
Если ускорять ошибочное действие, продукт не становится лучше. Он просто быстрее масштабирует неверный выбор.
Когда «трение» нужно, а когда мешает
Убираем трение
Для частых, безопасных и обратимых действий: повседневные операции, повторяющиеся задачи, low-risk сценарии.
Добавляем осмысленное трение
Для дорогих или необратимых действий: финансовые операции, смена критичных настроек, удаление данных, юридически значимые шаги.
Формы полезного трения
Подтверждение намерения, понятные предупреждения, превью последствий, выбор из осмысленных альтернатив.
Формы вредного трения
Лишние поля и шаги без смысла, непонятные формулировки, скрытые ограничения, «капча ради капчи».
Роли в создании ценности
Product Manager
Формулирует JTBD, приоритеты и границы trade-offs. Цель PM не «простота любой ценой», а устойчивая ценность и управляемый риск.
Аналитик
Переводит гипотезы в измеримую систему сигналов: ошибки, возвраты, отмены, time-to-decide, downstream impact на retention и выручку.
Дизайнер
Проектирует когнитивную механику интерфейса: пояснения, предупреждения, подтверждения и микрообучение в точках принятия решения.
Инженерная команда
Обеспечивает наблюдаемость, экспериментальную инфраструктуру, контроль рисков и возможность безопасного отката при неудачной гипотезе.
Что это означает для техлида и Staff+
Инфраструктура экспериментов
Feature flags, cohort rollout, быстрый A/B-тест, механизм аварийного отключения.
Наблюдаемость качества решения
Метрики не только про клики: wrong actions, отмены, возвраты, time-to-decide, повторные попытки.
Explainability-след
Фиксация, какие подсказки, ограничения и подтверждения влияли на критичное решение пользователя.
Ритуалы совместного решения
JTBD-бриф, единый эксперимент-план и регулярный decision review по фактам, а не по мнениям.
Антипаттерны
Оптимизация на клики
Локальная метрика растет, а качество решения пользователя снижается.
Простота ради простоты
Убирается важное трение там, где нужна осознанность, и растет цена ошибки.
Feature-driven без JTBD
Исправляются симптомы, но не закрывается реальная работа пользователя.
Операционная рамка: от гипотезы к решению
- Зафиксируйте JTBD-бриф: контекст, задача пользователя, критерии успеха и цена ошибки.
- Определите точки, где нужно ускорить путь, и точки, где необходимо осмысленное подтверждение.
- Запустите эксперимент с наблюдаемостью: cohort-разделение, события качества решения, маркеры риска.
- На decision review сравните краткосрочные метрики и долгосрочные сигналы.
- Примите инженерное решение: масштабировать, корректировать механику или откатывать подход.
Практика на 2 недели
- Выберите один критичный пользовательский сценарий с высокой ценой ошибки.
- Соберите JTBD-карту и определите текущие слабые точки принятия решения.
- Сделайте прототип с осмысленным трением в одной критичной точке.
- Проведите A/B-тест и сравните качество решений, а не только скорость прохождения.
Связанные главы
Краткий вывод
- Ценность создается, когда продукт помогает принять более качественное решение, а не только быстрее кликнуть.
- JTBD и осмысленное трение дают общий язык для PM, аналитики, дизайна и инженерии.
- Для техлида ключевая роль в создании инфраструктуры проверки гипотез и наблюдаемости качества решений.