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

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

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

Дэн Декер[68], специалист по написанию сценариев, в своей книге «Анатомия сценария» называет такого героя «персонажем-окном»: именно его глазами мы видим все события:

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

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

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

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

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

Эта проблема возникает не только в исследованиях пользовательского опыта. Непросто постоянно напоминать себе, что вы не центр Вселенной. Американский врач и писатель Джон Эндрю Холмс утверждает: «Нужно помнить, что вся Вселенная, за одним незначительным исключением, состоит из других людей».

Отношения с аудиторией

Рассмотрим следующий тип отношений – между вами и аудиторией. Вы можете играть одну из ролей:

• Член сообщества равных, например команды.

• Внешний консультант – из другой компании или отрасли.

• Тот, кто хвалит менеджеров, клиентов или других людей с более высоким статусом, чем ваш.

• Эксперт или менеджер, рассказывающий об экспертизе.

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

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

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

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

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

Много ли у вас общего с аудиторией?

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

Мой муж Джон Честер – звукоинженер. Настоящий инженер, который может рассказывать истории об электронных деталях с разными номерами. Как-то он участвовал в дискуссии Общества инженеров-акустиков[70] об истории живого звука. Он собрал несколько ведущих специалистов, работавших в этой области со времен появления живых концертов – тех, кто следил за звуком на фестивалях в Вудстоке и Ньюпорте, – чтобы вспомнить о былом и посмотреть, как развивалась отрасль.

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

Показали одну из фотографий с джазового фестиваля в Ньюпорте. Джон предположил, что аппарат на фото – это U-47, и тут началась бурная дискуссия. «Нет, это Elam-251. – Не может быть. Он был бледно-зеленого цвета, а этот не такой». В конце концов сошлись на том, что это U-48.

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

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

Они все знали о микрофонах. И они привыкли так говорить.

Вы воспринимаете историю так же, как аудитория?

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

Но наверняка у больного диабетом будет другая точка зрения. Он задумается: «Понимают ли они, над чем работают? Поможет ли мне их прибор?» Нужна история, которая покажет, что разработчики действительно разбираются в вопросе.

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