Когда Дэс попросил меня внести свой вклад в публикацию «Внутри Intercom», я как раз представил концепцию РКДБВ моим соучредителям в Aim – рекламной площадке для индустрии недвижимости.

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

Затем меня осенило. Без каких-либо ссылок на концепцию РКДБВ я начал указывать на наиболее успешные предложения, сделанные моими соучредителями. Я объяснил, с каким затруднительным моментом столкнулись наши клиенты, и описал, как их жизнь изменится к лучшему после того, как это затруднение будет решено. Затем я объяснил, почему их предложение хорошо подходило для этой задачи проектирования. Фактически, я описал работу клиента и то, что у него происходило после того, как эта работа была выполнена.

Используя язык РКДБВ для общения, мы смогли набросать свой первый дизайн всего за несколько минут. Мы никогда не оглядывались назад.

Персоны и пользовательские истории имели смысл, когда клиенты и группы продуктов были далеки друг от друга. Однако в настоящее время ситуация изменилась.

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

Жертвами такого процесса, основанного на модели водопада, становились тонкости, чрезвычайно важные для создания отличных продуктов: причинно- следственная связь, тревоги и побуждающие мотивы. РКДБВ – это философия сосредоточения внимания на этих тонкостях. А гранулированный способ довести эту концепцию до продукта – это использовать Истории работы для разработки функций, UI и UX.

Когда персоны не достигают успеха

Как Дэс уже обсуждал ранее, персоны часто определяются атрибутами, которые не имеют никакого отношения к причинно-следственной связи. Например, возраст человека, его пол, раса и привычки проведения времени на выходных не объясняют, почему он съел батончик Сникерса. Зато 30 секунд, потраченные на то, чтобы купить и съесть что-нибудь, что утолит голод на 30 минут, объясняют это.

Когда пользовательские истории не достигают успеха

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

В пользовательских историях, как в той, что приведена выше, есть три большие проблемы:

1. Они используют персоны.
2. Они привязывают реализацию к побудительным мотивам и результатам.
3. Они игнорируют контекст, ситуации и тревоги.

Функции часто не достигают успеха. Если функция была определена пользовательской историей, будет сложно обнаружить, почему она потерпела неудачу, потому что реализация была привязана к побудительным мотивам и результатам. Из-за такой связи как кто-нибудь может узнать, что пошло не так? Была ли неправильной реализация, или были неправильными предположения о побудительных мотивах?

Введите Историю работы

Впервые упомянутые Полом Адамсом в блоге Intercom и разработанные здесь, Истории работы – это другой способ проектирования функций. Но как команда внедряет их в свой рабочий процесс?

Вот один из подходов:

1. Начните с работы высокого уровня.
2. Определите более мелкие работы, которые помогут выполнить работу высокого уровня.
3. Понаблюдайте за тем, как люди решают проблему сейчас (работа, которую они используют в настоящее время).
4. Придумайте Историю работы, чтобы исследовать причинно-следственную связь, тревоги и побудительные мотивы того, что они делают сейчас.
5. Создайте решение, которое решает такую Историю работы.

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

В начале процесса проектирования команда обсуждала, как будет выглядеть профиль, и какие функции должны существовать там.

В какой-то момент Сара, член команды, встала и нарисовала простое каркасное изображение на доске. Она указала на блок и сказала: «Это профиль продавца».

Команда была не сразу убеждена ее аргументацией. Они задали серию вопросов «Почему?» для каждой части профиля. Даже после всех этих вопросов команда не выработала единое мнение относительно принятия или непринятия идеи.

На этом этапе был задан вопрос:

«Почему продукт должен иметь профиль? Почему это должно быть в том или ином виде? Какую информацию он должен отображать? Какие ситуации он разрешает? Какую работу выполняет этот профиль?»

Чтобы решить этот вопрос, рамки функции были определены заново через Истории работы.

Начните с работы высокого уровня

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

Определите более мелкие работы, которые помогут выполнить работу высокого уровня.

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

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

При заполнении этого типа информации покупатель анализирует (обычно визуально) продавца и автосалон и делает вывод о том, можно ли им доверять. Как правило, он записывает финансовую информацию личного характера на листе бумаги в непосредственной близости от продавца. Это помогает ему чувствовать уверенность в том, что информация указана правильно и не будет передана людям, которые не имеют право ее видеть.

Придумайте Историю работы, чтобы исследовать причинно- следственную связь, тревоги и побудительные мотивы того, что люди делают сейчас.

1. Когда продавцы автомобилей и их клиенты взаимодействуют друг с другом через продукт…
2. …клиенты хотят чувствовать, что они могут доверять организации, процессу и продавцу.
3. Продавцы захотят быть уверенными в том, что их процесс дает их клиентам возможность чувствовать себя комфортно…
4. …поэтому клиенты будут чувствовать себя в безопасности, внося свою финансовую информацию в процесс.

Вышеизложенная информация структурирует ситуацию в Историю работы. Ее можно изложить в более подробном варианте, предоставив больше ситуационного контекста – например, когда и где указывается эта информация (к примеру, дома или в автосалоне), и перечислив тревоги, которые каждая сторона будет иметь относительно создания и просмотра профиля.

Создайте решение, которое урегулирует такую Историю работы

Чтобы выполнить эту работу, команда решила, как должен быть спроектирован профиль. Слишком мало информации – и профиль не будет выполнять оригинальную работу, а слишком много информации может иметь негативные последствия. Поэтому команда решила следующее:

1. Когда клиент использует продукт, профиль продавца всегда будет видимым (чтобы успокоить тревогу клиентов о том, что они физически не присутствуют рядом с продавцом).
2. В профиле будет представлена фотография продавца, название должности, количество проданных автомобилей и лет работы в компании (чтобы успокоить тревогу клиента относительно репутации и надежности продавца).
3. Профиль предоставит клиенту легкие пути для связи с продавцом, например, с помощью номера его телефона, адреса электронной почты и кнопки «Задать [продавцу] вопрос» (чтобы успокоить клиента относительно возможной ошибки в заполнении формы).

Вот пример решения:

А вот разбивка UI: работа, которую выполняет каждый элемент UI, и какую ситуацию он урегулирует.

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

Проектирование для реальных людей, проектирование для причинно- следственной связи.

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

Абстрактные атрибуты и реализация привязки к побудительным мотивам и результатам являются отвлекающими факторами для команды. Если команда углубляется в ситуацию и узнает о РКДБВ для клиента, она создает решения более эффективно. И использование Историй работы для разработки продуктов является одним из лучших способов сделать это.