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

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

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

Общая инфраструктура пользовательского интерфейса 163

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

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

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

Исследования в области восприятия архитектурных чертежей и визуализаций говорят в пользу такого подхода. Результаты изучения реакции людей на различные изображения, созданные в CAD-системах, приводят к заключению, что карандашные наброски стимулируют обсуждение предложенного дизайн-проекта, а также дают ясное понимание того, что представленная работа еще не закончена (Schumann et al., 1996). Кэролин Снайдер (Carolyn Snyder) подробно описывает данный эффект в своей работе «Paper Prototyping» (Snyder, 2003), где речь идет о ценности слабо детализированных представлений с точки зрения получения реакции от пользователей. Мы считаем, что юзабилити-тести-

₁₆₄ Глава 7. От требо ваний к пользовательскому интерфейсу

рованне и отзывы пользователей наиболее полезны на стадии детального проектирования, но определенно существуют случаи, когда эта деятельность приносит пользу уже на стадии создания инфраструктуры. (Более подробно юзабилити-тестирование обсуждается в конце главы.)

Создание инфраструктуры взаимодействия

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

1. Определение форм-фактора, типа приложения и способов управле
ния.

2. Определение функциональных и информационных элементов.

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

4. Макетирование общей инфраструктуры взаимодействия.

5. Создание ключевых сценариев.

6. Выполнение проверочных сценариев для верификации решений.

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

Шаг 1: определение форм-фактора, типа приложения и способов управления

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

Общая инфраструктура пользовательского интерфейса 165

Определяя форму продукта, следует также выявить базовый тип интерфейса продукта и способы управления системой. Тип интерфейса продукта определяется тем, как много внимания пользователь будет уделять взаимодействию с продуктом и как продукт своим поведением будет отвечать вниманию со стороны пользователя. Решение по этому вопросу следует основывать на контекстах и окружении использования, упомянутых в контекстных сценариях (см. главу 6). Понятие типа интерфейса мы более подробно рассмотрим в главе 9.

Способ управления определяет, каким образом пользователь взаимодействует с продуктом. Этот способ в некоторой степени диктуется форм-фактором и типом приложения, а также предпочтениями, взглядами и навыками персонажа. Вариантов здесь множество: клавиатура, мышь, панель с клавишами, клавиатура типа thumb-board (клавиатура для больших пальцев обеих рук), сенсорный дисплей, голосовое управление, джойстик, пульт дистанционного управления, специализированные кнопки и прочее, и прочее. Какое сочетание способов подходит вашим ключевым и второстепенным персонажам? Если для продукта уместно сочетание нескольких способов управления (так обычно бывает с веб-сайтами или компьютерными приложениями, рассчитанными на мышь и клавиатуру), выберите для продукта один ключевой способ управления.

Шаг 2: определение функциональных и информационных элементов

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

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

166. Глава 7. От требований к пользовательскому интерфейсу

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

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

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

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

• Голосовая активация (голосовые данные, привязанные к контакту
из телефонной книги)

• Программируемые кнопки быстрого набора

• Выбор человека из записной книжки

• Выбор на основе заголовка сообщения электронной почты, записи
о встрече или заметки

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

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

Дата добавления: 2015-10-24