Процесс проектирования интерфейса

Главные идеи#

Три шага по кругу#

Цикл такой: первоначальное проектирование, затем прототип, затем тестирование и доработка — и снова по кругу. Чем тщательнее первый шаг, тем короче третий, но тем длиннее сам первый; этот компромисс неизбежен. Начинайте на бумаге: экранный редактор подталкивает шлифовать вариант, который через пять минут отправится в корзину. Головач считает союзником и технического писателя: чем понятнее интерфейс, тем меньше приходится объяснять, поэтому писатели хорошо распознают плохой дизайн.

Семь этапов первоначального проектирования#

1. Определите функциональность. Функцию из системы, которая уже продаётся, убрать почти невозможно, поэтому планируйте на несколько версий вперёд. Запросы отдела продаж — например, жалобы клиентов или функции конкурентов — считайте симптомами, которые нужно проанализировать, а не распоряжениями. Совместите два анализа. Цели пользователей: людям нужен результат (поджаренный хлеб, а не тостер). Действия пользователей: как люди добиваются этого результата сегодня — это можно узнать, только наблюдая за ними. Остерегайтесь эгоцентризма: «мне нужно — значит, нужно всем».
2. Напишите пользовательские сценарии. Это описания взаимодействия простым языком, с именованными персонажами и без деталей реализации; они охватывают все типы задач. Сценарии потом станут материалом для тестирования, а уже сейчас показывают лишние шаги.
3. Сделайте паузу для вдохновения. Спросите себя: «Нельзя ли сделать принципиально лучше?» — пока изменения ещё дёшевы.
4. Спроектируйте общую структуру. Разбейте систему на независимые блоки примерно по три функции в каждом и определите связи между ними. Связи бывают логическими, процессуальными и основанными на том, как пользователи группируют понятия. Последние выявляют карточной сортировкой (card sorting) не менее чем с четырьмя-пятью представителями целевой аудитории. Иногда стоит жёстко задать последовательность действий, чтобы сократить число ошибок и время обучения.
5. Спроектируйте экраны. Это наименее алгоритмизируемый этап. Головач рекомендует здесь модель KLM (Keystroke-Level Model) из семейства GOMS (Кард, Моран и Ньюэлл). Каждый вариант интерфейса раскладывают на элементарные операции (нажатие клавиши, наведение указателя, перенос руки между мышью и клавиатурой, принятие решения) и складывают их стандартные длительности. Так варианты можно сравнить без прототипа. Модель подходит для опытных пользователей и не учитывает обучение, ошибки и удовлетворённость. Обращайте внимание и на адаптивную функциональность: система берёт на себя более сложную логику, чтобы логика пользователя стала проще. Её находят только наблюдением за пользователями.
6. Составьте глоссарий всех терминов интерфейса: надписей на кнопках, пунктов меню, названий окон и режимов. Затем дорабатывайте его по кругу: сокращайте, проверяйте понимание на пользователях, давайте каждому понятию одно название, сверяйтесь со стилем платформы, называйте команды глаголами.
7. Соберите всё вместе и проверьте. Сведите воедино структуру, экраны и глоссарий и продумайте обработку исключительных ситуаций, например команд, недоступных для конкретного объекта. Затем заново распишите каждый сценарий, не глядя на схему, и сравните. Расхождения находятся почти всегда, и именно сейчас их дешевле всего исправить.

Экспертная оценка#

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

Детализация прототипа#

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

Тестирование#

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