Метод

1. Понять задачу клиента

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

Задачу клиента выявляют либо на основании жалоб («боль клиента»), либо исследований потребностей.

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

Когда задача осознана, её необходимо зафиксировать, используя формулировку, с которой согласны остальные участники продуктовой команды. Для описания задач используйте один из фреймворков — User Story или Jobs to be Done.

Рекомендации

  • Общайтесь с клиентами.
  • Применяйте методологию customer development с самого начала работы над продуктом. Как минимум, проводите глубинные интервью для выявления потребностей клиентов. Не ленитесь.
  • Применяйте способ «пять почему» — иногда он помогает докопаться до причины, на основании которой можно сформулировать объективную задачу.

2. Определить метрики

Метрики бывают двух типов. Зафиксируйте оба:

  1. Ответьте на вопрос «Как мы поймём, что задача пользователя решена». Что хотите получить в виде решения.
  2. Цифровые метрики: относительные и абсолютные величины. Чаще это количественные показатели (финансовые, скорость, клиенты, время). Цифровые метрики отвечают на вопрос «Как мы поймем, что решение удачное».

Тут есть уловка: часто в презентациях за относительными величинами скрывают, преувеличивают или теряют объективный масштаб решения. Например, «прирост аудитории составил 3%» — это много или мало? Если это 150 000 человек (поселок городского типа, со школами и садиками, магазинами и своей администрацией) — то уже внушительное число, хотя кажется что мелочи. С другой стороны, «рост прибыли 300%», если это 300 рублей за месяц, уже сомнительный показатель. И снова, если 150 000 человек — статистическая погрешность в размерах аудитории всего продукта (допустим, посещения главной страницы поисковика в год), то этими размерами скорее всего можно пренебречь, хотя речь про население того самого поселка городского типа.

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

Жил-был лучший в мире лучник. Допустим, дело было в Японии – для остроты сюжета. Он мог поразить цель лучше всех с самой большой дистанции, и даже, как Робин Гуд, попасть в собственную стрелу. Лучник путешествовал по стране и удивлял своим мастерством окружающих, делился опытом.

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

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

— Что случилось, Лучник? — удивился крестьянин.

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

— Ты, наверное, говоришь про пораженные цели в самых причудливых местах? — внезапно догадался крестьянин.

— О да, ты прав — с сожалением молвил Лучник.

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

Рекомендации

  • Определите метрики сразу после того, как поняли задачу. Не рисуйте мишени вокруг стрел.

3. Сформулировать гипотезы решения

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

Проведите ментальную работу и придумайте, как минимум, три разных решения. Имейте в виду, что «развитие» одной идеи в виде прогрессивно меняющегося макета это одно решение, а не три (или сколько у вас получилось сделать разных макетов).

Может сработать такое упражнение:

  • Выключите компьютер, мобильник, попросите коллег не беспокоить вас 20 минут;
  • Возьмите карандаш и лист бумаги;
  • Придумайте за 20 минут 15–20 вариантов решения задачи. Пусть некоторые из них будут фантастическими — гораздо важнее, чтобы они не повторялись и позволяли взглянуть на проблему под разными углами.

Для начала попробуйте (но не ограничивайтесь) такие три подхода:

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

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

Рекомендации

  • Придумайте, как минимум, 3 разных решения задачи.
  • Проверьте ваши гипотезы.

4. Определить контекст

Customer Journey Map — это инструмент, позволяющий понять и зафиксировать контекст, в котором клиент пытается решить свою задачу. Обратите внимание, «решить свою задачу» ≠ «воспользоваться вашим интерфейсом или продуктом».

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

Если задача — проработка фичи в существующем приложении, то CJM погрузит в контекст и обеспечит бесшовное решение задачи. Часто, игнорируя контекст, дизайнеры и продуктовые менеджеры делают «новый раздел», размножая сущности, усложняя навигацию и порождая неразбериху в интерфейсе.

Рекомендации

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

5. Протестировать решение

Договоритесь с разработчиком и сделайте работающий прототип для проверки каждой гипотезы. Это не обязательно будет идеальное в техническом и эстетическом плане решение — важно сделать минимально жизнеспособный продукт (MVP), в тестирование которого можно вовлечь новых и существующих клиентов («применяйте методологию customer development с самого начала работы над продуктом», помните?).

Рекомендации

  • Не пренебрегайте тестированиями.
  • Настройте регулярный контакт с клиентами.

6. Проработать макеты

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

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


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