В прошлом году известный австрийский графический дизайнер Стефан Сагмайстер произвел сенсацию, когда он раскритиковал то, что он видел как растущую тенденцию к творческим людям, называющим себя «рассказчиками». И не потянул без ударов.
В видео он утверждал, что рассказывание историй — увлечение в творческой индустрии. Мастера-сказочники, такие как романисты и режиссеры, редко называют себя сказочниками, а дизайнеры американских горок и ландшафтные архитекторы так и делают. Также стало обычным делом встречать людей в области дизайна и UX, превозносящих преимущества рассказчика.
Предупреждение : пожалуйста, имейте в виду, что в своем видео Стефан использует довольно красочный язык, который может быть не всем по вкусу.
Тонкое Различие
Хотя не каждый дизайнер обязательно является рассказчиком, я не верю, что аргумент Стефана также полностью оправдан. Стефан определенно не против рассказывания историй как таковых. Его больше раздражает идея людей, называющих себя сказочниками, — тонкое различие.
Его комментарии можно объяснить реакцией на злоупотребление «рассказыванием историй» как модным словом. Большая часть образования вокруг рассказывания историй сосредотачивается на том, чтобы рассказать клиенту историю бренда.
Тем не менее, применение методов рассказывания историй для улучшения пользовательского опыта было эффективным инструментом для разработки продуктов. Ключевым отличием является рассказывание историй — техника, используемая внутри команды разработчиков и сотрудников.
Речь не идет о применении пути героя , трехэтапной структуре или попытке сопоставить какую-то загадочную технику создания фильма с тем, как мы разрабатываем веб-сайты. Это больше похоже на еще один инструмент для обсуждения опыта, который мы создаем.
В своей статье 2011 года « Зачем нам нужны рассказчики на слуху о разработке продукта », Сара Дуди переворачивает идею рассказывания историй с ног на голову. Она сказала:
Первой целью рассказчика продукта является содействие сотрудничеству и совместному созданию.
Глядя на рассказывание историй как на метод сотрудничества, а не на уловку продаж, придает ему больше глубины и смысла. В этой статье Сара объясняет, как рассказывание историй помогает объединить сообщение о продукте и выделить его на многолюдном рынке.
Естественно, следующий вопрос: как начать применять эту технику в своей повседневной работе? Каковы точные шаги для создания цифровых продуктов, основанных на истории?
Начните с проблемы
Обычно люди начинают говорить о приложении, которое они создают . Приложения, расширения браузера, плагины и продукты, как правило, являются средством для достижения цели. Часть в большей схеме вещей. Рассказывание историй помогает сосредоточиться на опыте клиента и проблеме, которая решается, а не на решении.
Выявление актеров
Любая история имеет две основные составляющие — сюжет и актеры. Выявление действующих лиц требует определенного количества исследований. Чем реальнее актеры, тем лучше история. Первый шаг в создании истории — понять, кто является ключевыми действующими лицами. Выделите широкую категорию людей, которые потенциально могут быть пользователями. Исходя из этого в качестве отправной точки, мы сможем провести некоторые пользовательские исследования.
Низкие затраты на исследования пользователей
Исследования пользователей мгновенно напоминают о высококачественных юзабилити-лабораториях с двусторонними зеркалами и машинами для отслеживания глаз. Несмотря на то, что есть место для таких подробных исследований, существуют альтернативные методы для проведения быстрых пользовательских исследований при низких затратах, в соответствии с графиком и бюджетом.
Всегда лучше конкретизировать персонажей или актеров на основе исследований, а не предположений. Обратитесь к друзьям или знакомым, которые могут соответствовать профилю актера, которого мы набросали. Люди, которые могут столкнуться с той же проблемой, которую мы пытаемся решить. Попытка понять, как они в настоящее время решают эти проблемы, дает нам глубокое понимание создания лучшего опыта.
Помните, что этот этап быстрый, и от вас не ожидают, что он будет очень подробным. Достаточно просто пользовательских исследований, чтобы мы не строили актеров исключительно на основе предположений. Достаточно просто анализа конкурентов, чтобы мы понимали, какие решения уже существуют.
Twitter является еще одним отличным ресурсом для быстрого исследования пользователей. Независимо от того, какую проблему вы пытаетесь решить, вокруг нее обязательно будет разговор. Быстрый поиск в твиттере помогает определить, каково общее чувство вокруг этого домена. Это также помогает наблюдать естественные разговоры, происходящие вокруг темы, вместо того, чтобы задавать людям прямой вопрос. Некоторые из поисков, которые вы могли бы выполнить:
- Как я _ _ _ _ _ _ _ _
- Может ли кто-нибудь порекомендовать _ _ _ _ _ _ _ _
- Вы когда-нибудь использовали _ _ _ _ _ _ _ _ (продукт конкурента)
В этом примере поиск в Твиттере « Вы когда-либо использовали uxpin » показывает, как некоторые люди относятся к этому продукту и какие существуют альтернативы. Это также показывает, что команда UXPin довольно активно реагирует на такие комментарии. Вся хорошая информация, чтобы основывать наши истории и актеров вокруг.
Форумы — отличные места для выявления возможностей и разочарований пользователей. Если вы найдете статью на соответствующую тему, проверьте раздел комментариев. Обычно люди предоставляют дополнительную информацию, интересные ссылки или высказывают свои разочарования в разделе комментариев. Вы можете лучше понять клиентов, следя за дискуссиями, где бы они ни происходили.
В этой статье в журнале Smashing раздел комментариев содержит дополнительную информацию о рекомендуемых инструментах, а также об альтернативах. Это отличное дополнение к актуальной статье. Комментарии обычно показывают, что люди думают о продуктах и инструментах, которые обсуждаются. Это, в свою очередь, показывает, каковы реальные проблемы пользователей и какие потребности недостаточно обслуживаются существующими решениями.
Основываясь на вышеупомянутом исследовании, вы должны теперь иметь базовое представление о целевой аудитории, каковы их мотивы, цели и разочарования. Вы также можете узнать, где существующие продукты не отвечают требованиям или делают большую работу.
Строить историю
Расправившись с основными действующими лицами, мы можем начать формировать гипотетический сценарий — историю. Существует много литературы по созданию историй, и эта тема заслуживает отдельной статьи. Тем не менее, вот очень простая история в качестве примера:
В этой истории мы начнем с контекста пользователя и его чувств. Это хорошая информация для создания продуктового предложения, отвечающего самым высоким интересам пользователей. После ознакомления с решением актер преодолел свою проблему и достиг желаемого результата .
Важно понимать, что решение (веб-сайты, приложения, цифровые продукты) является лишь частью истории клиента. Потребители хотят получить результат — переместитесь из пункта А в пункт Б. Вот куда вписываются продукты, которые мы создаем.
На данный момент нас больше волнует пользовательский опыт и путешествие в целом, а не мелочи интерфейса. На самом деле, мы даже не дошли до эскизов решений.
Установка сцены
История помогает установить сцену или показать нам контекст пользователя. Понимание контекста использования является ключом к созданию хорошего опыта. Пользователи используют продукт поздно ночью в темных местах или на улице на солнце в дневное время? На основе этой информации мы можем сделать осознанный выбор цветовой палитры.
Понимание пользовательского контекста также может помочь в принятии решений по разработке. Будут ли пользователи иметь доступ к хорошему сетевому покрытию или мы должны использовать автономные возможности? Будут ли они иметь доступ к зарядным станциям или мы будем строить для низкого заряда батареи. На этом этапе можно раскрыть множество технических и UX-целей.
Определение ключевых экранов
Основываясь на установленном нами этапе, мы должны быть в состоянии определить ключевые экраны или взаимодействия, которые должны пройти пользователи. Это та точка, с которой мы начинаем делать наброски каркасных решений. Опять же, не вдаваясь в подробности, мы можем набросать ключевые экраны или взаимодействия для пользователей. Это может быть отдельная раскадровка сама по себе.
Основываясь на приведенном выше примере раскадровки, мы можем понять, что Максу (нашему персонажу) больше всего понадобятся следующие экраны:
- Поиск курса по теме
- Посмотрите, охвачены ли ключевые темы, уровень курса (для начинающих)
- Пройдите курс поэтапно
Такая расстановка приоритетов, основанная на потребностях пользователей, дает нам лучшее понимание их мира, их ментальных моделей и требований. Разрабатывая в соответствии с их потребностями, решение в конечном итоге будет более актуальным для конечного пользователя.
Представление решений
Представление решений с историями — это отличный способ помочь людям понять, какие решения вошли в дизайн. Это помогает представить дизайнерские решения ключевым заинтересованным сторонам, таким как высшее руководство, юристы, маркетологи, дизайнеры и разработчики.
Прежде чем показывать клиенту решение по макету дизайна, полезно начать с актеров, их контекста, их ситуации и предлагаемого решения. Одно дело доставить макет PSD по электронной почте для одобрения клиента. Это совершенно другой опыт, чтобы показать им путь клиента и то, как приложение помогло людям в этом путешествии.
Чем это отличается?
Рассказывание историй, в общем, выигрывает, потому что люди за пределами технологического мира понимают истории и рассказывание историй лучше, чем Lean UX или Agile UX. Иногда UX-люди, как правило, оказываются вовлеченными в артефакты, такие как личность или исследования пользователей. Эта техника удерживает внимание пользователя. Хотя все эти концепции все еще используются, они используются с точки зрения « как я могу решить проблему пользователя ». Это автоматически заставляет нас двигаться, не слишком сосредотачиваясь на не относящихся к делу вопросах, таких как:
- Насколько точны эти исследования?
- Это статистически значимо?
- В каких местах пользователь совершает покупки?
Самым большим отличием использования повествования для разработки продукта является то, что оно используется внутри команд. Инструмент для совместной работы, который помогает выправить историю до того, как будет написана единственная строка кода или нарисован эскиз.
Это также помогает задать тон для развития — когда речь идет не о ком-либо в команде или о самом приложении. Речь идет не о крутой новой функции, о которой кто-то думал в душе. Здесь нет места для личной предвзятости или эмоциональной привязанности к особенностям. Это действительно сфокусировано на людях, для которых мы пытаемся решить проблемы.
Это привлекает внимание к обсуждению и пересмотру дизайна. Отзывы дизайнеров — одно из самых страшных разговоров для дизайнеров, потому что они очень субъективны. Используя рассказывание историй, мы можем сосредоточиться на требованиях конечных пользователей к функции или изменению дизайна, а не на том, что кажется правильным клиенту. Мы можем противопоставить пустую обратную связь дизайну вопросами: « Как это решит проблему пользователя? »
Решения для сборки, а не экраны
Конечно, это делает нас, дизайнеров, более ответственными. Теперь у нас нет оправданий, чтобы побаловать себя последним модным увлечением. У нас нет оправдания, чтобы начать обсуждение с «Это будет параллакс-сайт». Дизайн ориентирован на пользователя, его контекст и историю. Сейчас мы находимся в состоянии решать проблемы, а не создавать экраны.
Дальнейшее чтение
Я ссылался на видео Стефана в этой статье, потому что трудно игнорировать такие самоуверенные комментарии, когда писал о той же самой методике, которую он осудил. Я считаю, что для каждой техники в книге есть подходящее время и место. Наша задача как дизайнеров — использовать правильную технику для решения правильной задачи. Как говорится:
Если у вас есть только молоток, все выглядит как гвоздь
Вот несколько ссылок, которые продвигают этот разговор.
- Большая часть идей в этой статье взята из моего интервью Сары Дуди на подкасте IncrementalUX . Она углубляется в то, как использовать эту технику и как ее не использовать.
- Она была достаточно любезна, чтобы сделать шаблон для раскадровки .
- Сара Дуди первоначально опубликовала статью в 2011 году в журнале UX, где она вводит идею повествования в основе разработки продукта.
- Сара активно ведет блоги и выпускает новостную рассылку UX о разработке продуктов и смежных темах.
- На UIE есть отличный эпизод подкаста с Кимом Гудвином, использующим истории. В этом эпизоде она рассказывает о том, как истории могут помочь поставить проблему пользователя в центр. Она также продолжает рассказывать о том, насколько гибкие истории полностью отличаются от пользовательских историй или рабочих историй.
- У Zurb есть отличный пример (с набросками) для решения, которое они построили с использованием техники повествования.