Определение
10 эвристик юзабилити Нильсена — это набор универсальных принципов, по которым эксперт оценивает качество пользовательского интерфейса. Эвристики были разработаны Якобом Нильсеном и Рольфом Молихом в 1990 году и уточнены Нильсеном в 1994-м на основе факторного анализа 249 реальных проблем юзабилити. С тех пор они стали золотым стандартом экспертной оценки интерфейсов во всём мире.
Десять эвристик охватывают основные аспекты взаимодействия человека с системой:
- Видимость статуса системы — система должна сообщать пользователю, что происходит.
- Соответствие между системой и реальным миром — интерфейс должен говорить на языке пользователя.
- Свобода и контроль пользователя — возможность отменить действие и вернуться назад.
- Единообразие и стандарты — одинаковые вещи должны выглядеть и работать одинаково.
- Предотвращение ошибок — лучше не допустить ошибку, чем помочь исправить.
- Узнавание, а не припоминание — информация должна быть на виду, а не в памяти пользователя.
- Гибкость и эффективность использования — ускорители для опытных пользователей.
- Эстетичный и минималистичный дизайн — ничего лишнего, только нужное.
- Помощь в распознавании, диагностике и исправлении ошибок — сообщения об ошибках должны быть понятными.
- Справка и документация — помощь должна быть доступна, когда она нужна.
Эвристическая оценка — это метод, при котором несколько экспертов независимо проходят интерфейс, фиксируя нарушения этих принципов. Метод не заменяет юзабилити-тестирование с реальными пользователями, но дополняет его: он быстрее, дешевле и позволяет выявить типовые проблемы ещё до первого контакта с аудиторией.
Как появились эвристики
1990 год. Якоб Нильсен и Рольф Молих публикуют статью «Improving a Human-Computer Dialogue» в журнале Communications of the ACM. В ней они предлагают новый подход к оценке интерфейсов: вместо формальных чек-листов из сотен пунктов — компактный набор общих принципов, которые эксперт может удерживать в голове, проходя интерфейс. Они назвали эти принципы эвристиками — по аналогии с эвристиками в когнитивной психологии: не точные алгоритмы, а правила-ориентиры, которые в большинстве случаев приводят к верному результату.
Первоначальный набор включал девять принципов и был достаточно абстрактным. Нильсен продолжил работу: он собрал 249 реальных проблем юзабилити из разных проектов и провёл факторный анализ, чтобы выяснить, какие принципы наиболее точно объясняют наблюдаемые проблемы. В 1994 году вышли две ключевые работы: книга «Usability Inspection Methods» (в соавторстве с Робертом Маком) и обновлённый список из 10 эвристик, который используется по сей день.
Контекст появления важен. В начале 1990-х юзабилити как дисциплина переживала переломный момент. С одной стороны, росло понимание того, что интерфейсы нужно тестировать — слишком много дорогих систем оказывались непригодными для работы. С другой стороны, полноценное юзабилити-тестирование с пользователями стоило дорого и занимало недели. Нильсен предложил метод, который мог провести один-два эксперта за несколько часов — и при этом выявить значительную часть проблем.
Нильсен был не единственным, кто работал в этом направлении. Бен Шнейдерман в 1986 году опубликовал «8 золотых правил проектирования интерфейсов» (8 Golden Rules of Interface Design) — во многом пересекающийся набор принципов. Джилл Герхардт-Пауэлс в 1996 году предложила «принципы когнитивной инженерии» (cognitive engineering principles), ориентированные на снижение когнитивной нагрузки. ISO 9241 формализовал требования к эргономике программных интерфейсов. Но именно эвристики Нильсена стали де-факто стандартом — благодаря лаконичности, практичности и обширной эмпирической базе. Они оказались достаточно общими, чтобы работать для любого интерфейса, и достаточно конкретными, чтобы находить реальные проблемы.
10 эвристик с примерами
1. Видимость статуса системы (Visibility of system status)
Система должна всегда информировать пользователя о том, что происходит, через своевременную и уместную обратную связь.
Человек не может работать с чёрным ящиком. Когда система молчит, пользователь не знает: его запрос принят? Процесс идёт? Произошла ошибка? Каждая секунда без обратной связи порождает неуверенность — и желание нажать кнопку ещё раз, обновить страницу, закрыть приложение.
Хорошие примеры. Индикатор загрузки с процентами: пользователь видит, что файл загружается, и может оценить, сколько ждать. Статус заказа в интернет-магазине: «оплачен — собирается — передан курьеру — доставлен». Подсветка активного пункта меню: пользователь понимает, в каком разделе находится.
Плохие примеры. Форма отправлена, но экран не изменился — пользователь не знает, дошло ли сообщение. Долгая загрузка без индикатора — пользователь думает, что система зависла. Кнопка нажата, но визуально ничего не произошло.
В медицинском контексте. На сайте клиники пациент записывается к врачу. После нажатия кнопки «Записаться» он должен немедленно увидеть подтверждение: дата, время, врач, адрес филиала. Без этого пациент не уверен, что запись состоялась, — и может записаться повторно или позвонить в регистратуру.
2. Соответствие между системой и реальным миром (Match between system and the real world)
Система должна говорить на языке пользователя — использовать знакомые слова, фразы и концепции, а не системный жаргон. Информация должна быть организована в естественном и логичном порядке.
Это эвристика о ментальных моделях. Пользователь приходит в интерфейс с набором ожиданий, сформированных реальным миром. Корзина покупок работает как корзина: туда кладут товары, оттуда их можно убрать, и в конце — «оплатить на кассе». Если интерфейс нарушает привычную метафору — например, товар нельзя убрать из корзины после добавления — пользователь теряется.
Хорошие примеры. Иконка конверта для электронной почты — метафора из реального мира. Калькулятор на экране, который выглядит как физический калькулятор. Карточка товара с фотографией, ценой и кнопкой «В корзину» — знакомая структура.
Плохие примеры. Сообщение «Error 0x80070005: Access denied» вместо «У вас нет прав для этого действия». Кнопка «Сабмит» на русскоязычном сайте. Навигация по сайту, организованная по внутренней структуре компании, а не по задачам пользователя.
В медицинском контексте. Сайт клиники, который предлагает «записаться к оториноларингологу», не учитывает, что большинство пациентов ищут «ЛОР-врача». Названия услуг — «аудиометрия», «тимпанометрия» — понятны специалисту, но бессмысленны для пациента. Интерфейс должен использовать бытовой язык: «проверка слуха», «обследование уха».
3. Свобода и контроль пользователя (User control and freedom)
Пользователи часто выбирают функции по ошибке и нуждаются в чётко обозначенном «аварийном выходе» — возможности отменить действие и вернуться в предыдущее состояние.
Свобода — это не просто кнопка «Назад». Это философия: пользователь должен чувствовать, что он управляет системой, а не система им. Каждое действие должно быть обратимым, каждый шаг — предсказуемым, каждый тупик — иметь выход.
Хорошие примеры. Функция «Отменить» (Ctrl+Z) в текстовых редакторах. Gmail: после удаления письма появляется полоска «Письмо удалено. Отменить» — у пользователя есть несколько секунд, чтобы передумать. Корзина для удалённых файлов — промежуточный этап перед окончательным удалением.
Плохие примеры. Форма из 10 шагов без возможности вернуться на предыдущий. Подписка, которую легко оформить, но невозможно отменить без звонка в поддержку. Модальное окно без кнопки закрытия.
В медицинском контексте. Пациент начал запись к врачу, но на третьем шаге понял, что выбрал не тот филиал. Если система не позволяет вернуться и изменить выбор без потери уже введённых данных — это нарушение эвристики. Запись должна легко отменяться и переноситься.
4. Единообразие и стандарты (Consistency and standards)
Пользователи не должны гадать, означают ли разные слова, ситуации или действия одно и то же. Следуйте платформенным конвенциям.
Единообразие бывает двух видов. Внутреннее: одни и те же элементы в разных частях вашего интерфейса работают одинаково. Внешнее: ваш интерфейс работает так же, как другие знакомые пользователю системы. Внешнее единообразие — это, по сути, закон Якоба: пользователи проводят большую часть времени на других сайтах и ожидают, что ваш будет работать так же.
Хорошие примеры. Логотип в левом верхнем углу ведёт на главную страницу — веб-конвенция, которую знают все. Красный цвет для ошибок, зелёный для успеха — единообразие через цвет. Одинаковый стиль кнопок на всех страницах сайта.
Плохие примеры. На одной странице действие называется «Сохранить», на другой — «Применить», на третьей — «Подтвердить», хотя во всех случаях происходит одно и то же. Ссылки, которые в одних местах подчёркнуты, а в других — нет. Форма входа, которая на мобильной версии работает иначе, чем на десктопной.
5. Предотвращение ошибок (Error prevention)
Ещё лучше, чем хорошие сообщения об ошибках, — тщательный дизайн, который предотвращает возникновение ошибок.
Нильсен выделял два типа ошибок: промахи (slips) — неосторожные действия при выполнении привычной задачи, и заблуждения (mistakes) — неверные решения, вызванные непониманием. Дизайн должен защищать от обоих типов. Промахи предотвращаются ограничениями и подсказками. Заблуждения — понятной структурой и предварительным просмотром результата.
Хорошие примеры. Диалог подтверждения перед удалением: «Вы действительно хотите удалить 47 файлов?» Валидация формы в реальном времени: поле email подсвечивается красным ещё до отправки, если адрес некорректен. Автодополнение в поле поиска — система предлагает варианты, снижая вероятность опечатки.
Плохие примеры. Кнопки «Сохранить» и «Удалить» расположены рядом, одинакового размера и цвета — промахнуться легко. Форма принимает дату в формате ММ/ДД/ГГГГ без подсказки — европейский пользователь введёт ДД/ММ/ГГГГ. Выпадающий список из 200 стран без возможности поиска.
В медицинском контексте. При записи к врачу система не должна позволять выбрать прошедшую дату или время, когда врач не принимает. Если пациент вводит дату рождения, формат должен быть однозначным — с подписями «день», «месяц», «год». Ошибка в медицинских данных может стоить здоровья.
6. Узнавание, а не припоминание (Recognition rather than recall)
Минимизируйте нагрузку на память пользователя: делайте объекты, действия и варианты выбора видимыми. Пользователь не должен запоминать информацию между разными частями интерфейса.
Эта эвристика напрямую связана с законом Миллера: рабочая память ограничена, и перегружать её — значит провоцировать ошибки. Интерфейс должен выступать внешней памятью: показывать контекст, подсказки, недавние действия — всё, что позволяет пользователю узнать нужный вариант, а не вспоминать его.
Хорошие примеры. Список недавно просмотренных товаров в интернет-магазине — не нужно вспоминать, что смотрел вчера. Автодополнение в поисковой строке с историей запросов. Хлебные крошки (breadcrumbs) — пользователь видит путь, по которому пришёл на текущую страницу.
Плохие примеры. Система требует ввести код товара по памяти вместо того, чтобы показать каталог. Настройки, разбросанные по разным разделам без указания текущих значений — чтобы узнать, что сейчас включено, нужно зайти в каждый раздел. Форма оплаты без отображения содержимого корзины — пользователь не помнит, что именно он покупает.
7. Гибкость и эффективность использования (Flexibility and efficiency of use)
Ускорители — невидимые для новичка — могут значительно повысить скорость работы опытного пользователя. Система должна быть удобна и для тех, и для других.
Новичок и эксперт работают с одним интерфейсом, но по-разному. Новичку нужна пошаговая навигация, подсказки и визуальные ориентиры. Эксперту — горячие клавиши, макросы, настраиваемые панели и возможность пропустить знакомые шаги. Хороший интерфейс обслуживает обоих, не мешая ни одному.
Хорошие примеры. Горячие клавиши в текстовых редакторах: Ctrl+B для жирного текста — эксперт не тянется к панели. Жесты в мобильных приложениях: свайп для удаления — быстрее, чем три тапа по меню. Настраиваемые шаблоны ответов в службе поддержки: оператор выбирает шаблон вместо того, чтобы набирать текст каждый раз.
Плохие примеры. Система, которая при каждом входе требует пройти стартовый тур без возможности его пропустить. CRM, в которой для создания типовой задачи нужно заполнить 15 полей, хотя 12 из них каждый раз одинаковые. Калькулятор без истории вычислений.
8. Эстетичный и минималистичный дизайн (Aesthetic and minimalist design)
Экраны не должны содержать информацию, которая не нужна пользователю или нужна ему редко. Каждый лишний элемент конкурирует с нужными и снижает их относительную видимость.
Эта эвристика перекликается с законом Хика: чем больше элементов на экране, тем дольше пользователь принимает решение. Минимализм — не про красоту, а про сигнал и шум. Каждый элемент интерфейса — это информация, которую мозг должен обработать. Если элемент не помогает пользователю решить текущую задачу — он мешает.
Хорошие примеры. Главная страница Google: одно поле ввода и две кнопки. Ничего лишнего, потому что задача одна — поиск. Пустая карточка товара в Apple Store: фото, название, цена, кнопка покупки — и белое пространство вокруг, которое направляет внимание.
Плохие примеры. Главная страница, забитая баннерами, акциями, новостями, виджетами погоды и курса валют — пользователь не понимает, куда смотреть. Дашборд с 20 графиками на одном экране, из которых актуальны три. Всплывающие окна с предложением подписаться, оценить приложение и включить уведомления — одновременно.
В медицинском контексте. На сайте клиники пациент ищет конкретного врача или услугу. Баннеры с акциями, всплывающие чаты, блоки «партнёры» и «лицензии» на каждой странице — это визуальный шум, который отвлекает от основной задачи. Информация о лицензиях важна, но её место — в подвале или на отдельной странице, а не в центре экрана.
9. Помощь в распознавании, диагностике и исправлении ошибок (Help users recognize, diagnose, and recover from errors)
Сообщения об ошибках должны быть выражены простым языком (без кодов), точно описывать проблему и предлагать конкретное решение.
Ошибки неизбежны. Вопрос — в том, как система помогает пользователю из них выбраться. Хорошее сообщение об ошибке отвечает на три вопроса: что произошло? Почему? Что делать дальше? Плохое сообщение создаёт дополнительную проблему поверх первой.
Хорошие примеры. «Пароль должен содержать не менее 8 символов. Сейчас — 6» — понятно, что не так и что делать. Страница 404 с поисковой строкой и ссылками на популярные разделы — пользователь не застревает в тупике. Автоматическое предложение «Вы имели в виду…?» при опечатке в поисковом запросе.
Плохие примеры. «Произошла ошибка. Попробуйте позже» — ни причины, ни решения. «Error 500» — технический код, который ничего не говорит пользователю. Красная рамка вокруг поля без объяснения, что именно введено неправильно.
В медицинском контексте. Пациент заполняет форму записи и получает сообщение «Ошибка валидации». Что с этим делать? Гораздо лучше: «Номер полиса ОМС должен содержать 16 цифр. Вы ввели 15 — проверьте, пожалуйста». Понятное сообщение снимает тревогу, которая и так высока у человека, обращающегося за медицинской помощью.
10. Справка и документация (Help and documentation)
В идеале система должна быть понятна без документации. Но если справка необходима — она должна быть легко доступна, ориентирована на задачу пользователя, содержать конкретные шаги и не быть избыточной.
Эта эвристика стоит последней не случайно. Если пользователь вынужден обращаться к справке — значит, первые девять эвристик где-то не сработали. Но реальные системы сложны, и полностью обойтись без справки удаётся редко. Задача — сделать её полезной, а не формальной.
Хорошие примеры. Контекстные подсказки (tooltips) рядом со сложными полями формы — справка появляется там, где нужна. Пошаговые руководства (wizards) для сложных процессов — вместо одной длинной инструкции. FAQ, организованный по задачам пользователя, а не по структуре продукта.
Плохие примеры. Справка в формате PDF на 200 страниц без поиска. Ссылка «Помощь», которая ведёт на общую страницу поддержки без связи с текущим контекстом. Документация, написанная для разработчиков, а не для пользователей.
Как проводить эвристическую оценку
Эвристическая оценка — не просто «пройти сайт и записать, что не нравится». Это структурированный метод с определённым протоколом, который обеспечивает воспроизводимость и полноту результатов.
Шаг 1: подготовка. Определить объект оценки (весь интерфейс или конкретные сценарии), выбрать набор эвристик (чаще всего — 10 эвристик Нильсена), подготовить шаблон для фиксации результатов. Важно определить целевую аудиторию и ключевые задачи — без этого эксперт не сможет оценить, насколько интерфейс соответствует потребностям пользователей.
Шаг 2: независимая оценка. Каждый из 3-5 экспертов проходит интерфейс самостоятельно, без обсуждения с коллегами. Это принципиально: групповая оценка приводит к конформизму — эксперты начинают соглашаться друг с другом вместо того, чтобы искать проблемы. Каждый эксперт проходит интерфейс минимум дважды: первый раз — знакомство с общей структурой, второй и третий — детальная проверка каждого экрана по каждой эвристике.
Шаг 3: фиксация проблем. Для каждой найденной проблемы эксперт записывает: какая эвристика нарушена, где именно (экран, элемент), в чём нарушение и какова его серьёзность. Нильсен предложил пятибалльную шкалу серьёзности:
- 0 — не проблема юзабилити. Нарушение формальное, пользователь не пострадает.
- 1 — косметическая проблема. Исправить, если есть время.
- 2 — незначительная проблема. Низкий приоритет исправления.
- 3 — серьёзная проблема. Высокий приоритет, значительно затрудняет работу.
- 4 — катастрофа. Исправить до релиза. Пользователь не может выполнить задачу.
Шаг 4: агрегация результатов. После того как все эксперты завершили оценку, результаты объединяются. Проблемы, найденные несколькими экспертами, получают более высокий приоритет. Итоговый список ранжируется по серьёзности — от катастроф к косметическим проблемам.
Шаг 5: отчёт и рекомендации. Для каждой проблемы формулируется рекомендация по исправлению. Отчёт структурирован так, чтобы команда разработки могла использовать его как руководство к действию: проблема — контекст — рекомендация — приоритет.
Сколько экспертов нужно? Нильсен исследовал этот вопрос эмпирически. Один эксперт находит в среднем 35% проблем юзабилити. Пять экспертов — около 75%. Дальше отдача резко падает: десять экспертов найдут около 85%, но стоимость удваивается. Оптимум для большинства проектов — 3-5 экспертов. Важна не только численность, но и разнообразие: эксперт с опытом в медицинских системах заметит проблемы, которые пропустит эксперт, работавший только с e-commerce.
Чем эвристическая оценка не является. Она не заменяет тестирование с реальными пользователями. Эксперт, каким бы опытным он ни был, не является пользователем: он не знает, какие термины понятны целевой аудитории, какие ментальные модели она использует, какие задачи считает приоритетными. Эвристическая оценка находит проблемы типа «кнопка не выглядит как кнопка» или «нет обратной связи после отправки формы». Но она не найдёт проблему «пациент не понимает, что означает ‘прикрепление к терапевту’» — для этого нужно наблюдать за реальными пациентами. Лучший результат даёт сочетание: сначала эвристическая оценка (быстро, дёшево, убирает очевидные проблемы), затем юзабилити-тестирование (глубже, дороже, выявляет проблемы, которые эксперт не видит).
Связь с юзабилити, UX и HCD
Эвристики Нильсена — не изолированный инструмент. Они вписываются в систему понятий о качестве взаимодействия человека с интерфейсом.
Юзабилити по стандарту ISO 9241-11 определяется через три метрики: эффективность, продуктивность и удовлетворённость. Эвристики напрямую оценивают все три: видимость статуса (эвристика 1) влияет на продуктивность — пользователь не тратит время на ожидание неизвестно чего. Предотвращение ошибок (эвристика 5) влияет на эффективность — меньше ошибок, меньше откатов. Эстетичный дизайн (эвристика 8) влияет на удовлетворённость — не через красоту как таковую, а через снижение когнитивной нагрузки.
UX (пользовательский опыт) шире юзабилити: он включает эмоции, ожидания, контекст использования. Эвристики Нильсена покрывают значительную часть UX-проблем: соответствие реальному миру (эвристика 2) — это про ожидания. Свобода и контроль (эвристика 3) — про чувство уверенности. Понятные сообщения об ошибках (эвристика 9) — про снижение тревожности. Однако эвристики не оценивают эмоциональный дизайн, бренд-восприятие, эстетическое удовольствие — то, что Дон Норман называет «висцеральным уровнем» взаимодействия.
HCD (человекоориентированное проектирование) по стандарту ISO 9241-210 описывает итеративный процесс: понимание контекста — определение требований — создание решений — оценка. Эвристическая оценка — инструмент фазы оценки. Она позволяет быстро проверить дизайн-решения на соответствие базовым принципам, не дожидаясь разработки и тестирования с пользователями. В цикле HCD эвристическая оценка занимает место между прототипированием и юзабилити-тестированием: прототип готов, но привлекать пользователей ещё рано или слишком дорого.
Закон Якоба — научное обоснование эвристики 4 (единообразие и стандарты). Пользователи формируют ожидания на основе опыта с другими сайтами и приложениями. Нарушение этих ожиданий — это нарушение и закона Якоба, и четвёртой эвристики одновременно.
Закон Миллера — научное обоснование эвристики 6 (узнавание, а не припоминание). Рабочая память ограничена 7 плюс-минус 2 элементами. Интерфейс, который требует запоминать код товара или номер страницы, нарушает и закон Миллера, и шестую эвристику.
Закон Хика — научное обоснование эвристики 8 (эстетичный и минималистичный дизайн). Каждый лишний элемент на экране увеличивает n в формуле Хика и замедляет принятие решения. Минималистичный дизайн — это дизайн с оптимальным n.
Как эвристики Нильсена используются в проектах UsabilityLab
Эвристики Нильсена — основной фреймворк, который мы в UsabilityLab применяем при проведении UX-аудита. За 1800+ проектов с 2006 года мы убедились: несмотря на появление новых устройств, платформ и паттернов взаимодействия, 10 эвристик остаются точным диагностическим инструментом.
UX-аудит как экспертная оценка. Когда клиент обращается за аудитом интерфейса, наши эксперты проходят его по всем 10 эвристикам, фиксируя нарушения с оценкой серьёзности. Каждая находка привязана к конкретному экрану и конкретной эвристике — это делает отчёт не субъективным мнением, а структурированной экспертизой. Клиент получает не список «нам не понравилось», а приоритизированные рекомендации с обоснованием: «Нарушена эвристика 5, серьёзность 3 — форма записи не предотвращает выбор прошедшей даты».
UX Inspector. Наш инструмент UX Inspector систематизирует нарушения эвристик. Каждая проблема категоризируется по номеру эвристики, оценивается по серьёзности и привязывается к элементу интерфейса. Это позволяет отслеживать прогресс: после внедрения рекомендаций повторный аудит показывает, сколько нарушений устранено и какие остались.
Медицинские сайты: какие эвристики наиболее критичны. В проектах для GMS Clinic, СМ-Клиники, ЕМС и Бест Клиник мы обнаружили характерный паттерн. На медицинских сайтах чаще всего нарушаются три эвристики:
- Эвристика 2 (соответствие реальному миру) — медицинская терминология, непонятная пациенту. Названия специальностей, услуг, процедур написаны для врачей, а не для людей, которые ищут помощь. Пациент не знает, к какому специалисту обратиться с болью в спине — к неврологу или ортопеду.
- Эвристика 5 (предотвращение ошибок) — формы записи, которые не валидируют данные на лету: можно записаться на прошедшую дату, выбрать время, когда врач не принимает, или указать некорректный номер полиса.
- Эвристика 1 (видимость статуса) — отсутствие подтверждения записи, неясный статус результатов анализов, непонятно, отправлено ли обращение в клинику.
Сочетание с юзабилити-тестированием. Эвристическая оценка — первый этап, юзабилити-тестирование — второй. Аудит снимает очевидные проблемы: кнопки без обратной связи, непонятные сообщения об ошибках, нарушения единообразия. Тестирование с пользователями выявляет более глубокие вещи: неверные ментальные модели, проблемы с терминологией, неочевидные сценарии. В комбинации два метода дают полную картину — быстрее и дешевле, чем каждый по отдельности.