Эвристики Нильсена

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

1. дизайн-систему,
2. конкретный пользовательский сценарий,
3. ограничения разработки.

Здесь мы опишем то, как наши UX-дизайнеры используют 10 эвристик Нильсена в работе над платформой SimpleOne:

1. Видимость состояния системы

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

2. Соответствие между системой и реальным миром

В системе для автоматизации бизнес-процессов SimpleOne мы стараемся сделать всё настолько понятным, чтобы разобраться мог не только системный администратор, но и, например, бухгалтер. В специфичных интерфейсах мы допускаем сложные терминологические формулировки, но всегда сопровождаем их подсказкой, чтобы не заставлять неопытного разработчика постоянно обращаться к документации. Что касается элементов, универсальных для любого ПО (например, обозначение области drag&drop, иконок, скролла), тут мы руководствуемся общепринятыми правилами проектирования компонентов: область drag&drop должна быть обозначена, иконки подписаны (например, используем подсказку по наведению), скролл похож на скролл.

3. Пользовательский контроль и свобода

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

4. Последовательность и стандарты

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

5. Предотвращение ошибок

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

6. Узнаваемость, а не воспоминание

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

7. Гибкость и эффективность использования

У каждого пользователя свой подход к взаимодействию с интерфейсом и свой индивидуальный опыт. Для кого-то подсказки нужны, кто-то обходится без них. Кто-то нажимает на кнопку "отмена", а кто-то на "крестик", хотя они выполняют одно и то же действие. Кто-то привык добираться до нужного раздела с помощью поиска, кому-то легче открыть навигацию, многие же вообще используют адресную строку. Всех этих пользователей необходимо поддерживать в равной степени: создавать понятные и запоминающиеся наименования таблиц, дублировать "крестик" кнопкой "отмена" в модальном окне, а ещё добавлять функцию закрытия окна с помощью клавиши Esc для продвинутых.

8. Эстетичный и минималистичный дизайн

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

9. Помощь пользователям в устранении ошибок

Для подсвечивания ошибок мы делаем понятный всем пользователям текст, конструктивно излагаем, что произошло и, по возможности, предлагаем выход. Для более опытных пользователей даём ссылку на логи, где они смогут диагностировать причины ошибки. Менее опытным помогаем связаться с поддержкой. В зависимости от контекста, мы делим ошибки визуально: ошибка при доступе к странице (stub page) высвечивается на весь экран, ошибка при сохранении записи - в динамическом окне справа (tost или flash message).

10. Справки и документация

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