В конце прошлого года мы разработали интерфейс программной платформы «Астерос Бизнес Контакт». Сделали разные интерфейсы для трех режимов работы платформы.

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

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

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

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

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

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

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

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

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

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

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

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

Этот проект хорошо иллюстрирует тот факт, что требования к проекту постоянно эволюционируют. В процессе работы постоянно появляются новые детали, уточнения, находятся наиболее эффективные пути решения тех или иных задач. Без тщательного проектирования все могло бы свестись к бесконечной переделке дизайна, что накладно для обеих сторон. А мы, аналитики-юзабилисты, как обычно всех спасли=)