Метод Jobs to Be Done. Проектирование клиентоориентированного продукта

В качестве примера Адамс указывает на архитектуру Facebook[44], показанную на рис. 5.3. Для каждого компонента системы есть соответствующий этап работы, скажем, написать сообщение, отправить сообщение, создать профиль пользователя. Это становится основой организации решения, независимой от технических проблем и соображений об интерфейсе.

Рис. 5.3. Пример архитектуры продукта

Моделирование системы

Архитектура решения – это абстракция. Модели делают ее конкретной. Создание модели структуры решения связывает понимание потребностей клиента с разработкой концепции в целом. Даже простая диаграмма, такая как на рис. 5.3, поможет достичь взаимопонимания в команде.

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

Вы можете эффективно использовать JTBD в начале разработки дизайна архитектуры решения. Главное – обосновать дизайн наблюдениями за реальным миром. Хорошие решения имеют логику, присущую их структуре, в свою очередь отражающей пользовательскую ментальную модель работы, которую надо выполнить (рис. 5.4).

Рис. 5.4. Разработка структуры решения с помощью JTBD – это восходящий процесс

Дизайн пользовательской среды (UED)

В своей знаменитой книге «Контекстный дизайн» Бейер и Хольцблатт предложили особый метод создания структуры продукта под названием дизайн пользовательской среды (User Environment Design, UED)[45]. Хотя UED создали для проектирования программного обеспечения, он применим для любого решения, в том числе даже для проектирования услуг и промышленного дизайна.

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

В качестве примера UED Бейер и Хольцблатт приводят приложение, управляющее электронной почтой (рис. 5.5).

Рис. 5.5. Пример архитектуры решения системы обмена электронными письмами

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

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

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

Этап 1. Понимание пользователей и их работы

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

Этап 2. Определение областей фокусировки

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

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