О мелочах в интерфейсе

Семен Куликов, 29.11.2007

Вы когда-нибудь пробовали переименовать файл в Windows? Наверняка. Для этого нужно войти в режим переименования, выделить название и ввести новое. Риторический вопрос: «Как часто вместе с именем файла вы меняете расширение?» Описанная схема переименования прошла через несколько версий операционной системы, прежде чем в новой Vista (как бы кто к ней ни относился) разработчики исправили ситуацию — в режиме редактирования автоматически выделяется только название файла.

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

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

(Почему возникают)

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

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

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

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

(Почему важны)

С позиции пользователя мелочи бывают трех типов:

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

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

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

Впрочем, в ряде случаев мелочи, как и субъективная удовлетворенность, не играют важной роли в популярности продукта. Это происходит в ситуациях, когда система для пользователя является основным рабочим инструментом, к которому он привык (классический пример — Windows), и/или у него просто нет выбора (1C).

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

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

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

(Как бороться)

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

С позиции проектирования мелочи можно классифицировать:

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

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

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

Элементы управления

Если на какой-то объект можно нажать, как правило, это должно быть видно: кнопки выпуклые и/или выделены цветом, ссылки подчеркнуты (выделения цветом недостаточно).

Элементы, раскрывающие меню при нажатии, снабжаются стрелкой, показывающей, в какую сторону раскроется меню.

Текст кнопки и ссылки, открывающей новое окно или страницу, на которой от пользователя требуется совершение неких действий, заканчивается многоточием (например: «Изменить параметры…»). Как правило, под такими действиями подразумевается ввод данных: заполнение формы, выбор и т. д. Так, в текстовых редакторах пункт меню «Файл — Закрыть» не имеет многоточия, хотя и открывает окно подтверждения, а «Файл — Открыть…» имеет, так как требует уточнения имени файла.

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

И название, и обложка книги — ссылки (Amazon.com).

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

Модальные окна должны быть снабжены кнопкой «Закрыть». Ее отсутствием часто страдают интернет-приложения. Также следует рассмотреть возможность закрытия окна по клику в любом месте рабочей области, например, если окно представляет собой картинку, открывшуюся в новом слое.

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

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

Текущий раздел сайта выделяется в меню, оставаясь при этом ссылкой.

Формы ввода

Как это ни странно, поля ввода должны выглядеть как поля ввода. Хороший вкус проявляется не в изысканном оформлении элементов формы, а в том, что пользователя не заставляют задумываться, что перед ним — поле или кнопка.

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

При неправильном заполнении поля появляется подсказка (Yahoo.com).

Если поле многострочное, нажатие Enter должно по умолчанию приводить только к созданию новой строки, но никак не дублировать терминальную кнопку.

Клик на подписи к чекбоксу или переключателю (радиокнопке) должен их устанавливать.

Для «резиновых» форм необходимо прорабатывать минимальный (всегда) и максимальный (часто) размер полей.

Часто система может догадываться или знать наверняка значения некоторых полей. Автозаполнение и подстановка значения по умолчанию могут сэкономить время пользователя.

Терминальные кнопки должны находиться после всех элементов формы, под ней.

После отправки формы необходимо показывать соответствующее сообщение (пример: Gmail).

Опытным пользователям будет очень приятно, если форма будет понимать стандартные сочетания быстрых клавиш (такие, например, как Ctrl+S для сохранения и Сtrl+Enter для отправки формы).

Форма ввода должна быть активна сразу после появления, чаще всего нет необходимости заставлять пользователя ставить курсор в поле ввода. Так, например, работают все поисковые системы, первые страницы которых представляют собой форму с одним полем. Жаль, что так же не ведут себя Википедия и Грамота.ру.

Текст

Орфографические ошибки. Все просто — их быть не должно. Сообщения на сайтах «На Вашем счету 10 руб.» и «Сегодня 1 Сентября» — это ошибки.

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

Часто возникают неоднозначности в формулировании обращений «мое»/«ваше», например, пункт меню может называться как «мои счета», так и «ваши счета». Здесь действует простое правило: если система обращается к пользователю, сообщая ему что-то, то «ваше» (например, текст на странице: «Ваш баланс меньше 10 руб.»), если пользователь сообщает что-то системе, нажимая на пункты меню, кнопки, ссылки и т. д. — «мое» (например, ссылка: «Мой баланс»).

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

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

Представление информации

Хорошо представить данные в таблице — сложная и нетривиальная задача для дизайнера. Однако есть несколько общих приемов, позволяющих облегчить пользователю чтение таблицы:

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

Вообще, избыточная информация чаще всего мешает. Так, не стоит показывать целиком длинные URL, у которых важны, как правило, только начало и конец (www.usethics.ru/lib/…/curseur.html), и вообще длинные строки, часть которых одинакова (например, номера пластиковых карт: *1234).

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

Если информация выводится постранично, навигация между страницами должна быть снабжена ссылками вперед/назад, кликнуть по которым значительно проще, чем по номеру страницы.

Выцеливать эти ссылки, мягко говоря, непросто.

Технические мелочи

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

URL страниц на сайте, по возможности, должны быть читаемы (Человеко-Понятные URL, ЧПУ).

В социальных сервисах персональные страницы пользователей должны иметь уникальные URL (в противном случае развитие сервиса может быть затруднено — пользователь не сможет никому дать свой адрес).

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

(В терминах пользователя)

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

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

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

Что делать?

Для того, чтобы общая ситуация менялась к лучшему, необходимо выполнение нескольких условий (от частных к общим):

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

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


One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.