Поиск проблемы, которую стоит решать
Что это такое
Результат исследования сам по себе — ещё не ответ: из него нужно извлечь две вещи, которых одно исследование не даёт. Сколько проблема стоит и кто несёт эти издержки. Когда обе величины названы, на выходе получается формулировка проблемы с приложенными числами.
Почему это важно
Исследовательская сессия может вскрыть настоящую досаду, которая затрагивает четырёх человек, — и без размера команда не отличит её от досады, затрагивающей каждого, кто регистрируется. Тогда решать будет громкость истории. Оценка размера вскрывает и другой случай: издержки ложатся не на покупателя, а на сотрудников поддержки, партнёра или финансовую команду. От этого меняется, кого нужно убеждать, а иногда и стоит ли работа вообще того.
Ключевые идеи
Привяжите к каждой проблеме частоту и стоимость
Сколько людей с ней сталкиваются и во сколько обходится каждый случай. Даже грубые цифры переводят спор со вкусовщины на арифметику.
Проблема повторные покупатели заново вводят карту при оформлении
Частота 42% повторных покупателей, около 1 900 сессий в месяц
Стоимость ~40 секунд каждый раз, и 28% бросают на этом шаге
Выгода вернуть половину бросивших — это ~9 000 € заказов в месяц
Числа с указанной погрешностью гораздо полезнее прилагательных.
Отделяйте частоту от серьёзности
Редкая проблема, которая блокирует задачу, важнее частой, стоящей нескольких секунд. Однако сообщать нужно о обеих и не сводить их пока в один балл.
Найдите, кто платит
Боль чувствует не всегда тот, кто платит за исправление: иногда за работу платит организация, и дважды — один раз в продукте, другой раз временем поддержки. Назовите обоих, потому что бизнес-кейс будут судить по второму.
Пользователь 40 потраченных секунд, часть бросает оформление
Поддержка ~60 обращений в месяц про карту, по 5 минут каждое
Формулируйте проблему последней
Правильная формулировка звучит не как «нам нужны сохранённые карты», а как «повторные покупатели бросают оформление на шаге с картой, потому что должны заново ввести данные, которые уже давали». Первое — решение; второе оставляет место для запоминания данных без хранения карты.
Скажите, что вы сделали бы иначе
Если бы частота оказалась 4%, а не 42%, ответ был бы другим. Запишите порог сейчас, чтобы решение не пересматривали потом.
Практика
Оцените одну проблему по имеющимся данным
Возьмите проблему, в которую вы уже верите, и привяжите к ней частоту, стоимость одной единицы и того, кто её несёт. Источники — аналитика, журналы поддержки и несколько сессий, если их не хватает.
Готово, когда: у проблемы есть три числа с их источниками и заявленный порог, ниже которого вы не стали бы действовать.
Сформулируйте проблему
Сожмите оценённые данные в одно предложение, где названы человек, цель и препятствие и нет ни одного решения.
Готово, когда: из предложения явно возможны два разных решения, и ни одно из них не упомянуто.
Частые ошибки
- Проблемы без размера — побеждает самая громкая история; исправить: привяжите частоту и стоимость единицы.
- Смешение частоты и серьёзности — блокирующая проблема и мелкая помеха оказываются в одном ряду; исправить: сообщайте о обеих и ранжируйте явно.
- Учёт только издержек пользователя — издержки поддержки и партнёра исчезают из бизнес-кейса; исправить: назовите всех, кто платит.
- Формулировка проблемы, называющая решение — самый дешёвый вариант исключается до рассмотрения; исправить: назовите препятствие, а не функцию.
- Нет порога — решение снова обсуждают после того, как пришли числа; исправить: запишите число, ниже которого вы не стали бы действовать.
Что читать дальше
- Продуктовое исследование (04-product-process/04-product-discovery) — трек, который открывает эта глава.
- Дешёвая проверка решения (04-product-process/04-product-discovery/02-testing-a-solution-cheaply) — что делать, когда проблема оценена.
- Пользовательские исследования (03-design-ux/05-user-research) — методы, дающие эти данные.
- От выводов к решениям (03-design-ux/05-user-research/04-from-findings-to-decisions) — та же дисциплина группировки и подсчёта.