Комильфо интерфейса пользователя

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

Кто ответит за дизайн?

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

Рекомендации по оформлению

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

Кнопки

Кнопки бывают нескольких видов:

• кнопки прямого действия (командные кнопки), запускают какое-то действие;
• кнопки доступа к меню, название говорит само за себя;
• чекбоксы и радиокнопки, позволяют пользователю делать выбор из множества вариантов.

Другие возможные нестандартые решения так или иначе можно отнести к одному из этих трех основных видов кнопок (к примеру, umbrUI — CSS3 range slider, checkbox + radio button — нестандартная реализация стандартных кнопок). Кстати говоря, ссылка — тоже командная кнопка, но ссылки в интерфейсе программ используются гораздо реже, поэтому о них речи не будет.
Из неформального определения командной кнопки следует, что лишь по нажатию оной может быть иницировано действие, и ни в коем случае не понажатию чекбоксов или радиокнопок.

Размер:

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

Положение:

• Нежелательно размещать кнопки впритык, лучше оставлять между ними пустой промежуток, потому как одно дело, когда пользователь промахивается мимо кнопки, и совсем другое — если, промахнувшись, он еще и ошибочно нажимает на другую кнопку.
• Совершенно неприемлемо удалять из видимости те кнопки, на которые нажать нельзя, взамен этого их необходимо делать неактивными, иначе пользователь будет теряться («клянусь, эта кнопка только что была здесь!»).
• В группе не должно быть менее двух радиокнопок (это очевидно, однако, бывают случаи...). Помимо этого, как минимум одна радиокнопка должна быть отмечена по умолчанию, об этом частенько забывают.
• Желателен вертикальный порядок чекбоксов и радиокнопок, приемлемо и расположение в две-три колонки, но никак не в разноброс. Пользователь должен сразу видеть, какие кнопки к какой группе относятся.

Текст:

• Надпись на кнопке по возможности должна быть в виде глагола в форме инфинитива (Прийти, Увидеть, Нажать) и как можно более точно отражать суть.
• Более внимательно нужно отнестись к использованию к кнопки «ОК» и по возможности заменять «ОК» на соответствующий глагол. Об этом читаем тут: Почему кнопка «ОК» теперь считается дурным тоном в дизайне.
• Желательно совсем отказаться от использования кнопки «Применить», особенно в наборе OK-Применить-Отмена. Такое сочетание кнопок порождает некоторые неопределенности у пользователя, не будем обсуждать какие.
• На кнопке доступа к меню должна быть какая-нибудь индикация о том, что она именно отображает меню (самый лучший вариант — стрелочка вниз/вбок).
• Подписи к кнопкам не должны содержать отрицание во избежание возможных заблуждений пользователя.
• Пользователь скажет вам отдельное спасибо, если подписи к чекбоксам и радиокнопкам так же будут реагировать на нажатие.

Списки

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

Размер:

• Ширина списка должна быть достаточна как минимум для того, чтобы пользователь мог различить его элементы.
• Высота списка не должна превышать 7-8 строк. Такое количество элементов легче запоминается.

Поля ввода

Размер:

• Ширина поля должна соответствовать объему вводимого текста.
• Так же ширина поля не должна быть больше максимальной длины строки. Если пользователь ввел в поле максимальное количество символов, и наблюдает пустое пространство, то он может подумать, что где-то ошибся, не надо вводить пользователя в заблуждение.

Текст:

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

Меню

Текст:

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

Пиктограммы:

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

Группировка:

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

Контекстное меню:

• Контекстное меню не должно быть единственным способом вызова функций.
• Меню желательно делать не особо длинным, 7-8 элементов.
• В контекстном меню особенно важен порядок — первыми должны быть более релевантные элементы.

Прочее

• Горизонтальные полосы прокрутки — это очень плохо. Пользователь их не любит.
• В строке заголовка окна первым должно идти имя документа, а лишь затем — приложения. Ярким примером служит Microsoft Word 2003: «Microsoft Word — Document1.doc», и при большом количестве открытых окон в панели задач не будут различимы наименования документов.
• Строку статуса необходимо использовать либо как индикатор состояния системы, либо как панель инструментов для опытных пользователей. Худшим вариантом является использование строки статуса в качестве подсказок при наведении на тот или иной элемент окна.
• Панель инструментов нежелательно делать единственным способом вызова функций.

Отклик системы:

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

И, главное, не надо бояться копировать успешные и эффективные решения чужих интерфейсов! Интуитивный интерфейс — это знакомый интерфейс. Единообразие приложений очень важно. Если пользователь, к примеру, привык сохранять документ на сочетание Ctrl+S, то не надо в своем приложении учить его новым сочетаниям клавиш.

Использованная литература

В. В. Головач. «Дизайн пользовательского интерфейса».
Джеф Раскин. «Интерфейс: новые направления в проектировании компьютерных систем».
Дженифер Тидвелл. «Разработка пользовательских интерфейсов».
Рекомендации Алана Купера и Стива Круга.