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

Одному аспекту мы уделяем особое внимание — это исследование. Мы нанимаем людей с реальным опытом в исследовательской работе, и каждый член продуктовой команды напрямую общается с клиентами: продакт-менеджеры, дизайнеры и, конечно, команда исследователей. Мы также довольно рано наняли директора по исследованиям (Сиан Таунсенд, которая ранее возглавляла исследовательскую команду Google Maps), намного раньше, чем это делают другие стартапы.

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

Мы были большими поклонниками фреймворка Jobs-to-be-Done, но большая часть написанного о нём касалась молочных коктейлей и шоколадных батончиков. Почти не было исследований о том, как применять Jobs-to-be-Done к программному обеспечению. Поэтому мы создали свой собственный процесс, основываясь на том, что нам было известно.

На протяжении большей части своей карьеры я использовал персоны и сценарии для понимания клиентов. Популяризованные Аланом Купером в книге The Inmates Are Running the Asylum, они стали одним из самых широко используемых инструментов в арсенале исследовательских и дизайнерских команд. Купер также написал отличную книгу About Face, которую я рекомендую всем дизайнерам, присоединяющимся к моей команде. Но я прошу их пропустить главы о персонах.

Когда я работал в Google, я создал десятки, если не сотни персон для разных проектов. Мы тщательно следовали методике Купера, добавляя свои итерации. В итоге я обнаружил, что ценность этих инструментов весьма ограничена. Часто они помогали развивать эмпатию среди сотрудников, далёких от конечных пользователей, но редко приводили к прорывным идеям или свежему взгляду на проблему. В Intercom мы никогда не использовали персоны.

Я впервые по-настоящему начал сомневаться в ценности персон, когда покинул Google и пришёл в Facebook. У Facebook была потрясающая количественная база данных о том, как люди на самом деле используют продукт, и разговоры с командой data science всегда приносили новые инсайты.

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

Например, мотивации замужней матери троих детей из США, публикующей фото с семейного барбекю, в целом такие же, как у корейского подростка, выкладывающего фото с вечеринки. Цели и атрибуты у них внешне абсолютно разные, но мотивация — одна. Персоны никогда бы не привели к созданию одного и того же продукта для обеих аудиторий.

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

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

Проектировать продукт, исходя из мотиваций, гораздо эффективнее, чем исходя из атрибутов. Это и есть ключевое отличие между персонами и Jobs-to-be-Done. Персоны смотрят на роли и атрибуты. Jobs-to-be-Done — на ситуации и мотивации. Персоны объясняют, кто такие люди и что они делают. Но они никогда не объясняют полностью, почему они что-то делают. А почему — это куда важнее.

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

1. Люди — эксперты в своей проблеме, но не в решении. Однако им проще предложить решение в виде запроса на функцию. Описать предлагаемое решение легче, чем описать проблему, но вам нужно возвращаться к ним с вопросами, чтобы по-настоящему понять суть проблемы.
2. В своём первом ответе они скажут, что они хотят — в форме атрибутов, но не скажут, почему это важно. Поэтому нужно глубже копать мотивации. Было критически важно выяснить, какую именно проблему клиенты пытались решить и почему им это было нужно.

Как только мы поняли проблему, встал вопрос: как преобразовать эти инсайты в нечто полезное для дизайн-команды? Что-то лаконичное, легко передаваемое и запоминающееся. Я не могу даже вспомнить, сколько раз в Google мы проводили исследования, создавали персоны вместе с другими участниками, но потом всё это игнорировалось — просто потому что персоны были слишком сложными и громоздкими. Они просто недостаточно лаконичны для быстрого темпа работы продуктовых команд.

Кроме персон, есть ещё один популярный инструмент — user stories, продвигаемый Agile-сообществом в разработке ПО. Мы тоже никогда не использовали user stories. Во-первых, они не основаны на эмпирических данных, а создаются больше инженерами, чем клиентами. Они формулируются так, чтобы описать функциональность, которую нужно построить, а не мотивации людей.

После размышлений от первых принципов мы изобрели Job Stories. Тогда у них ещё не было такого названия (его позже предложил Алан Клемент), но сам процесс уже работал. Впервые мы упомянули его в блоге, сетуя на «дрибблизацию» дизайна. Мы долго размышляли над Jobs-to-be-Done и в итоге создали собственный процесс, фокусирующийся на ситуациях, мотивациях и результатах:

<aside> 🔑

[ Когда _____ ] [я хочу _____ ] [чтобы _____ ]

</aside>

                             *«когда ____»* 

→ фокус на ситуации/контектексе