РИС. 8.1. Задание в контексте главной цели пользователя
Нет единственного способа создания истории. Есть методики, которые описывают разницу между типами историй и определяют различия в продолжительности, структуре или формате подачи.
Джинни Редиш предполагает, что истории, которые помогают придумать идею, должны быть «короткими, с описанием реальных пользователей в реальных ситуациях».
Сара Смит, 25-летняя сотрудница маленькой туристической компании из трех человек, принимает звонок от своей подруги Дженни:
Дженни хочет прилететь в Феникс в следующем месяце и увидеться со своей закадычной подругой. Она может отправиться в любые выходные и взять отгул на пятницу и понедельник. Но только если билеты будут ей по карману. Дженни попросила Сару найти самые дешевые билеты на следующий месяц (до Феникса на пятницу, обратно на понедельник).
Здесь приведена информация о пользователях, их целях и задачах и контексте – физических, социальных и технических условиях. Задача – найти лучшие тарифы. Сейчас этим занимаются все туроператоры. Джинни написала эту историю по результатам наблюдения за реальными людьми, изменив имена из соображений конфиденциальности.
Исследователь Дэн Груэн из IBM считает, что разница между историями и сценариями заключается в мотивации и специфике. В его модели сценарии менее специфичны и слабо отражают (или не отражают совсем) мотивы персонажей. При генерации новых идей мотивация становится необходимым элементом, поскольку показывает особенности человеческой культуры и характера. В разработке дизайна сценарии полезны для того, чтобы сосредоточиться на заданиях, которые должны быть выполнены, или технологиях, которые должны быть использованы.
Блок-схемы и кейсы используются для тех же целей, но в них внимание сосредоточено в большей степени на разработке технических конструкций, чем на объяснении мотиваций и контекста. Истории используются наряду с другими формами описания взаимодействий, однако показывают реальный пользовательский опыт.
Мы не можем однозначно сказать, в каких случаях следует использовать тот или иной формат. Но мы знаем, какие элементы включает хорошая история, применяемая в проектировании:
• Акцент на деятельность, описание действий и поведения в определенном контексте.
• Описание стимулов к действию.
• Подробное описание действующих лиц (или одного из них) в контексте.
Кроме того, нужно исключать ненужные подробности, технические характеристики и все то, что ограничивает проект. Это не имеет отношения к дизайну. Вам нужна история, которая описывает пользователей и продукт в действии. Позже мы еще поговорим о выборе деталей, пока же приведем короткий пример: если вы описываете дождливый день, то погода должна как-то влиять на события. Возможно, трудно работать с телефоном одной рукой, потому что другая занята зонтом. Или дождь как-то воздействует на поведение персонажа. Упоминание о дожде может быть важным, но только если история включает соответствующие детали.
Задачи историй в проектировании
Истории нужны даже тогда, когда проект уже завершен. Они могут сопровождать спецификации, иллюстрируя их, дополняя деталями из ранее созданных сценариев. Они могут описывать альтернативный опыт для разных пользователей и объяснять сложное взаимодействие, например одновременное применение разных режимов.
Истории нужны для демонстрации контекста. Когда описываются технические подробности, легко забыть, почему была добавлена конкретная возможность и как она может использоваться. Истории помогают показать общую картину во время проработки деталей проекта.
Стандарт, построенный на историяхВ журнале UX Magazine Изабель Фрин описывает один из самых необычных случаев использования историй в медицинских программах типа H7[54]. Они используются персоналом поликлиник – медсестрами и докторами. Пользователи считают, что люди, которые составляли технические требования, не представляют себе условий работы. Кроме того, они обнаружили, что непросто описать их действия в технических терминах. Поэтому они начали применять истории и кейсы. Это помогло медикам и компьютерным разработчикам найти общий язык.
Раскадровка: запрос статуса в листе ожидания
Задачи
Раскадровка отражает процесс коммуникации для запроса статуса клиента в листе ожидания.
Предпосылка
Питер Процесс, соцработник организаций «Удачная выписка» и «Больница для выздоравливающих», отправлял запрос в несколько домов престарелых для размещения больного Адама Эвримана. Ему сообщили, что пациента занесли в лист ожидания. Поскольку господин Эвриман очень хотел попасть в дом престарелых поближе к месту, где живут его дети, он записался в очередь в Living Legends Aged Services (LLAS) и Senior Living Retirement Villages (SLRS). Питер очень хочет пристроить больного в ближайшие 1–2 суток и поэтому хочет знать статус, чтобы понять, нужно ли ему обратиться в другие дома престарелых[55].
Раскадровка
У Питера есть доступ к обоим листам ожидания, и он делает запрос, на каком месте в очереди сейчас находится пациент, чтобы оценить, сколько еще нужно ждать. Он получил ответ от системы LLAS, что перед господином Эвриманом еще 4 человека.
Итог
Питер обсудил ответ на запрос с господином Эвриманом, и они решили подождать, когда появится свободное место.
История как спецификация
Один из видов историй-прогнозов – технические спецификации, основа подробных описаний. Это не собственно спецификация, но она закладывает основу для проектирования, сбора информации из разных источников. Так же и персонажи в удобном формате обобщают информацию о людях. Структура истории включает следующие элементы:
• Предположение: утверждения, иллюстрирующие исходные данные.
• Опыт: очень короткие истории, на пару предложений, которые показывают образ.
• Цели: предложения, описывающие идеальный новый опыт.
• Источники: ссылки, книги, статьи из источников, которым доверяет аудитория, по теме исследования. Все это помогает повысить доверие аудитории. Многие люди считают, что их работа самая важная. Поэтому имеет смысл сослаться на работы других участников процесса.
• Выводы: образы, которые показывают ключевые элементы в удобном для аудитории формате (например, презентация).