Детализация формы и поведения

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

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

На этапе детализации происходит перевод раскадровок в полноценные экраны, отражающие пользовательский интерфейс с точностью до от' дельных пикселов (рис. 7.4).

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

Рис. 7.4. Полноценные экраны для Cross Country TravCorps, основанные на иллюстрациях, созданных в программе Framework (рис. 7.2).

Обратите внимание, что в макете интерфейса произошли небольшие естественные изменения, связанные с реалиями пиксельной графики

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

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

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

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

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

Проверка результата проектирования и юзабилити−тестирование

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

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

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

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

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

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

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

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