Кумир молодежи второй половины XVI века, философ Мишель Монтень считал, что каждый человек — это модель всего человечества. В своих популярных по тем временам «Опытах» он предпринял попытку проанализировать и понять, а значит, как известно, решить на 80% актуальные общечеловеческие проблемы через «призму себя». И пришел, между прочим, к интересным выводам, некоторые из которых сохраняют значение и поныне. Сегодня, спустя почти 500 лет после публикации «Опытов» его идеи могут найти новых поклонников. В нашей компании, например, идея использования человека в качестве призмы успешно применяется для повышения качества интерфейсов.

Проверка качества — не задача дизайнера

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

Проверка качества — юзабилити-тестирование?

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

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

Выбор региона на сервисе прогноза погоды (снимок сделан 20.10.2008).

Проверка качества — мистер Х?

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

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

I уровень — «контрольный список»

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

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

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

II уровень — «юзкейсы»

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

Перед началом работы над проектом интерфейса дизайнер обязан составить список задач, которые пользователи будут решать с помощью проектируемого продукта. Задачи должны быть проранжированы по важности и по частоте. Однако впоследствии в ходе работы над интерфейсом, задачи нередко уходят на второй план и к ним возвращаются нечасто. Хороший способ проверить интерфейс — взять такие задачи и попробовать их выполнить самому, пускай и в прототипе. Задач должно быть немного, и они должны быть сформулированы максимально конкретно. Например: «Узнать сколько стоит страховой полис для моего автомобиля, квартиры, поездки» или «Заказать 3-ий том Мишеля Монтеня «Опыты» с доставкой на дом». Проверяющему также важно знать, как часто выполняется такая задача, раз в месяц или несколько раз в день, кроме того, полезно иметь представление о целевых пользователях.

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

III уровень — «глобальный»

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

Правки — диалог, а не монолог…

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

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

1. Объект обсуждения не должен меняться в ходе разработки интерфейса. Необходим универсальный идентификатор места в прототипе. В контексте прототипов такими идентификаторами являются уникальные названия для страниц, которые не должны меняться в процессе разработки. Прототип разрастается от версии к версии и страницы меняют свое местоположение, а соответственно и номера. Уникальное название дает возможность на любом этапе разработки найти страницу, к которой относилась правка.
2. Дизайнер обязан ответить на замечания проверяющего. Часто не все необходимо исправлять, а требуется лишь пояснить какие-то моменты. Иногда дизайнеру кажется, что все работает, тогда как проверяющий не понимает как, и это уже повод задуматься — в интерфейсе есть возможность для улучшений.
3. Все изменения вносятся в историю изменений.  Используя ссылки истории изменений легко понять, как исправлено то или иное замечание.
4. Для учета замечаний мы используем таблицу, которая помогает нам соблюдать эти правила (в первом столбце — идентификатор страницы прототипа, далее, последовательно — требования проверяющего и ответы дизайнера). После каждой версии таблица расширяется. По некоторым замечаниям диалог продолжается чуть ли не все время жизни проекта.