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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каким же оно было? Нужно ли было изменить процесс работы сайта или правил валидации данных? Нет. Нужно было добавить два коротких слова: «Ваше» и «Их».

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

«Один маленький шаг – один гигантский прыжок».

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

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

Однажды я присутствовала на предварительной встрече разработчиков и маркетеров с бизнес-подразделением. Каждый описывал свое ви́дение продукта. Было ясно, что они не просто рассматривают его с разных позиций, но и описывают разный опыт. Сотрудники бизнес-подразделения представляли себе устройство, которое решит проблемы само, без вмешательства людей. Команда маркетинга хотела получить мультимедийный продукт. А разработчики представляли алгоритм в Visual Basic.

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

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