Сторителлинг в проектировании интерфейсов. Как создавать истории, улучшающие дизайн

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

Достоверность

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

Здесь есть множество аспектов. Например, если велика разница в социальном положении участников исследования и аудитории, придется решить, стоит ли точно передавать речь. Обеспечит ли это большую правдоподобность? Или слушатели просто решат, что рассказчик менее образован и компетентен, чем они сами? Задача непростая – нужно одновременно сохранить исходную форму и не повредить репутации участника исследования, предоставившего вам информацию.

Редактирование живой речи для письменной презентации

Кэролайн Джаретт помогает правительственным учреждениям в установлении контактов с гражданами и компаниями. Она понимает свою роль связующего звена между обычными людьми и правительством.

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

Они были умны и красноречивы, но многие не имели нужного образования. А мой клиент – правительственное учреждение. Его сотрудники, как правило, не очень уважительно относятся к малообразованным людям.

В отчете я решила исправить грамматические ошибки и убрать выражения, которые могли быть истолкованы как признак низкого уровня образования и узости кругозора.

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

Возможно, вы создадите разные варианты истории для различных аудиторий или обстоятельств. Однако старайтесь сохранить достоверность.

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

Хороший финал

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

Это этическая проблема. Вы как рассказчик даете аудитории возможность обдумать идеи и события и испытать ощущения, с которыми они раньше не сталкивались.

Рассказчик несет ответственность за выбор финала. Последний должен не только соответствовать поставленной цели, но и показать аудитории возможность использовать чужой опыт в своей жизни и работе.

Дополнительные источники

Профессиональные кодексы этики

Американская ассоциация психологов. Этические принципы психологов и кодекс поведения:

www.apa.org/ethics/code2002.html

Кодекс этики Американской ассоциации антропологов:

www.aaanet.org/committees/ethics/ethcode.htm

Ассоциация профессионалов в области юзабилити. Кодекс профессионального поведения:

www.usabilityprofessionals.org/about_upa/leadership/code_of_conduct.html

Международная торговая палата и Европейское общество по опросам общественного мнения и маркетинговым исследованиям. Международный кодекс по практике проведения маркетинговых и социальных исследований:

www.esomar.org/index.php/codes-guidelines.html

Ассоциация рыночных исследований:

www.mrs.org/uk/standards/codeconduct.htm

Общество эргономики. Кодекс этики:

www.hfes.org/web/AboutHFES/ethics.html

Выводы

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

• Когда вы отбираете истории, рассказанные другими, постарайтесь ответственно работать с материалом.

• Полезные советы можно найти в исследованиях и кодексах профессиональных ассоциаций.

• Вы должны помнить, что влияете на ход исследования. Задумайтесь, как лучше «перевести» истории пользователей на язык своей аудитории.

Глава 5. Истории как часть пользовательского опыта

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

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

Мы не будем доказывать преимущество какого-либо подхода или продвигать новую методологию, основанную на использовании историй. Истории полезны в любом случае: когда вы ориентируетесь в первую очередь на пользователя, свои цели или применяете более сложный подход (например, DDD[37]).

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

Существует даже международный стандарт, описывающий общий процесс, который назван человеко-ориентированным проектированием для интерактивных систем. Его официальное название – ISO 13407. В новой версии ISO 9241–210 при оценке юзабилити учитывается пользовательский опыт. На рис. 5.1 приведена упрощенная схема этапов процесса.

^{РИС. 5.1. Человеко-ориентированная модель проектирования}

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

Кроме того, процесс разработки и тестирования включает еще несколько необходимых элементов:

• Понимание (исследование пользователей и контекста).

• Особенности (бизнес-анализ и исследование пользователей для определения предназначения продукта).

• Дизайн (разработка фактического дизайна продукта – от ранних набросков до готового проекта).

• Оценка (тестирование разработки на соответствие поставленной цели).

В этом процессе есть три важные особенности.

Во-первых, он итеративен. Идеи могут быть протестированы, а затем приняты или отклонены. Можно пробовать множество вариантов, пока не найдется оптимальный. Команда разработчиков может вначале создавать приблизительные наброски или схемы, а потом использовать их в окончательном варианте (тестируя идеи на каждом этапе).

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

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

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

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

Пользовательский опыт – междисциплинарная практика

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

Мы видели всякое: от проектных команд из одного человека до компаний, все сотрудники которых (включая дизайнеров, проект-менеджеров, разработчиков, маркетеров и специалистов в области пользовательского опыта) участвовали в исследованиях, анализе и проектировании. Об этом и идет речь в знаменитой фразе Уильяма Гибсона[38]: «Будущее уже здесь. Просто оно очень неравномерно распределено».

Мы не требуем, чтобы вы стали специалистами по историям или ввели в своей компании должность «рассказчика» или «придумщика историй». Мы только надеемся, что они помогут каждому специалисту развить свои творческие способности.

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

Идея не нова

Не мы первые придумали использовать истории при проектировании пользовательского опыта. Они применяются в разных методиках в качестве реальных примеров.

Одна из основных дисциплин, изучающих пользовательский опыт, – этнография. Специалисты в этой области наблюдают за людьми и их поведением в определенных ситуациях. Основной упор делается на реальных историях и иллюстрации определенных гипотез с их помощью. В учебнике AIGA[39] «Введение в этнографию» говорится: одна из задач этнографа – «рассказать историю так, чтобы помочь людям осмыслить все данные и создать общее видение».

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

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

Иногда сценарии очень похожи на кейсы. Правда, в последних основной упор делается на описании конкретных событий, включая действия системы (или ее элементы, отвечающие за определенные действия). Их главная задача – зафиксировать взаимодействия при использовании программы, а не описать условия и пользовательский опыт в целом. Ларри Константин и Люси Локвуд применяют другой подход – «практичное проектирование». С помощью кейсов и других программных методов они определяют цели пользователей и способы их достижения.

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

На сайте, посвященном гибким методам разработки (www.agile-software-development.com/2008/04/writing-good-user-stories.html), говорится следующее: «Пользовательские истории – простой способ собрать технические требования во время проекта, альтернатива длинным спецификациям». Общая схема такова: «Как [роль пользователя] я хочу [цель], чтобы [причина]», например:

– Как соискатель я хочу найти работу, чтобы продвинуться по карьерной лестнице.

– Как специалист по кадрам я хочу опубликовать вакансию, чтобы найти нового члена команды.

Джо-Энн Хакос и Джинни Редиш в своей книге «Анализ пользователя и задачи для дизайна интерфейса»[40] рассказали о сценариях и пользовательских историях. Они считают, что сценарий помогает проиллюстрировать результаты анализа, и толкуют этот термин так же широко, как мы – понятие сторителлинга:

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

«Анализ пользователя и задачи для дизайна интерфейса»

Они выделили несколько типов историй (в их терминологии – сценариев): от краткого описания ситуации, контекста или действий пользователя до подробных сценариев задач и действий, в которых показаны все этапы работы.

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

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

Мы рассмотрим пять областей исследования пользователей, в которых истории наиболее эффективны (в каждом случае необходимо учесть особенности целевой аудитории):

• Предварительный сбор информации.

• Исследования и получение новых данных.

• Генерирование идей, эксперименты.

• Тестирование.

• Озвучивание и продажа идей.

На любом этапе работы с пользователями вы можете услышать истории об их перспективах и целях (рис. 5.2). Основная аудитория таких историй – вы (и ваши коллеги).

^{РИС. 5.2. Сбор информации из разных источников}

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

В человеко-ориентированном проектировании это часть этапа понимания. Ваша основная задача – выслушать истории, в которых приведены интересные информация, точка зрения или метод описания.

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

^{РИС. 5.3. Истории помогают прояснить информацию}

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

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

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

^{РИС. 5.4. Истории как источник идей}

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

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

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

Истории играют определенную роль и в тестировании (рис. 5.5). С их помощью можно определить, с чего стоит начать и какие задачи поставить перед участниками эксперимента.

^{РИС. 5.5. Истории – подходящий сценарий для тестирования задач}

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

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

Возможно, вы уверены, что отличная идея или продукт продадутся сами. Говорят, что одна картинка стоит тысячи слов. Но в случае продукта эти слова нужны, чтобы объяснить смысл картинки (или прототипа). Истории показывают связь между исследованиями пользователей, изначальной идеей и проектом (рис. 5.6) и благодаря этому наглядно демонстрируют работоспособность нового продукта.

^{РИС. 5.6. В рамках истории можно описать идею проекта}

Дополнительные источники

Erickson T. Notes on Design Practice: Stories and Prototypes as Catalysts for Communication // Carroll J. (ed.) Scenario-Based Design: Envisioning Work and Technology in System Development. John Wiley & Sons, 1995.

Rosson M., Carroll J., Cerra D., Hill N. Usability Engineering: Scenario-Based Development of Human Computer Interaction. Morgan Kaufmann, 2001.

Константин Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.

Hackos J., Redish J. User and Task Analysis for Interface Design.

AIGA, «Введение в этнографию» (AIGA, An Ethnography Primer): http://www.aiga.org/ethnography-primer/.

Выводы

Сторителлинг – не новая методология, но он может использоваться в описании пользовательского опыта.

• Идея применения сторителлинга не нова. Во многих методиках истории применяются для передачи информации о взаимодействии пользователей с продуктом.

• Истории полезны на разных стадиях: сбора входной информации, анализа данных, генерирования идей, оценки дизайна и прояснения возникших вопросов.

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

Глава 6. Сбор историй в рамках исследования

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

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

Личная беседа – очень мощный инструмент

Рэйчел Бэйли занимается контент-стратегией, помогает организациям создавать коммуникационные продукты и управлять ими. Она рассказала нам, как истории клиентов помогают изменить методы продаж.

Недавно меня попросили написать тексты для нового сайта компании. Я задала вопрос о целевой аудитории. Они хотели раскрутить нового разработчика PAAS[41] – решений для малого бизнеса. Директор представлял себе это так: «Приложение настолько просто в использовании, что даже моя бабушка с ним бы справилась». Ставилась задача создать приложение с функцией перетаскивания для разработки модулей программного обеспечения.

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

Для начала я опросила потенциальных клиентов. Результат удивил всех. Считалось, что новый продукт предназначен для малых компаний, в которых работает не более 100 сотрудников и чей доход не превышает 5 млн долл. На втором собеседовании выяснилось, что целевой рынок – не малый бизнес, а микробизнес: число сотрудников не превышает 10, а доход – 1 млн долл.

Эти клиенты не знали, что такое PAAS, как она может быть им полезна и где можно найти такие программы. Когда они выбирали приложения, то обращали внимание прежде всего на полезные для бизнеса функции, например выписку счетов онлайн.

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

После разговора с потенциальными клиентами мы решили, что продукт должен быть описан иначе. Теперь продукт рекламируется как «бизнес-приложения и услуги, выходящие за рамки стандартного CRM[42]».

Самое забавное то, что в конце концов на главной странице сайта оказалось не так много материала. Мы не объясняли, почему PAAS-решение хорошо для владельцев микробизнеса, а привели реальные истории успеха (которые помогают целевой аудитории оценить преимущества предложения) и краткую видеоинструкцию на главной странице.

Ну, и цену, разумеется. Она была решающим фактором при выборе приложений.

Лучшие истории – реальные

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

При личном общении можно заметить все мелкие детали взаимодействия. Это особенно актуально для эмоциональных реакций или неожиданной радости.

Какой пульт дистанционного управления самый забавный?

В ранние 1990-е, когда я учился в аспирантуре, Philips участвовала в процессе разработки недолговечной технологии CD-I (интерактивный компакт-диск). В рамках спонсорства образовательной программы нам предоставили CD-I-плеер с несколькими играми и двумя пультами. Наступили рождественские каникулы, и большинство учащихся поехали домой на праздники. Я попросил разрешения взять домой CD-I-плеер и принадлежности к нему. Я знал, что моим детям он понравится. Мне тоже нравился плеер, потому что он был бесплатный (для аспирантов это существенное достоинство).

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

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

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

Второй пульт был «детским», но на самом деле он и взрослым показался бы более удобным: 15-сантиметровый ярко-желтый трекбол с белым основанием, красными и голубыми боковыми кнопками. Пластик, из которого он сделан, был приятным на ощупь и казался крепким.

Использовать его было интересно, он хорошо работал и его не нужно было долго изучать! Это лучший элемент устройства. Нам всем понравился пульт, но мы не были уверены, попадет ли он на рынок. Он был явно лучше, чем сам CD-I-плеер.

Примечания

1

В русской бизнес-литературе на данный момент еще не сложилось единого мнения по поводу того, как переводить термины «usability», «user experience», «UX design» (или просто «design»). Самый простой способ – транслитерация («юзабилити»). Буквальный перевод – «удобство использования». Соответственно, «user experience» – это «впечатления, полученные от использования», или «опыт использования». Однако в зависимости от контекста используются термины «проектирование пользовательского взаимодействия», «опыт пользовательского взаимодействия», «опыт использования», «пользовательский опыт», «опыт взаимодействия», «пользовательское взаимодействие» и др. Что же касается термина «UX design», то под ним часто имеется в виду «проектирование интерфейса» или «дизайн интерфейса». Подробнее см.: http://artgorbunov.ru/bb/soviet/20101018/. Прим. ред.

2

Creative Common License – документ, охраняющий авторское право. Прим. науч. ред.

3

В фантастическом сериале «Звездный путь» Холодек – специальная голографическая палуба, на которой члены экипажа могут взаимодействовать с различными предметами. Прим. науч. ред.

4

Murray J. Hamlet on the Holodeck: The Future of Narrative in Cyberspace. The MIT Press, 1998.

5

Laurel B. Computers as Theatre. AddisonpWesley Professional, 1993.

6

Redish J. Letting Go of the Words – Writing Web Content that Works. Morgan Kaufmann, 1th ed., 2007.