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

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

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

Мы были большими поклонниками структуры РКДБВ, но бóльшая часть того, что было написано об этой концепции, применялась к молочным коктейлям и шоколадным батончикам. Публикаций об исследованиях на тему применения данной концепции для работы с программным обеспечением было очень немного. Поэтому мы создали собственный процесс, основанный на том, что мы знали.

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

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

И мы никогда не пользовались персонами в Intercom.

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

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

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

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

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

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

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

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

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

Подумав об этой проблеме с чисто теоретической точки зрения, мы изобрели концепцию «Истории работы». Тогда она называлась по-другому (позднее Алан Клемент дал ей это название), но процесс присутствовал и работал подходящим для нас образом. Мы впервые озвучили ее в одном из сообщений в блоге, жалуясь на проектирование в стиле сообщества Dribbble. Мы долго и упорно думали о РКДБВ и в конечном итоге создали свой собственный процесс, который фокусировался на ситуациях, побудительных мотивах и результатах:

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

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

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

Прежде чем мы в Intercom начинаем какой-либо проект, мы создаем краткий одностраничный обзор проекта (Вы можете загрузить копию шаблона с bit.ly/intermissiondownload). Он очень прост и должен ограничиваться одной страницей формата A4. В нем есть раздел «Истории работы», который помогает в напоминании нам о проблеме или возможности, с которой мы встретились, и держит фокус нашего внимания на протяжении всего проекта.

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

Если это Вас не убедит, помните, что персоны искусственно ограничивают общий рынок для Вашего продукта. Вот почему мы ставим все на Истории работы.