Шаг 4: разработка контекстных сценариев

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

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

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

Контекстные сценарии отвечают на вопросы, подобные этим:

• В какой обстановке будет использоваться продукт?

• Будет ли он использоваться в течение долгого времени?

• Часты ли прерывания в работе персонажа?

• Работает ли с компьютером/устройством более чем один пользова' тель?

• Какие еще продукты используются вместе с проектируемым?

• Какие основные действия должен выполнить персонаж, чтобы дос' тичь своих целей?

• Каков ожидаемый конечный результат применения продукта?

• Какова допустимая сложность продукта исходя из частоты его ис' пользования и навыков персонажа?

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

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

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

Пример контекстного сценария

Ниже приводится пример первоначального варианта контекстного сценария для ключевого персонажа. Продукт объединяет в себе смарт' фон и сопутствующую услугу оператора. Персонажа зовут Вивьен Стронг, она – агент по продаже недвижимости из Индианаполиса. Це' ли Вивьен – достичь равновесия между рабочей и семейной жизнью, успешно завершать сделки, добиться того, чтобы каждый ее клиент чувствовал себя единственным.

Контекстный сценарий для Вивьен:

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

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

3. Разговаривая с Фрэнком, Вивьен включает громкую связь, чтобы иметь возможность в ходе разговора смотреть на экран. Она изучает назначенные встречи, чтобы понять, в какое время она свободна. Когда она создает новую запись о встрече, смартфон автоматически отмечает ее как встречу с Фрэнком, потому что знает, с кем она сей' час разговаривает. Заканчивая беседу, она быстро вносит адрес до' ма в запись о встрече.

4. Отправив Алису в школу, Вивьен направляется в агентство недви' жимости, чтобы собрать документы, которые требуются для другой встречи. Ее смартфон уже синхронизировал новые встречи с Out' look, так что остальные сотрудники офиса знают, где она будет днем.

5. День летит быстро, и Вивьен несколько опаздывает на встречу. На' правляясь к дому, который хочет смотреть Фрэнк, она получает уведомление от смартфона, что встреча состоится через пятнадцать минут. Открыв смартфон, она видит не только запись о встрече, но и список всех документов, относящихся к Фрэнку, включая элект' ронные письма, заметки, голосовые сообщения и информацию о звонках на номер Фрэнка. Вивьен нажимает кнопку вызова,

и смартфон автоматически связывает ее с Фрэнком, поскольку зна' ет о скорой встрече с ним. Вивьен сообщает Фрэнку, что будет на месте через двадцать минут.

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

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

8. Вивьен принимает звонок и выясняет, что Алиса опоздала на авто' бус и ее нужно забрать из школы. Вивьен звонит мужу, чтобы выяс' нить, сможет ли он это сделать, однако попадает в голосовую почту – вероятно, муж находится за пределами действия сети. Она сообщает мужу, что она на встрече с клиентом, и спрашивает, сможет ли он забрать Алису. Через пять минут смартфон издает короткий звук, по которому Вивьен узнает, что это муж; она видит, что он прислал ей короткое сообщение: «Алису заберу, удачи со сделкой!»

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

Игра в волшебство

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

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

На ранних стадиях проектирования считайте интерфейс волшебным.

Шаг 5: выявление требований

Получив первый удовлетворяющий вас набросок контекстного сцена' рия, вы можете приступить к его анализу с целью извлечения потреб' ностей персонажей – требований. Эти требованиямогут включать в се' бя объекты, действия и контексты (Shneiderman, 1998). Помните: мы предпочитаем не отождествлять требования с возможностями или зада' чами. Таким образом, из приведенного выше сценария можно опреде' лить, например, такую потребность:

Звонок (действие) человеку (объект) непосредственно из записи о встре' че (контекст).

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

Информационные требования

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

Функциональные требования

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

Прочие требования

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

• Требования бизнесамогут включать в себя сроки разработки, стан' дарты, структуры ценообразования и бизнес'модели.

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

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

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

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

От требований к пользовательскому интерфейсу: общая инфраструктура и детализация

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