За моим сегодняшним дизайн-процессом стоит четырехлетняя история. Свой подход «Объектно-ориентированного UX» (Object-Oriented UX — OOUX) я представила в прошлом году на A List Apart. Подход подразумевает дизайн объектов перед проработкой действий. Настало время изучить преимущества OOUX более глубоко, в частности, плавный переход от дизайна объектно-базированной системы к дизайну взаимодействий.

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

С чего начнете свой дизайн?

Сперва вы сделаете наброски воодушевляющего процесса онбординга для поваров? Нам действительно нужны повара, чтобы сделать успешный продукт: нет поваров — нет сети! Так что, возможно, начнем с того, чтобы обеспечить им незабываемый первый опыт работы в продукте.

Или же лучше начать с одного из самых частых действий: как повар публикует новый рецепт? И это могло бы легко привести к созданию набросков браузинга — как другие шеф-повара будут искать новые рецепты?

Три или четыре года назад я бы начала с раскадровки главного пути пользователя. Я бы расписала все, что делает стандартный пользователь.

AddingRecipeFlowSketch2x
С чего начнете свой дизайн?
В пред-OOUX времена мое изначальное продумывание дизайна выглядело бы примерно так. Я бы определила дизайн взаимодействия, уточняя, как именно должен выглядеть рецепт.

Я представляю, что многие дизайнеры UX начинают примерно таким же способом, определяя, как тот или иной пользователь будет использовать продукт. Один сценарий взаимодействия ведет к дизайну другого сценария. Вскоре у вас формируется сеть сценариев. Итерируйте эти сценарии, добавляйте какую-то постоянную навигацию и вуаля — дизайн продукта готов.

Но с этим подходом, ориентированным на действия, есть одна проблема. Мы проектируем действия без четкой картины, над чем действие производится. Это как предложение: «Вася ударил». У нас есть субъект (пользователь) и есть глагол (действие). Но где объект? Вася ударил что? Мяч? Своего братика? Голодного зомби?

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

Сейчас многое происходит до того, как я приступаю к наброскам сценариев действий пользователя (в этой статье я использую «сценарий пользователя» и «сценарий взаимодействия» для одного и того же). Сначала я определяю своего пользователя, спрашивая «Кто такой Вася?» Затем я определяю его ментальную модель, подразумевая все вещи (объекты), из которых состоит задача, все, что он видит частью решения, и как эти части связаны между собой. И, наконец, я проектирую взаимодействия. Как только я понимаю, что Вася — это ниндзя, вооруженный всего одной палкой, стоящий перед полчищем зомби, я могу лучше спроектировать действия, которые он предпримет.

Оглядываясь на свое прошлое, мне кажется, что я делала свою работу в обратном порядке две трети своей карьеры, проектируя сценарии взаимодействия перед построением объектно-ориентированного фреймворка. А теперь я бы определила систему поваров, рецептов и ингредиентов перед тем, как побеспокоиться о процессе онбординга поваров или тем, как именно повар публикует свой рецепт. Как объекты связаны друг с другом? Какие элементы контента образовывают каждый объект? Какие объекты составляют мой MVP, и какие объекты я могу добавить позже? Наконец, какие действия пользователь совершает над каждым объектом?

Вот, о чем Object Oriented UX и есть — мы мыслим объектами, а не действиями. Ранее мы уже изучали подход определения объектов и дизайна фреймворка на основе этих объектов. В этот раз мы откроем способ плавного перехода из OOUX к дизайну взаимодействий, используя очень простой инструмент — CTA Inventory.

Что такое CTA Inventory, и почему он важен?

Призывы к действию (Call to action или CTA) — главные исходные точки сценариев взаимодействий. Если сценарий представляет собой разговор между системой и пользователем, CTA — это повод для начала такого разговора. Как только у вас сформирован объектный фреймворк, вы можете добавить возможные CTA к своим объектам, в буквальном смысле заложив метки вроде «Тут начинается взаимодействие». Эти метки — CTA — можно указывать с помощью CTA Inventory.

CTA Inventory - это мост от OOUX
CTA Inventory — это мост от OOUX к детальному дизайну взаимодействий.
CTA Inventory — это по сути список потенциальных CTA, организованных вокруг объектов. Так как большинство (все?) взаимодействий подразумевают создание, управление или поиск объекта, мы создаем это инвентори, думая о том, что пользователь хочет делать в вашей системе — в особенности, что пользователь хочет делать с объектами в вашей системе.

Создание CTA Inventory решает два вопроса. Сначала оно помогает нам переключать скорости между комплексной природой дизайна систем к более разделенной работе по дизайну взаимодействий. Во-вторых, оно помогает:

  1. Думать о взаимодействиях в креативном ключе;
  2. Валидировать эти взаимодействия;
  3. Гораздо точнее оценивать сроки разработки проекта.

Давайте детальнее раскроем эти три преимущества перед созданием собственного CTA Inventory.

Креативные ограничения улучшают брейншторм

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

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

Например, подумаем об объекте «ингредиент» в нашем приложении. Перечислим все действия, которые может проделать Пьер над ингредиентом:

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

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

Валидируйте действия на ранних этапах

Хорошие новости. Вы можете тестировать на пользователях свою систему объектов и действия, которые может совершать над ними пользователь, перед тем, как приступите к долгой и нудной разработке дизайна взаимодействий. Создайте прототип, который просто позволяет пользователям передвигаться с одного объекта на другой, изучая фреймворк (что само по себе является целью пользователя). Через наблюдения и интервью вы сможете увидеть, резонирует ли ваша система с ментальной моделью ваших пользователей. Есть ли у вас все нужные объекты, связаны ли они корректно друг с другом? И правильные ли на этих объектах «кнопки»?

Вооружившись простым прототипом ваших взаимосвязанных объектов и CTA, привязанным к ним, вы теперь имеете платформу для обсуждения функционала с пользователями — и не нужно убивать уйму времени на прототипирование самих взаимодействий. Если кратко, то: поговорите со своими пользователями о кнопках перед проектированием того, что произойдет по ее нажатию.

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

Оценивайте дизайн взаимодействий в уме

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

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

Нравится ли вам идея лучшего брейншторма, ранней валидации и более точной оценки? Отлично! Приступим к построению CTA Inventory. Сначала мы обсудим приблизительный план (который лучше проделать вместе с командой). Далее настроим более формальную и детальную табличную версию.

CTA Inventory: приблизительно

Если вы не читали мою азбуку отображения объектов, сейчас самое время! Я поясню вам свою методологию для:

  • Извлечения объектов из целей продукта;
  • Определения элементов объектов (ключевой контент, метаданные, вложенные объекты);
  • Приоритизации элементов.

В результате получится карта объектов:

Карта объектов CTA Inventory
Карта объектов перед разбивкой в CTA Inventory.
Я использовала обведенные синие стикеры для представления объектов; желтые стикеры для представления ключевого контента; розовые стикеры для указания метаданных; и дополнительные синие стикеры для представления вложенных объектов.

Примерное CTA Inventory — это фактически расширение карты объектов; как только вы приоритизировали элементы, начните думать о призывах к действию (CTA), которые будут ассоциироваться с каждым объектом. Я использую зеленые стикеры для своих CTA (как символ «в путь!») и помещаю их поверх их соответствующих объектов.

CTA Inventory на скорую руку
Карта объектов с примерным CTA Inventory на скорую руку. Потенциальные призывы к действию указаны на зеленых стикерах рядом с каждым объектом.
Грубый CTA-брейншторм отлично работает в процессе совещаний с кросс-функциональной командой. Получите идеи от разных коллег о том, как пользователь может взаимодействовать с объектами. Вы получите десятки потенциальных CTA! По сути, у вас с командой состоится разговор по поводу возможностей продукта, но с помощью полезного фреймворка объектов и их CTA. Вы берете этот большой и сложный процесс определения функционала и сводите его к простому, веселому совместному времяпровождению: «Все, что мы делаем, — брейнштормим, какие кнопки нужны для взаимодействия с объектами! И все, вот так просто!»

На каждый объект уйдет примерно 10−15 минут, так что запланируйте час-два для обсуждения CTA, если в системе от трех до пяти объектов. Вы удивитесь, насколько продуктивными окажутся генерируемые идеи! Вы и ваша команда получит четкое видение, что должен делать продукт, каждый выскажется по пунктам, с которыми он не согласен (что по-своему ценно).

В нашем примере с шеф-поварами, пока команда выдавала идеи, произошло кое-что очень интересное. В процессе обсуждение CTA объекта «ингредиент» мы подумали, что, возможно, будет полезно, если бы шеф-повары могли предлагать его замену (альтернативный ингредиент — смотрите на обведенный зеленый стикер внизу). «Выжимка из ашиота? Лучше попробуйте шафран!» Но при этом «предложенные альтернативные ингредиенты» должны стать частью объекта «ингредиент». Поэтому мы обновили карту объектов, чтобы они отражали это нововведение (обведенный кружком синий стикер).

CTA
После брейншторма всевозможных CTA нам понадобилось добавить вложенный объект в «ингредиент». Это были «альтернативные ингредиенты».
И хотя я всегда начинаю со своих объектов и их композиции, брейншторм CTA заставляет меня снова к ним возвращаться и вновь переосмысливать структуру объектов. Как всегда — будьте готовы к итерациям!

CTA Inventory: детально

CTA могут быть сложными; как и когда они отображаются — все это условия, основанные на правах, типах пользователя или состояниях объекта. И даже в нашем простом примере некоторые призывы к действию будут доступны только некоторым пользователям.

Например, если я — шеф-повар одной из сущностей своего объекта рецепта, у меня будет кнопка «edit» и «delete», но я не смогу добавить мой собственный рецепт в избранное («favorite»). И наоборот, если я нахожусь на листинге рецепта другого повара, я не смогу редактировать или удалять его, но у меня появится опция «favorite».

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

Детальное CTA Inventory

Детальное CTA Inventory для примера соцсети поваров. Вот вам Google-документ с подробностями.

Используя таблицы Google, я создаю матрицу (смотрите выше), которая позволяет мне захватывать мысли по каждому CTA и неизбежные сценарии взаимодействия для каждого:

  • Почему вообще у нас есть этот призыв к действию? Какая цель пользователя или бизнеса за ним стоит?
  • Кто запустит этот CTA? Конкретный персонаж или тип пользователя? Кто-то с особыми правами или ролью?
  • Где будет жить этот CTA? Где те места, в которых пользователь запустит этот сценарий? Есть ли другие места, которые стоит рассмотреть, опираясь на нужды пользователя?
  • Насколько сложен сценарий, запущенный этим CTA? Это поможет оценить нужные усилия.
  • Какой приоритет этого сценария взаимодействий? Его запуск критичен, можно отложить его на более позднюю фазу, или этот концепт нужно исследовать и оценить?
  • Какие вопросы и темы к обсуждению поднимает этот CTA?

Перед началом дизайна взаимодействий, связанных с каждым из ваших CTA, ответьте на эти вопросы. Разработайте объектно-ориентированный прототип и провалидируйте ментальную модель с пользователями. Пообщайтесь с ними и убедитесь, что вы включили правильные «двери» во взаимодействие. Только тогда у вас будет все необходимое для начала работы над набросками и прототипирования того, что происходит при открытии пользователем одной из этих дверей.

Крепкая основа для дизайна функционала

Вы совместно с командой создали элегантную объектно-ориентированную систему и создали продуманный CTA Inventory. Вы построили грубый, кликабельный прототип своей будущей системы. С помощью реальных пользователей вы убедились, что навигация в системе проста и полна. Пользователи благодарно кружат от объекта к объекту, и призывы к действию на этих объектах соответствуют их нуждам. Жизнь удалась!

Но объектно-ориентированный UX и CTA Inventory не помогут вам реализовать сами взаимодействия. Вам все еще предстоит тяжело потрудиться! Хотя теперь, когда вы начали набрасывать сценарии взаимодействия, вы можете быть уверенны, что разрабатываемый функционал уходит своими корнями в прочную почву. Так как ваше CTA Inventory приоритизировано, одобрено командной, вы как никогда организованны и готовы к работе над взаимодействиями.

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