Протокол о потребностях пользователя, так называемые «проблемные утверждения» (user need statements, problem statements), является мощным и основополагающим инструментом в деле идентификации проблем клиента и поиска способов ее решения.
В дизайн-мышлении (собственно, как и в любом другом процессе разработки продукта) крайне важным является определение проблемы, которую вы своим продуктом и собираетесь решать, причем идентифицировать проблему необходимо, как вы понимаете, до того, как в разработку решения будут вложены финансы и время (создание продукта, который решает другую проблему, можно считать неудачей). Такой подход позволяет получить максимальный результат от всех затраченных средств и уменьшает вероятность возникновения разногласий внутри самой команды разработчиков на этапах прототипирования, тестирования и реализации продукта.
Данный протокол вступает в игру на втором этапе дизайн-мышления — этапе определения; разработчики согласовывают друг с другом свои взгляды на продукт и только потом продолжают работу по идеации (формированию идеи). Неважно, какой термин вы выберете (потребность пользователя или проблема) — важно, чтобы вся команда воспринимала этот аспект одинаково.
Именно в проблемных утверждениях происходит идентификация того, кем является пользователь, какую он испытывает потребность и почему она так важна для него. На данном этапе вы должны прийти к пониманию того, для решения какой проблемы будет предназначен ваш продукт, и определить метрики, позволяющие измерить ваш успех в ходе всего процесса проектирования.
Более того, главная цель протокола — отразить то, что вы собираетесь решать, а не как вы будете это делать. Этот документ поможет вам обрести более глубокое понимание проблемы и впоследствии — развить из конкретного функционала полноценный продукт. Например, в протоколе не будет написано, что пользователям нужен раскрывающийся список: там будет указано, что они должны видеть перед собой перечень доступных вариантов и выбрать один из них; будет указано не то, что им нужен дашборд, а то, что вся нужная им информация была бы доступна в одном месте.
Если будете фокусироваться только на конечных продуктах, то рискуете закончить с неоптимальными проектами. Цель идеации — исследовать идею, поэтому не стоит слишком рано ограничивать себя, остановив свой выбор на каком-либо решении.
Содержание статьи
Преимущества разработки протокола
1. Узнать пользователя и его потребности
2. Добиться согласованности в работе всей команды
3. Определить критерий успеха
1. Определите область
2. Провести качественные исследования (или собрать результаты уже проведенных)
3. Генерируйте и комбинируйте
4. Подвергните критике свои утверждения
5. Добавьте методы измерения
Утверждения о потребностях пользователей в действии
Пример 1: исследование
Пример 2: старт проекта
Пример 3: ретроспектива
Утверждения о потребностях пользователей в сравнении с задачами разработки
3 компонента
Традиционный протокол состоит из 3-ех компонентов: 1) пользователь, 2) потребность, 3) цель: [пользователь] и [потребность] объединяются, чтобы конкретная [цель] была достигнута.
Например, [Алена, многозадачность, разбирающаяся в технологиях мама] испытывает потребность в том, чтобы [быстро и уверенно сравнивать варианты, не покидая зону комфорта], и это позволит ей [тратить больше времени на действительно важные дела].
Пользователь должен соответствовать определенной персоне или реальному сегменту пользователей, исследование которого вы провели. Не будет лишним придумать короткий и запоминающийся слоган, который не даст всем остальным в команде забыть, кем является пользователь, особенно, если утверждение о потребности будет использоваться крупной компанией или заинтересованными сторонами, которые отдалены от исследования:
- Алена, многозадачность, разбирающаяся в технологиях мама;
- Мария, исследователь, жаждущий приключений;
- Антон, активный ютубер в городе.
Потребность должна быть реальной, быть свойственна пользователям, не должна быть «высосана из пальца» и не должна иметь формулировку решения. Держитесь подальше от каких-либо «фич», особенностей интерфейса или технологий. Например, возможными целями могут быть:
- иметь возможность быстро и уверенно сравнивать варианты, не покидая зону комфорта;
- встречаться и общаться с другими людьми, не обделяя временем семью;
- получить согласие других при принятии важного решения.
Запомните: пользователи не всегда знают, что им нужно, даже если говорят об обратном. Генри Форд говорил: «Если бы я спросил людей, чего они хотят, то они попросили бы более быструю лошадь».
Цель является результатом удовлетворения этой потребности. Она должна быть основана на сопереживании. Попробуйте выйти за пределы очевидного — что именно может сделать пользователь при помощи вашего решения? Например, подумайте о надеждах, страхах и мотивациях пользователя:
- иметь больше времени на действительно важные вещи;
- чувствовать себя уверенно, ужиная с новыми друзьями;
- начать движение к мечте всей жизни, на которую обычно никогда не хватало времени.
Преимущества разработки протокола
Разработка протокола о потребностях пользователя и сам протокол представляют большую ценность для вашей команды и организации. Он позволяет:
1. Узнать пользователя и его потребности
Протокол о потребностях освобождает ваше представление о пользователях от всего лишнего: все, что вам нужно знать, будет выражено в одном предложении. Это особенно полезно в процессе исследования (ответы на опросы, стенограммы интервью пользователей, карты эмпатии) и поиска решения — таким образом, улучшается ясность и распределение времени.
2. Добиться согласованности в работе всей команды
Протокол о потребностях — это наиболее эффективный способ распространить во всей компании единое понимание пользователя и его потребностей. В будущем это будет играть роль компаса, направляющей силы.
3. Определить критерий успеха
Протокол потребностей обеспечит вас метриками успеха еще до начала этапов генерирования идей, прототипирования и тестирования. Возьмите цель и спросите себя: как мы узнаем, достигли ли мы ее? Затем, по мере разработки протокола, установите соответствующие показатели успеха.
Почему компании так боятся поговорить со своими клиентами?
Процесс
1. Определите область
Протокол должен быть применим к разным областям. Скорее всего, в рамках одного проекта у вас будет подготовлено несколько утверждений о потребностях: всеобъемлющее, зонтичное утверждение и подчиненные утверждения, которые формулируют меньшие цели для этого типа пользователя. Вы должны сформулировать утверждения, исходя из текущих потребностей проекта.
Начните с создания «зонтика» или «родителя» (в широком диапазоне), когда ваша цель:
- согласование долгосрочной перспективы или дорожной карты;
- определение проблемного утверждения в начале разработки концепции продукта.
Родительское утверждение будет иметь широкую цель, которая перекроет все компоненты проекта. Например, следующее утверждение о потребности можно рассматривать как родительскую цель: Например, [Алена, многозадачность, разбирающаяся в технологиях мама] испытывает потребность в том, чтобы [быстро и уверенно сравнивать варианты, не покидая зону комфорта], и это позволит ей [тратить больше времени на действительно важные дела].
И наоборот, полезно начать с «детского» (малого) утверждения о проблеме, если ваша цель:
- улучшить комфорт в проблемной сфере;
- разработать личные критерии успешности деятельности;
- установить цель для недельного спринта.
2. Провести качественные исследования (или собрать результаты уже проведенных)
Изучите как можно больше исследований, которые укрепят ваше понимание пользователей и их проблем. Особое внимание уделите таким качественным исследованиям, как интервью с пользователями, полевые работы, дневниковые исследования: они значительно улучшат ваши представления о пользователях. Не обходите вниманием и карты, которые ваша команда уже успела разработать: карты эмпатии, карты путешествий или схемы обслуживания.
3. Генерируйте и комбинируйте
Используя данные исследований, подберите варианты для 3 переменных в вашем утверждении о проблемах: пользователя, потребности и их понимании. Не стоит беспокоиться о том, что вам не удастся с самого начала разработать идеальное утверждение; вместо этого подумайте о каждой переменной в отдельности, затем начните их комбинировать друг с другом и сопоставлять. Генерируйте несколько разных пар, пока не получите утверждение, отражающее реальную потребность пользователя.
Обычно специалисты опасаются включать в свои утверждения о потребностях что-либо, что не находит прямого подтверждения в проводимых исследованиях. Однако важно помнить, что пользователи не всегда готовы напрямую сказать, что им нужно и почему: порой они и сами этого не знают. Ваша работа, как проектировщика пользовательского опыта, — использовать данные исследований, комбинировать это с вашими знаниями и получить качественно новые выводы.
Ребекка Синклер (Rebecca Sinclair) из Airbnb напоминает, что «вы — разработчик. Ваша задача — быть глубоким, чутким слушателем и представлять себе способы решения проблемы. Возьмите на себя ответственность создать нечто намного лучшее, чем клиент мог бы себе представить. Они будут служить вам вдохновением, но творцом остаетесь вы». Продолжайте это делать, не переставая спрашивать себя:
- что заботит пользователя?
- почему это для него столь важно?
- какие эмоции движут поведением пользователя?
- что он может получить?
4. Подвергните критике свои утверждения
Как только у вас появится утверждение, вам следует начать работу по его шлифовке. Меняйте его компоненты, пробуйте разные варианты. Не переставайте спрашивать себя, приводит ли вас это утверждение к идеации? Отражает ли утверждение нюансы того, какое значение будет иметь решение этой проблемы для пользователя?
5. Добавьте методы измерения
На финальном этапе разработке протокола вам понадобится подобрать метрики для измерения его эффективности. Если бы вы смогли удовлетворить конкретную потребность пользователя, как бы вы об этом узнали? Наиболее распространенные критерии успеха следующие:
- удовлетворение клиента;
- количество возвратов;
- пролонгация контракта;
- повторяющиеся покупки или подписки;
- вероятность рекомендации продукта.
Как сделать поведенческие метрики основной движущей силой вашего бизнеса?
Утверждения о потребностях пользователей в действии
Утверждения должны использоваться на протяжении всего цикла разработки продукта, чтобы команда успела извлечь из них максимум пользы. Ниже приведены примеры того, когда и почему полезно создавать и ссылаться на user need statements.
Пример 1: исследование
Когда: анализ и совместное использование ключевого вывода из интервью пользователя.
Как: после завершения анализа индивидуальных исследований самостоятельно разработайте утверждения о потребностях. Сравните эти утверждения с тем, что удалось разработать вашей команде. Постарайтесь на их основе выработать новые варианты утверждений, которые могли бы наиболее достоверно представить выводы из интервью.
Зачем: это поможет вам свести все самое важное к одному действенному утверждению, которое легко понять, а значит — и распространить.
Совет: не забудьте сравнивать утверждения о потребностях для разных пользователей друг с другом, чтобы отметить различия между пользовательскими сегментами.
Пример 2: старт проекта
Когда: определение целей в начале цикла запуска нового продукта или спринта.
Как: разработка утверждений должна вестись коллективно, в ходе переговоров. Попросите участников генерировать идеи о потребностях конкретного пользователя. Продолжайте обсуждение, пока все не согласятся с одним утверждением.
Зачем: разработать четкое, понятно сформулированное утверждение, чтобы достичь единого понимания в масштабе всей мультидисциплинарной группы; а также чтобы противостоять возражениям, которые могут возникнуть на более поздних этапах цикла разработки.
Совет: попросите каждого члена команды поставить под утверждением свою подпись, указывая тем самым на согласие с ним и единое понимание цели.
Пример 3: ретроспектива
Когда: обзор эффективности и полезности нового функционала после его имплементации.
Как: ретроспективный анализ следует начать с обзора утверждения, которое было разработано еще в самом начале работы над проектом. Попросите участников сопоставить свое восприятие успеха с этим утверждением.
Зачем: Сравнить эффективность того, что было реализовано, с первоначальной целью (утверждение о потребностях должно сопровождаться четким определением того, в чем заключается успех — например, большое число кликов и т.д.).
Совет: сопоставьте свою оценку нового функционала с пользовательскими данными, восприятием новой функции самими пользователями.
Утверждения о потребностях пользователей в сравнении с задачами разработки
С первого взгляда может показаться, что утверждения о потребностях пользователей похожи на другие структуры, которые обычно используются в ходе разработки продукта. Задачи разработки и истории пользователей часто имеют один и тот же формат: [пользователь] нуждается [в способе выполнения чего-либо].
Чтобы лучше осознать разницу между этими инструментами, сравните утверждения о потребностях с заявлением о разработке:
[Алена, многозадачность, разбирающаяся в технологиях мама] испытывает потребность в том, чтобы [быстро и уверенно сравнивать варианты, не покидая зону комфорта], и это позволит ей [тратить больше времени на действительно важные дела].
Пользователю нужна сравнительная таблица, чтобы увидеть разницу в ценах.
Первый дает нам конкретного пользователя, то, что он должен сделать, и ясное, чуткое понимание того, почему ему это нужно. Заявление о разработке демонстрирует нам некий усредненный образ пользователя, решение (сравнительная таблица) и небольшое обоснование того, что это решение позволит сделать пользователю.
Оба документа одинаково нужны и важны, у каждого из них есть свое предназначение. Если вы находитесь на ранней стадии процесса дизайн-мышления, вы должны приняться за разработку качественных утверждений о потребностях, которые послужат опорой для дальнейших процессов идеации и прототипирования.
Заключение
Утверждения о потребностях формулируют не только проблему конечного пользователя, которую вы собираетесь решить, но и то, почему ее стоит решать. Благодаря им вы перестанете думать о проблемах пользователей как о готовых решениях: вы будете искать причину возникновения тех или иных проблем. И станете лучше понимать своих клиентов.
Подписывайтесь на нашу группу в фейсбуке и канал в телеграм, чтобы следить за обновлениями.
Прокачайте свой онбординг!
По материалам: nngroup.com Изображение: freepik.com
