От идеи до результата: Как создавать продукты, которые нужны людям

От наблюдений к возможностям: как правильно сформулировать проблему

На планёрке руководитель поддержки положил на стол распечатку с жалобами клиентов.

— «Согласование опять тянется». «Почему так долго?» «Можно как-нибудь ускорить?» — прочитал он. — Ответ очевиден. Добавим кнопку «Ускорить согласование».

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

Через месяц кнопку выпустили.

Согласования по-прежнему задерживались.

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

Команда добавила действие. Но не убрала препятствие.

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

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

Жалоба — не диагноз

Слова пользователя важны. Но не каждое из них уже объясняет, что происходит.

Полезно различать четыре уровня.

Жалоба — то, как человек описывает неудобство: «Согласование ужасно медленное».

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

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

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

Эти уровни связаны, но не тождественны. «Нужно быстрее» может быть точным описанием переживания, но не объяснением причины. «Добавим кнопку» — уже решение, которое команда поспешно вывела из жалобы. Между ними должна появиться работа по исследованию.

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

Стена, на которой видны закономерности

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

• «Я не знаю, в какой категории провести эту покупку. Если выберу не ту, заявку вернут».

• «Сумму и поставщика я уже внёс в систему закупок. Здесь приходится вводить всё заново».

• «Я не хочу одобрять на глаз. Потом спросят с меня».

• «Заявка висит два дня, но я даже не понимаю, у кого именно».

• «Если лимит небольшой, я обычно спрашиваю коллегу в чате, можно ли так оформлять».

Сначала заметки казались набором частных раздражений. Затем на стене начали проступать группы. Одни цитаты говорили о нехватке ясности: какие правила действуют и чего ждать дальше? Другие — о повторной работе: одни и те же сведения вводятся или проверяются несколько раз. Третьи — о риске: пользователь боится ошибиться и нести последствия.

Это и есть синтез: не переписывание интервью в аккуратный документ, а поиск повторяющихся барьеров, которые помогают объяснить наблюдаемое поведение.

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

Работа со стеной может идти в несколько этапов.

1. Соберите конкретные свидетельства. Короткая цитата, наблюдаемое действие, контекст и источник. Например: «Во время оформления покупки сотрудник переключился в таблицу, чтобы проверить лимит; наблюдение на рабочем месте, 14 мая».

2. Разделите факты и трактовки. «Переключился в таблицу» — наблюдение. «Не доверяет продукту» — гипотеза.

3. Сгруппируйте заметки по барьерам. Не по формулировкам вроде «кнопка», «скорость» и «уведомления», а по тому, что человеку мешает выполнить задачу.

4. Назовите возможные паттерны. Например, «неясно, как принять безопасное решение» или «данные приходится собирать заново».

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

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

Не превращайте несколько цитат в «все пользователи»

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

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

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

Полезно держать рядом две колонки: «Что мы наблюдали» и «Как мы это объясняем». Если объяснение звучит увереннее, чем свидетельства, пометьте его как гипотезу.

Например:

Что мы наблюдали

Возможное объяснение

Что стоит проверить

Согласующий открывает заявку и возвращается к ней позже

Ему не хватает информации для решения

Какие сведения он ищет и где?

Сотрудник вводит сумму в двух системах

Данные нельзя перенести или доверять их переносу

Дублируется ли ввод у других ролей?

Пользователь пишет коллеге перед отправкой заявки

Он хочет подтвердить, что не нарушит правила

Какие правила вызывают сомнения?

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

Сформулируйте точку зрения пользователя

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

Практичный шаблон:

[Кто], находясь в ситуации [контекст], пытается [выполнить задачу или получить результат], но сталкивается с [подтверждённым барьером]. Из-за этого [последствие]. Сейчас он справляется с помощью [обходной путь или альтернатива], однако [что в ней не удовлетворяет потребность].

Для нашего примера:

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

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

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.