Сторителлинг в проектировании интерфейсов
Начну с дисклеймера. Матерые дизайнеры или же те, кто знаком с методами исследования: CJM, персоны, сценарии и тд — найдут в статье мало практической пользы. Текст скорее для новичков и тех, кто хочет понять одну из базовых идей, на которой построен дизайн-процесс.
Ниже описан принцип, который встречается сразу на нескольких этапах дизайна. А можно поконкретнее? Можно, но для начала приведу пример.
В программе онлайн-курсов по дизайну, есть разделы, в которых идет речь о методах исследования (перечислил выше). Начиная проходить курс, вас учат как правильно рисовать CJM, составлять портреты пользователей или вопросы к юзабилити-тестированию. И у вас даже получается. Но мало кто понимает, в чем практический смысл этого.
История из жизни. На одном проекте стаяла задача определить ЦА и её привычные паттерны поведения. На правах старшего товарища, я предложил составить портреты пользователей другому дизайнеру. Вот задание выполнено, персоны составлены, но на вопрос: “Что будем делать дальше?” — дизайнер пожал плечами. У человека было понимание как составлять портрет пользователя, но не было понимания зачем это делать. Это распространенная ошибка при исследовании или анализе.
Дизайнеру было непонятно, на чём построена связь между пользователем и продуктом, задачей и решением. В этой статье речь пойдет как раз об этой связи, которая называется историей. В этом мне поможет книга “Сторителлинг в проектировании интерфейсов” по мотивам которой написан материал.
Что касается сухой теории, то она тут разбавлена примерами из жизни или выдуманными, но близкими к настоящим. Так как в статье присутствует слово “интерфейс”, то большинство примеров будут связаны с ним.
Что такое истории и где они применяются?
Представим ситуацию. Вы работаете дизайнером на проекте, который связан с онлайн-образованием. Сайт проекта представляет из себя каталог с детальной информацией по каждому курсу. Вы уверены, что благодаря такому четкому разделению, большинство людей с легкостью поймет, какой курс им больше подходит.
Но что если это не главное для будущих студентов. Новая профессия может стать для них мечтой. Избавит от текущей рутины и ненавистной работы. То есть на передний план выходят эмоции, которые получит человек, после изучения новой профессии.
Узнать, что важно людям, можно поговорив с ними. Для этого в дизайне достаточно способов, о которых уже было написано: интервью, опрос, персоны. Главная цель этих методов — услышать историю.
Если мы исследуем способы создания впечатления о нашем продукте, одна из главных целей — понять точку зрения целевой аудитории.
Сначала мы слушаем истории пользователей. Так формируем представление о пользовательском опыте, том самом UX. Потом, на основе этой информации, создаем и рассказываем свои истории, которые реализуем через интерфейс. Этот процесс называется сторителлинг.
Истории — общий язык в работе. С помощью них происходит общение с пользователями, передача информации, впечатлений. Выделяют несколько типов историй. Вот пример конкретный пример.
Описание обстоятельств или ситуации — показывает не только последовательность событий, но и причины событий. Рабочий из реального проекта:
Не так давно мы разговаривали с маркетологом, который работал с нашей платформой. Сейчас он работает с другими сервисами, но решает схожие задачи.
По ходу диалога, маркетолог рассказал о том, что любит пользоваться глобальным поиском и часто перекладывает этот паттерн взаимодействия на другие сервисы. Так ему не нужно вспоминать, в какой часть сервиса находится тот или иной объект.
Этот комментарий заставил задуматься, насколько нам нужен такой функционал. По итогу мы поняли, что в его реализации есть потребность и начали работу. А всё начиналось с обычной истории.
Другие виды историй:
- Иллюстрация проблемы
- Исследование концепции проекта
- Стимул для обсуждения идеи
При чем тут UX? Основные задачи истории
Может показаться, что история — это обычный рассказ, некая последовательность событий, такая как выступление или письмо. Но это не так. Хороший рассказ интересен, он больше похож на беседу, диалог, чем на выступление. Даже если слушатели молчат, они стараются представить то, о чем им говорят. Рассказ становится частью диалога.
Вы можете описать обстоятельства или характер персонажа, но это не история, пока нет событий, решений или действий. Все они обусловлены контекстом, или же пользовательским опытом. Это позволит понять причины произошедшего и найти решения.
И наоборот, когда мы что-то рассказываем пользователям, наш рассказ должен соответствовать интересам аудитории. Чтобы этого добиться, нужны две составляющие:
- История должна помочь пользователю выполнить задачу
- Она должна вписываться в контекст
Лучшие рассказчики — те, кто может создать связанный, легко запоминающийся сюжет.
Вернемся к примерам. Что отличает плохую историю от хорошей? Во второй должны излагаться факты и выстраиваться цепь событий:
Он зашел в Гугл и через поиске нашел сайт с доставкой обеда. На первом экране он увидел кнопку “Заказать сейчас” и нажал на нее. После чего перешел на сервис с каталогом.
Можно сделать акцент на объяснениях. А еще лучше описать поведение и отношение, показать, как люди реагируют на события:
Он зашел в Гугл, чтобы найти сайт с доставкой обеда. Ни секунды не думая, он выбрал первую же позицию. На первом экране он увидел кнопку “Заказать сейчас”, но прежде чем нажимать, убедился что выбран нужный город город. После чего его перебросило на на сервис с каталогом, из-за этого страница стала заново перезагружаться.
Также возможно добавить контекст, поясняющий мотивы, которые и определили поведение:
По дороге на работу, он зашел в Гугл со своего телефона, чтобы найти сайт с доставкой обеда. Ни секунды не думая, он выбрал первую же позицию. Его коллеги на прошлой неделе заказывали тут обед, поэтому он перешел сразу к заказу.
На первом экране он увидел кнопку “Заказать сейчас”, но прежде чем нажимать, убедился что выбран нужный город город. После чего его перебросило на на сервис с каталогом, из-за этого страница стала заново перезагружаться.
Узнали на что похоже? Такая же схема применяется при создании CJM. Там тоже есть цепь событий, реакция пользователя, контекст. Но это только инструмент. Повторюсь, задача этой статьи — показать универсальный принцип работы с информацией. Дополнительная задача — разобраться, зачем это делать. А уже когда поймем, будем использовать инструменты, чтобы систематизировать этот объем информации.
Еще один важный момент, который стоит упомянуть. Речь о способности слушать. Если внимательно слушать истории пользователей, можно понять их точку зрения и намерения. Благодаря этому вы узнаете причины того или иного действия.
Это большая тема для обсуждения, а мы тут вроде как собрались не только ради теории. Поэтому двигаемся дальше.
Применяем истории
Теперь рассмотрим историю на разных этапах проектирования пользовательского опыта. Для этого возьмем универсальный алгоритм создания продукта:
- Исследование пользователей и контекста. На этом этапе происходит предварительный сбор информации о пользователях. Ваша задача — выслушать истории, в которых пользователь описывает свою точку зрения.
- Анализ — получение новых данных на основе собранной информации. Здесь вы отбираете нужные истории. Нужно понять, какие истории будут интересны дизайнерам, разработчикам, менеджерам и другим людям.
- Дизайн — весь процесс от набросков до готового интерфейса.
На этом этапе истории помогают генерировать идеи и ориентироваться на реальные потребности пользователей. Вы начинаете создавать свои истории о том, как будет работать ваш продукт. - Тестирование — тестирование разработки на соответствие поставленной цели. В конце истории помогут определить, какие задачи поставить перед участниками эксперимента. На этом этапе мы создаем сценарии тестирования на основе собранных историй.
- Презентация — демонстрация решения. С помощью истории можно показать связь между исследованием пользователями, идеей и проектом. Это наглядно демонстрирует работоспособность нового продукта.
На всех этапах процесса создания, истории помогают сосредоточиться на пользователях. А это порой не просто, особенно если вы напрямую не контактируете с ними.
Хорошая история — напоминание о реальном мире, в котором будет использоваться ваш продукт.
Сбор историй в рамках исследования
Истории, которые рассказывают конкретные люди, не вымышлены. Из них можно извлечь нужную информацию для проекта. Например, мы можем понять мотивы или цели пользователей, определить отношение пользователей к продукту.
Распространенный способ сбора информации — качественное исследование (интервью, фокус группы). При личном общении всплывают подробности взаимодействия пользователя с продуктом. Одна из таких особенностей — эмоциональная реакций, то какие чувства вызывает то или иное действие.
Если вы не можете лично пообщаться с пользователем, используйте другие источники, например анкетирование или опрос.
Кроме того, можно собирать фрагменты историй из ряда косвенных источников:
- История поиска или просмотра — все что относится к поведению пользователя на сайте. Это может быть история поисковых запросов, перемещения пользователя по сайту или карта кликов.
- Записи службы техподдержки — хороший способ узнать вопросы пользователей и сортировать их по приоритету.
- Отдел продаж — они часто разговаривают с потенциальными клиентами. У них вы можете узнать, что больше всего интересует в продукте или о том, как пользователи объясняют свою проблему.
Самый простой способ услышать историю — задать вопрос. Старайтесь задавать вопросы, требующие развернутого ответа.
Вопрос — минимальная единица истории.
Старайтесь записывать то, что говорят пользователи. Фиксируйте только те фрагменты, которые кажутся важными для проекта, но лучше использовать своеобразные “фильтры”. Можно придумать принцип, по которому будете фиксировать самые яркие моменты.
Когда историй становится слишком много, их можно объединить в группы и на основе них составить пару портретов пользователей.
Истории как часть анализа
На этом этапе нужно отобрать наиболее подходящие истории. Они должны совпадать с целями проекта и подходить по контексту.
Вы можете не найти готовых историй, только короткие рассказы и заметки, характеристики и образы. Если у вас много разрозненных данных, вы можете создать сводную таблицу показателей и отобрать самые частые или наиболее подходящие для задачи. И уже на основе них сформировать единый сюжет (сценарий).
Сценарий может показать, в каких местах у пользователя возникали проблемы или натолкнет на новые идеи.
Прежде всего вы ищите полезную информацию, которая даст ответы на вопросы. Существуют маркеры интересных историй:
- Которые вы слышали более чем от одного человека
- В которых много подробностей
- С поясняющими деталями
- Иллюстрирующие аспекты пользовательского опыта, которые интересуют разработчиков
Но это только часть анализа. Есть и другие источники данных, которые напрямую не связаны с историями пользователей — это количественные данные. Их можно обработать и вычленить нужную информацию. Например данные из Google Analytics.
После этого вы можете сопоставить их с теми, которые озвучивали пользователи во время юзабилити-тестирования.
Истории в дизайне
Истории — не шаблон для разработки дизайна, а главный источник информации. Они скорее стимулируют дизайнерское мышление и заставляют находить новые решения для проекта.
На этом этапе есть несколько форматов, в которых происходит развитие и поддержка историй собранных ранее историй:
- Мозговым штурмом — генерируем идеи на основе рассказов пользователей и собственного понимания, как должен работать продукт.
- Концепция — объединяем несколько идей в одну.
- Спецификация — фиксируем основные правила работы с реализованным решением.
Один из наиболее понятных примеров рассказа истории в дизайне — это демонстрация работы продукта. На сайте можно рассказать о его основных фичах и конкурентных преимуществах, показать чем он полезен для пользователя.
Вот другой пример. Здесь мы на основе полученных данных ставим задачу, которую мы должны решить, чтобы помочь пользователям.
У вас сервис по продаже билетов. Вы знаете, что большая часть клиентов покупает билеты сразу туда и обратно. Но иногда, пользователи забывают заранее купить билеты назад и делают это на месте (через кассу или на другом сервисе). Перед вами встает вопрос: Что нужно сделать, чтобы пользователи покупали сразу два билета?
Вы можете решить его через интерфейс. Например, добавив кнопку “Купить обратный билет” перед завершение первого заказа.
Оценка с помощью историй
Любую работу нужно протестировать. С помощью историй можно усовершенствовать систему оценок. Один из способов — создание сценариев для участников тестирования. Другими словами, вы можете превратить обычное задание в реальную жизненную ситуацию.
Для одного из сервисов у нас была задача сделать интерфейс со статистикой по отправкам сообщений. Прежде чем приступать к проектированию, мы хотели понять, какие данные самые важные для маркетолога. Для этого мы составили несколько реальных бизнес-кейсов и попросили их решить в текущем интерфейсе.
После того, как мы сделали первые прототипы, настало время тестирования. Для него мы взяли те же задачи и попросили решить их в новом интерфейсе. Респонденты для тестирования были уже другие.
Но есть еще один лайфхак. Что если вы не спрашивали пользователей на этапе исследование. Или же у вас вовсе не было его. Звучит неправдоподобно, но на самом деле это не такая уж и редкая ситуация. Поэтому тестирование — это последний шанс узнать мнение людей, которые будут пользоваться вашим продуктом.
Истории в презентации
Самая важная деталь на этом этапе — кому мы презентуем. Сначала вы показываете свое решение команде разработки или проектному менеджеру. Потом вы рассказывать историю руководству. И только потом самому пользователю. Для всех этих групп должен быть свой подход.
Разработчикам важно найти простейший путь к цели. Менеджерам — понимать все детали и взаимосвязи. Для вышестоящего руководства основным критерием будет финансовый аспект истории, сколько денег принесет ваше решение. А для пользователя важнее всего решить задачу и чем проще будет решение, тем лучше.
Любая из этих групп воспринимает историю по-своему и иногда замечают “ошибки”. В этом нет ничего страшного, если их немного. Главное чтобы их можно было успеть исправить и двигаться дальше.
Вывод
Все это было только о применении истории в исследовании пользовательского опыта. А ведь еще нужно понимать как с этим правильно работать.
Чтобы не загружать ни себя не вас, я закончу на этом. Если будет потребность в продолжении или просто мне будет не лень — сделаю это в другой части.
