Однако, каким бы не был интерфейс, мы всегда делаем его одинаково — мы быстро делаем прототип интерфейса, а затем улучшаем и перерабатываем его до тех пор, пока интерфейс не начинает работать так, как надо пользователям и заказчику. Большинство наших прототипов — файлы Adobe PDF с работающими кнопками и/или ссылками (вот пример нашего прототипа), но, конечно, мы выбираем технологию в зависимости от поставленной задачи.

Проект по дизайну интерфейса чаще всего строится следующим образом:

1. Мы быстро готовим первую версию прототипа интерфейса, как мы его видим. Наш опыт показывает, что при наличии прототипа дальнейшее обсуждение получается гораздо более плодотворным и предметным.
2. Прототип обсуждается с заказчиком и одновременно проходит наш внутренний контроль.
3. Прототип эволюционирует — выявленные проблемы исправляются, растет число функций и объем интерфейса.
4. Шаги 2 и 3 повторяются, пока мы не получаем интерфейс, который нравится нам и заказчику. Одна такая итерация занимает не более недели. Порой в ходе проекта интерфейс полностью меняется два-три раза.
5. Если позволяет проект, прототип либо тестируется, либо проверяется иным исследованием.
6. После передачи финальной проектной документации заказчику мы сопровождаем разработку. В стоимость стандартного контракта входит полугодичный период, в течение которого мы готовы корректировать наши решения и консультировать разработчиков без дополнительной оплаты.

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

1. Эксперты нашей компании изучают интерфейс, выделяют его слабые и сильные места и составляют список вопросов тестирования, т.е. формулируют гипотезы о том, что в интерфейсе предположительно работает плохо (и что — хорошо).
2. Мы составляем набор заданий, отражающих наиболее частотные в деятельности пользователей задачи, покрывающие большую часть (или всю) функциональности системы. Набор заданий формируется таким образом, чтобы в результате эксперимента найти ответы на вопросы тестирования.
3. На основе данных клиента о группах пользователей составляем набор вопросов для рекрутинга, которые позволяют отобрать типичных представителей аудитории продукта.
4. Имитируем рабочую обстановку и предлагаем выбранным пользователям выполнить тестовые задания либо в самой системе, либо в прототипе будущего интерфейса. В это время протоколируются возникающие проблемы пользователей (вопросы, недоумения, отвлечения, ошибки и другое). Если это необходимо, проверяется соответствие интерфейса ранее заданным юзабилити-характеристикам, например, безошибочности, скорости работы и обучения.
5. Полученные результаты анализируются. Мы создаем отчет, описывающий обнаруженные проблемы интерфейса, их важность, возможные причины возникновения этих проблем, а также способы их устранения. Отчет соответствует стандарту Common Industry Format (ISO/IEC 25062:2006) или требованиям клиента.
6. При необходимости, интерфейс перерабатывается и тестируется опять.

Как правило, тестирование на 12-15 респондентах занимает три недели (если респонденты не очень специфические).

Наша лаборатория позволяет:

• Моделировать реальные условия работы пользователя с программным продуктом.
• Тестировать приложения для компьютера и мобильного телефона, интернет, WAP- и мобильные сайты, тач-скрин интерфейсы.
• Записывать и анализировать видеопротоколы (экран респондента и его лицо) с помощью TechSmith Morae.
• Собирать автоматически данные о результатах выполнения задания, времени выполнения и количестве ошибок, а также об отдельных действиях респондента (клики, клавиатурный ввод) и/или модератора (взаимодействие с респондентом).
• Анализировать направление и продолжительность фокусировки взгляда респондентов (eye tracking).
• Наблюдать за тестированием в офисе компании или дистанционно через интернет (транслируются содержимое экрана, видео с лицом респондента и общим видом лаборатории).

Мы — первая компания, начавшая проводить коммерческие юзабилити-тесты в России. С 2001 года мы накопили большой опыт такой работы и располагаем отлаженной технологией тестирования.

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

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

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

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

Как правило, экспертная оценка выполняется по следующему алгоритму:

1. Нами составляется набор частотных и важных пользовательских задач и ситуаций, которые должен успешно отрабатывать интерфейс.
2. 3-5 наших экспертов (больше – дороже), практикующих дизайнеров интерфейсов и/или юзабилити-специалистов, независимо друг от друга анализируют интерфейс. При этом проверяются: совместимость интерфейса с определенными на первом этапе задачами,  отклонения интерфейса от текущих стандартов (например, Windows User Experience), качество интерфейсных текстов и др. Каждую проблему эксперты рейтингуют по важности и, если это необходимо, предлагают решение.
3. Списки проблем сводятся вместе. Общий список обсуждается экспертами, после чего они повторно оценивают интерфейс и на основе уже новых замечаний и оценок проблем формируют окончательный отчет и набор рекомендаций по решению выявленных проблем.

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

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

Кроме того, включение в проектную команду наших специалистов обеспечивает еще и проработку интерфейсной составляющей – при таком прототипировании мы делаем не просто интерфейс, а как минимум неплохой интерфейс (хотя главное, конечно, сделать ТЗ, с которым согласны все участники проекта).

Мы пишем справку одновременно с дизайном интерфейса, что дает нам дополнительные возможности для улучшения интерфейса:

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

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

В таких условиях наилучший КПД дает разработка стандарта на интерфейс. Как это происходит:

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

В результате вы получаете:

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

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

Возможно проведение одной или нескольких сессий курса, продолжительность сессии — 2 дня. Индивидуальные курсы проводятся на территории заказчика.

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

Тем не менее, разработанному нами базовому дизайну можно добавить визуальной привлекательности за счет тщательной прорисовки:

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

Для этих видов работ мы рекомендуем компанию VisualPharm известного российского графического дизайнера Ивана Бойко (графический дизайн во всех наших проектах, начиная с конца 2005 года, выполняет эта компания). Независимо от того, кто подписывает контракт на графический дизайн, мы или VisualPharm, визуальное решение для разработанных нами интерфейсов проходит эргономическую экспертизу Usethics.