Проблема
Программист часто выполняет роль дизайнера пользовательских интерфейсов. Можно поспорить, хорошо ли это. Однако, особенно в небольших компаниях, это реальность, которую не изменить.
Я верю, что программист может сделать очень приличный интерфейс. В этом посте я бы хотел собрать несколько советов, которые помогут программисту более или менее успешно погрузиться в иррациональный мир пользователей и проектировать неплохие интерфейсы.
Оговорюсь, что эти советы скорее подходят программистам, которые вынуждены заниматься разработкой пользовательского интерфейса. То есть по каким-либо причинам в компании нет дизайнера, регулярных юзабилити тестирований, процесса проектирования интерфейсов и т. п.
Простота
Задачи пользователя. Любой интерфейс – это зло. Пользователь использует продукт не ради продукта, а ради того, чтобы решить какую-то свою задачу. Например, мы используем интерфейс набора телефонного номера не для того, чтобы набрать номер, а для того, чтобы поговорить с другим человеком. Сам факт набора является необходимой операцией, которую навязывает технология.
Таким образом, создавая каждую форму, диалог или панель я постоянно задаю себе вопрос: «какую задачу пользователя я сейчас решаю?». Если выходит, что я пытаюсь решить несколько задач одной формой (или панелью), то скорее всего что-то не так. В таких случаях надо подумать, что является основной функцией, а что – фичей «не для всех».
Правило 20/80. Как известно, 20% усилий дают 80% результата. Зачастую для задач 80% пользователей достаточно 20% форм/диалогов/панелей. Стало быть, при создании интерфейса надо быть очень аккуратным, когда выбираешь те двадцать ключевых процентов.
Перед тем как добавлять ещё одну кнопку, чекбокс, поле, ссылку, я пытаюсь ответить на вопрос: «будут ли этой функцией пользоваться 80% пользователей?». Если нет, то на помощь приходит техника progressive disclosure.
Например, вот панель настроек из Firefox:
Понятно, что большинство пользователей блокируют поп-апы и разрешают загрузку изображений отовсюду. Лишь небольшое количество вручную указывают сайты-исключения.
Разъяснения. Интерфейс можно назвать простым, если он не требует дополнительных разъяснений. То есть, если для дальнейших действий надо прочитать небольшой текст, объясняющий что к чему, то очень вероятно, что интерфейс чересчур сложен. В таких случаях я думаю о том, можно ли сделать более интерактивное управление, стоит ли разбить процесс на несколько шагов, добавить поясняющую картинку, и т. п.
Например, для настройка тачпада на макбуках выглядит вот так:
То есть, поясняющий текст вроде «поступательные движения тремя пальцами по тачпаду вперёд перемещает некоторые приложения на следующую страницу» заменили небольшим видео, из которого всё ясно.
Лишние вопросы. Часто интерфейс спрашивает пользователя о чём-либо. Обычно это поп-ап с кнопками «ОК» и «Отмена». Порой вопрос вполне уместен. Однако, в большинстве случаев вопрос только мешает. Войну поп-апам объявили давно. Тем не менее, я бы хотел привести наиболее популярные типы лишних вопросов:
- Вопрос, который может понять лишь 20% пользователей.
Например:
Те, кто знаком с тем, что такое keychain, поймут вопрос и ответят на него верно. Однако, большинство пользователей, скорее всего, пожмёт плечами и нажмёт «Allow».
- Вопрос, не имеющий отношения к текущей задаче. Это случается очень часто: вы работаете с какой-то программой, и тут возникает поп-ап:
Это заставляет забыть о текущей задаче и срочно принимать совершенно неожиданное решение.
- Вопрос, на который система вполне может ответить сама. Например, при удалении файла из какой-то временной папки необходимо ответить на вопрос:
Система знает, что этот файл временный и не очень-то и нужен. Более того, пользователь всегда может его восстановить.
Undo. Люди ошибаются. Приложение должно быть готово к этому. В идеале, должна быть возможность отменить любое действие пользователя. Каждый раз, когда пользователь принимает решение (например, выбирает юзернейм, удаляет файл или меняет конфигурацию), он может ошибиться. Очень грустно, если система не позволит исправить эту ошибку.
Тут же хочется отметить, что нельзя полагаться на вопросы, вроде «Вы уверены, что...?» или предупреждения, «Внимание! Это действие приведёт к ...!». Во-первых, не все их читают, а, во-вторых, из тех, кто читает, далеко не все действительно понимают, что именно имеет в виду система.
Единообразие
Зачастую скромный, аккуратный интерфейс гораздо приятнее для глаза, чем богато украшенный и сильно анимированный. Самый простой способ сделать привлекательный интерфейс – это стараться делать всё одинаково.
Компоненты. Кнопки, чекбоксы, текстовые поля и т. п. должны выглядеть одинаково по всему приложению. Очень неаккуратно выглядят компоненты очень похожие друг на друга. Например, плохо, если иногда прогресс бар в чёрной рамочке, а иногда – в серой. Хорошо, если прогресс-бар всегда реализован одним и тем же компонентом и всегда выглядит одинаково.
Поведение. В разных ситуациях одинаковые компоненты должны вести себя похоже. Например, кнопка «назад» всегда должна возвращать на предыдущую страницу. Или, если зелёная кнопка всегда открывает дополнительное диалоговое окно, то она дожна открывать его действительно во всех контекстах.
Расположение компонентов. Интерфейс выглядит очень неаккуратно, если компоненты разбросаны невпопад. Если нарисовать несколько линий и располагать компоненты по ним, то интерфейс будет выглядеть намного аккуратнее. Например:
Оформление текста. Обращайте внимание на лейблы! Стоит выработать и придерживаться правил, где и что пишется с большой буквы, где ставится многоточие (...), где ставятся точки. Очень важно одинаково именовать объекты системы: если где-то есть меню «параметры», то в другом месте это же меню никак не может называться «опции».
Стиль. Шрифты, цвета, иконки – всё это должно быть по возможности одинаково для всего приложения. Не стоит вводить в систему новые гарнитуры или новые начертания шрифтов. Стоит придерживаться основных цветов (зачастую, эти цвета являются «цветами компании»). Иконки дожлны обладать одинаковым стилем (например, если везде используются иконки в виде чёрно-белых силуэтов, не стоит добавлять новую цветную трёхмерную иконку).
Общение
Классическое замечание о том, что программисты часто не представляют, как пользователи используют продукт, увы, очень не далеко от правды. В идеале можно устроить запись взаимодействия пользователя с программой, проанализировать её, сделать выводы о недостатках интерфейса. Однако, когда такой возможности нет, полезно побеседовать с различными командами, чтобы получить представление о том, что ожидают от системы. Я предпочитаю беседы в неформальной обстановке, например, за обедом.
Продукт менеджмент. Мне кажется, что продукт менеджер должен быть верным другом программиста. Техническое задание (aka PRD) – это один из основных документов, помогающих понять «чо надо-то». Именно с продукт менеджером можно обсудить спорные моменты, попросить собрать необходимые данные, указать на возможные сложности, связанные с реализацией. Очень здорово, если техническое задание содержит наброски интерфейсов. Это в разы облегчает понимание того, что требуется создать.
Группа поддержки. Мне кажется, группа поддержки (aka support) ближе всего к самим пользователям системы. Именно к ним обращаются пользователи когда что-то не понятно, что-то работает не так, как ожидает пользователь, именно они объясняют, как надо использовать систему. Очень часто они подают идеи новых функций, которые могут в разы облегчить работу с продуктом.
Чтение саппорт тикетов, да и просто беседа с кем-либо очень открывает глаза на реальное положение дел.
Группа продаж. Я нашел очень полезным задавать коллегам из группы продаж (aka sales) вопросы о том, что можно изменить в интерфейсе, чтобы продукт было проще продать. Ответы могут быть очень интересными. Может, укажут на продукты конкурентов, может, попросят сделать «повебдванольее». Иногда можно услышать много интересного.
Заключение
Конечно, эти рекомендации не полны. Про удобство пользователя написаны книги. Есть специалисты в этой области, есть много консалтинговых компаний. Однако, я надеюсь, что этот пост сделает несколько интерфейсов чуть проще, аккуратнее, продуманнее.
А какие советы программисту-дизайнеру дали бы вы?
