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

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

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

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

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

Иногда нужно убедить людей в том, что инновации не приведут к их увольнению. Ян Роддис, Сара Аллен, Вики Стирлинг и Кэролайн Джаретт поняли это, когда начали работать с сайтом Открытого университета. Сотрудники центра регистрации были единственными, с кем будущие студенты общались до зачисления. Эти люди боялись, что потеряют работу, когда разрабатывался сайт с ответами на все вопросы о вузе.

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

Истории для технически подкованной аудитории

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

РИС. 10.3. Технический эксперт

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

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

Участник 2 (перебивая): Есть проблема. Вы сделали ошибку в макете. А главное, пятое поле слишком маленькое, его не хватит для длинного текста.

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

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

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

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

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

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

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

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

Саймон Гриффин из Etre[60] (www.etre.com) несколько лет ведет новостную рассылку. В каждом выпуске приводится короткая история-совет. Сначала он приводит краткое описание, чтобы заинтересовать публику и задать тон или контекст для всей истории. Здесь описаны случаи из практики или подробно объясняется технический принцип. Гриффин начал одну историю с рассказа о том, как NASA решило проблему письма в условиях невесомости. Потом он рассказал похожую историю о своей компании, которая начиналась с фразы из фильма об освоении космоса «Аполлон-13»[61].

«Etre, у нас проблема»

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

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

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

Оказалось, что клиенты почему-то вводили собственные данные в форму для получателей, а данные получателей – в форму для отправителей. С точностью до наоборот!

Тем не менее проблема казалась решаемой. Формы отправителя и получателя находились рядом, в обеих были заголовки «Имя», «Фамилия», «Адрес» и однозначные названия («Ваши данные» и «Данные получателя» соответственно). Источник путаницы был раскрыт. Оставалось понять, как решить проблему.