Публикация
Обновление 5 ноября 2026
Юзабилити сайта — это то, насколько легко конкретные пользователи достигают конкретных целей в определённых условиях: находят цену услуги, оформляют заказ с телефона, отправляют заявку без ошибок. Так юзабилити определяет стандарт ISO 9241-11:2018, и именно эту логику стоит использовать в 2026 году при оценке любого сайта. Удобство измеряется успешностью выполнения задач, временем, количеством ошибок и субъективной оценкой пользователей, а не личным вкусом владельца и не красотой дизайна. Ниже разобрано, как отличить юзабилити от смежных понятий, какие метрики и методы работают, как провести минимальный тест и как расставить приоритеты правок.
Ключевые выводы
- Юзабилити всегда определяется для конкретной аудитории, задачи и контекста: «удобно вообще» не существует.
- Проверять удобство можно без больших бюджетов: данные Яндекс Метрики и Вебвизора дают гипотезы, а короткий тест на реальных задачах подтверждает или опровергает их.
- Показатели Core Web Vitals описывают скорость и стабильность страницы, но не заменяют юзабилити-тестирование.
- Связь юзабилити с позициями в поиске нельзя подавать как гарантированную: надёжнее говорить о влиянии на поведение пользователей и конверсию, которое нужно проверять на своих данных.
- Правки стоит приоритизировать по трём критериям: влияние на задачу пользователя, частота проблемы и стоимость исправления.
Что такое юзабилити сайта по ISO 9241-11 и Нильсену
Стандарт ISO 9241-11:2018 описывает юзабилити как степень, в которой определённые пользователи достигают определённых целей с результативностью, эффективностью и удовлетворённостью в определённом контексте использования. Редакция 2018 года расширила охват на системы и услуги, поэтому определение применимо не только к программам, но и к сайтам, формам и сервисам. Юзабилити не бывает абстрактным: оно определяется только для конкретных пользователей, задач и условий использования.
В русскоязычных источниках термины переводят по-разному, и это путает читателей. В этой статье принято такое соответствие: effectiveness — «результативность» (точность и полнота достижения цели), efficiency — «эффективность» (затраты ресурсов относительно результата), satisfaction — «удовлетворённость». Если в другом материале встречаются слова «продуктивность» или «эффективность» в другом значении, стоит сверяться с английским оригиналом.
Вторая распространённая модель — пять компонентов юзабилити по Якобу Нильсену (Nielsen Norman Group): обучаемость (learnability), эффективность (efficiency), запоминаемость (memorability), ошибки (errors) и удовлетворённость (satisfaction). Она удобнее ISO, когда нужно разобрать конкретный интерфейс: можно спросить, насколько быстро новичок осваивает сайт, легко ли вернувшийся пользователь вспоминает путь и как часто люди ошибаются.
| Модель | Что оценивает | Когда полезна |
|---|---|---|
| ISO 9241-11:2018 | Результативность, эффективность, удовлетворённость в заданном контексте | Постановка целей и выбор метрик для проекта |
| Пять компонентов Нильсена | Обучаемость, эффективность, запоминаемость, ошибки, удовлетворённость | Разбор конкретных экранов и сценариев |
| 10 эвристик Нильсена | Соответствие интерфейса набору общепризнанных принципов | Быстрый экспертный аудит перед тестом |
Десять эвристик Нильсена считаются самым используемым фреймворком для оценки юзабилити. Полный перечень стоит брать на сайте nngroup.com, а не из пересказов, поскольку формулировки в них часто искажаются. Практический вывод: ISO помогает определить, что именно считать успехом, а эвристики и тестирование показывают, где пользователи теряют этот успех.
Юзабилити, UX, UI и доступность: в чём разница
Юзабилити — часть пользовательского опыта (UX), но не весь UX: опыт включает ещё эмоции, доверие к бренду и ожидания, а юзабилити отвечает на вопрос, насколько легко выполнить задачу. UI — это визуальный и интерактивный слой интерфейса, доступность (accessibility) — возможность пользоваться сайтом людям с разными ограничениями. Путаница в терминах ведёт к неверным заданиям подрядчикам, поэтому полезно развести понятия.
| Понятие | О чём оно | Как проверяют | Типичная ошибка трактовки |
|---|---|---|---|
| Юзабилити | Лёгкость достижения цели конкретным пользователем | Тесты задач, метрики успеха, SUS | Считать его «красивым дизайном» |
| UX | Весь опыт взаимодействия с продуктом и брендом | Исследования, интервью, CJM, аналитика | Приравнивать UX к юзабилити |
| UI | Внешний вид и элементы интерфейса | Дизайн-ревью, UI-кит, проверка состояний | Считать, что хороший UI гарантирует удобство |
| Доступность | Возможность использования людьми с разными ограничениями | Проверка по WCAG 2.2, ручные тесты | Рассматривать как опцию «для меньшинства» |
| Скорость страницы | Время загрузки, отклик, визуальная стабильность | Core Web Vitals, PageSpeed Insights | Подменять ею всю оценку удобства |
Отдельно стоит отличать utility (полезность функций) от usability: сайт может быть предельно понятным, но предлагать не то, что нужно аудитории. Тогда улучшение навигации не поможет, и придётся пересматривать предложение. Доступность при этом пересекается с юзабилити: крупные цели нажатия и понятные ошибки в формах помогают всем пользователям, а не только людям с ограничениями.
Как юзабилити влияет на бизнес и SEO: что доказано, а что нет
Юзабилити влияет на бизнес через конверсию: если пользователь не может найти кнопку, не понимает условия или сталкивается с ошибкой формы, он не совершает целевое действие. Величину эффекта нельзя взять из общих «исследований», она зависит от ниши, трафика и масштаба проблем, поэтому проверять её нужно на данных собственного проекта.
| Утверждение | Статус | Как проверить |
|---|---|---|
| Понятные формы и навигация повышают долю выполненных задач | Логичное следствие определения ISO, величину эффекта нужно измерять | Тест задач до и после правок, цели в Метрике |
| Юзабилити напрямую повышает позиции в Яндексе и Google | Прямого доказательства в найденных источниках нет | Не обещать, отслеживать динамику позиций отдельно от конверсии |
| Core Web Vitals — решающий фактор ранжирования | Категоричные формулировки встречаются во вторичных источниках, их нужно сверять с Google Search Central | Не писать «решающий фактор», использовать метрики как показатель опыта |
| Накрутка поведенческих факторов заменяет улучшение сайта | Не заменяет: она не устраняет причины проблем | Работать с причинами через аудит и тесты |
Поведенческие факторы — это данные о том, как пользователи взаимодействуют с сайтом: глубина, время, возвраты, отказы. Они полезны как сигнал: резкий рост отказов на конкретной странице может свидетельствовать о проблеме с юзабилити, но сам по себе показатель не объясняет причину. Накручивать поведенческие факторы бессмысленно и рискованно, а улучшать сценарии пользователей — разумно независимо от того, как поисковые системы учитывают эти данные.
Метрики юзабилити: что измерять и где брать данные
Метрики юзабилити делятся на три группы: показатели результативности и эффективности по ISO, субъективные оценки и бизнес-показатели. Ни одна цифра не имеет смысла без привязки к задаче: «время на сайте» можно трактовать и как интерес, и как растерянность. Поэтому каждую метрику нужно связывать с конкретным сценарием.
| Метрика | Что показывает | Где взять | Ограничение |
|---|---|---|---|
| Доля успешно выполнивших задачу | Результативность сценария | Юзабилити-тест, цели в Метрике | В тесте — малая выборка, в аналитике — нет причины неудачи |
| Время выполнения задачи | Эффективность | Тест, события в Метрике | Нужно сравнивать с эталоном для той же задачи |
| Частота ошибок и жалоб | Места, где пользователи теряются | Тест, формы в Метрике, обращения в поддержку | Не все пользователи сообщают о проблемах |
| SUS (System Usability Scale) | Субъективная оценка удобства по 10 вопросам, шкала 0–100 | Опрос после теста | Показывает уровень, но не указывает на причину |
| Конверсия, брошенные формы и корзины | Бизнес-результат сценария | Метрика, CRM | Зависит от трафика, сезона и предложения |
| Отказы, глубина, время визита | Косвенные поведенческие сигналы | Метрика | Допускают разные трактовки |
SUS — стандартная анкета из десяти вопросов с итоговой оценкой от 0 до 100. Её удобно запускать сразу после юзабилити-теста и сравнивать результаты до и после редизайна. Интерпретировать балл нужно через сравнение с собственными предыдущими замерами и с опубликованными бенчмарками MeasuringU, перед использованием которых актуальные значения нужно уточнить в первоисточнике.
Яндекс Метрика даёт три полезных инструмента: Вебвизор (записи сессий), карты кликов и скроллинга, а также аналитику форм. Названия отчётов в интерфейсе меняются, поэтому перед внедрением их стоит сверить со справкой сервиса. Эти данные хорошо показывают, где происходит проблема, но почему она возникает, чаще всего выясняется только в разговоре с пользователем или в тесте.
Как провести минимальный юзабилити-тест
Минимальный юзабилити-тест — это наблюдение за тем, как несколько представителей целевой аудитории выполняют типовые задачи на сайте. Он не требует лаборатории и дорогого оборудования, но требует дисциплины в подготовке. Рекомендация Nielsen Norman Group — тестировать рано и повторно: старую версию, затем прототипы, затем финальный вариант.
- Выберите сценарий и аудиторию.Возьмите один важный путь, например «найти услугу и оставить заявку». Результат шага — понятное описание того, кто и зачем приходит на сайт.
- Сформулируйте задачи.Каждая задача описывает цель пользователя, а не путь по меню. Результат — три-пять коротких заданий.
- Определите критерии успеха.Для каждой задачи заранее решите, что считать выполнением, и какое время приемлемо. Результат — таблица для фиксации итогов.
- Проведите сессии.Участник вслух комментирует действия, а модератор не подсказывает. Результат — записи и заметки о затруднениях.
- Зафиксируйте проблемы.Отмечайте место, действие, ожидание пользователя и последствия. Результат — список наблюдений с доказательствами.
- Приоритизируйте и исправьте.Оцените влияние, частоту и стоимость. Результат — короткий список правок.
- Повторите измерение.Запустите тот же сценарий после изменений и сравните результативность, время и SUS. Результат — подтверждённый или опровергнутый эффект.
Минимальный тест сильнее всего зависит от качества задач: формулировка должна описывать цель пользователя, а не подсказывать путь по интерфейсу. Например, «узнайте, сколько стоит доставка в ваш город» лучше, чем «откройте раздел „Доставка“». Универсального числа участников и срока ожидания эффекта в найденных материалах нет, поэтому размер выборки нужно выбирать по задаче и бюджету, а выводы формулировать осторожно.
Что чаще всего ломает удобство: диагностика по симптомам
Диагностику удобно строить по цепочке «симптом — вероятная причина — способ проверки — решение». Так команда не бросается переделывать дизайн, а сначала находит конкретное место потерь. Ниже собраны типовые случаи для сайтов услуг и интернет-магазинов; это рабочие гипотезы, а не гарантированные причины.
| Симптом | Вероятная причина | Как проверить | Что исправлять |
|---|---|---|---|
| Высокие отказы на главной или посадочной | Непонятное предложение на первом экране, несоответствие ожиданиям из рекламы или поиска | Вебвизор, карты кликов, тест «пяти секунд» с пользователями | Заголовок, оффер, ключевое действие в первом экране |
| Пользователи не доходят до каталога или услуги | Перегруженная или нелогичная навигация | Задача «найдите X» в тесте, пути в Метрике | Структуру меню, названия разделов, поиск |
| Брошенные формы | Лишние поля, непонятные ошибки, отсутствие подсказок | Аналитика форм в Метрике, запись сессий | Количество полей, сообщения об ошибках, маски ввода |
| Падение конверсии на мобильных | Мелкие элементы, перекрытие контента, медленная загрузка | Проверка на реальных устройствах, Core Web Vitals по мобильным данным | Размер целей нажатия, фиксированные блоки, вес страницы |
| Потеря на чекауте | Неожиданные расходы, принудительная регистрация, сложная оплата | Воронка в Метрике, тест оформления заказа | Прозрачность стоимости, гостевой заказ, способы оплаты |
| Мало обращений при хорошем трафике | Контакты трудно найти, недостаточно признаков доверия | Карта кликов, тест задачи «свяжитесь с компанией» | Заметные контакты, отзывы, реквизиты, условия |
Главное правило диагностики: сначала определите, где в воронке находится просадка, затем сформулируйте гипотезу и только потом выбирайте метод проверки. Количественные данные показывают место проблемы, качественные — причину. Если проверить гипотезу нечем, её нужно отложить, а не внедрять «на всякий случай».
Скорость и стабильность: пороги Core Web Vitals
Core Web Vitals — набор метрик Google, который описывает скорость загрузки основного контента, отклик на действия и визуальную стабильность страницы. Они относятся к юзабилити частично: медленная или «прыгающая» страница мешает выполнять задачи, но хорошие показатели сами по себе не делают сайт понятным. Перед настройкой стоит определить, какие именно значения считаются целевыми.
| Метрика | Что измеряет | «Хорошо» | «Плохо» |
|---|---|---|---|
| LCP | Время появления основного контента | до 2,5 с | свыше 4 с |
| INP | Отклик страницы на действия пользователя | до 200 мс | свыше 500 мс |
| CLS | Неожиданные сдвиги макета | до 0,1 | свыше 0,25 |
Страница считается прошедшей оценку, если все три метрики достигают целевых значений на 75-м перцентиле пользовательских данных. Это означает, что нужный результат должен получать не средний, а подавляющее большинство пользователей, включая тех, у кого слабые устройства и медленное соединение. INP заменил метрику FID как один из Core Web Vitals 12 марта 2024 года, поэтому материалы, в которых упоминается FID, устарели.
Для проверки используют PageSpeed Insights, где показаны полевые данные, Google Search Console и Яндекс Вебмастер. Вопрос о том, является ли Core Web Vitals ранжирующим сигналом, нужно сверять с формулировками Google Search Central и не называть эти метрики «решающим фактором». Практичнее смотреть на них как на условия нормальной работы страницы и устранять проблемы, которые влияют на самые важные сценарии.
Доступность по WCAG 2.2: минимальный чек-лист
WCAG 2.2 — рекомендация W3C, опубликованная 5 октября 2023 года, в которой добавлено 9 критериев и удалён критерий 4.1.1 Parsing. Для юзабилити она полезна как набор проверяемых требований: многие из них повышают удобство для всех пользователей. Российские требования к доступности, включая ГОСТ Р 52872-2019, нужно проверять в первоисточниках отдельно, поскольку в этой статье они не разбираются.
- Размер целей нажатия.Критерий 2.5.8 Target Size (Minimum) уровня AA требует минимум 24×24 CSS-пикселя, с исключениями. Более строгий критерий уровня AAA в WCAG 2.1 предлагает 44×44.
- Понятные ошибки в формах.Сообщение должно называть поле и способ исправления, а не только подсвечивать его цветом.
- Работа с клавиатуры.Основные действия — меню, форму, оформление заказа — нужно уметь выполнить без мыши.
- Контрастность и масштабирование.Текст должен оставаться читаемым при увеличении, а интерактивные элементы — различимыми.
Эти пункты — лишь стартовый минимум, а не полный аудит. Для формальной проверки нужно открыть первоисточники W3C и пройти критерии нужного уровня соответствия, а для повседневной работы достаточно включить доступность в чек-листы дизайна и разработки.
Как расставить приоритеты правок
После аудита и тестов почти всегда накапливается больше проблем, чем можно исправить за один спринт. Приоритизация по трём критериям — влияние, частота, стоимость — помогает начать с изменений, которые заметно улучшают ключевые сценарии при разумных затратах. Оценки можно давать по простой шкале «низкое — среднее — высокое» и пересматривать после каждого этапа.
- Влияние.Насколько проблема мешает выполнению задачи: полностью блокирует, замедляет или лишь раздражает.
- Частота.Какая доля пользователей и сессий сталкивается с проблемой, и на каком устройстве.
- Стоимость.Сколько времени и ресурсов требуется разработчикам, дизайнерам и контент-менеджерам.
В первую очередь стоит исправлять проблемы с высоким влиянием и высокой частотой, особенно если правка недорогая: ошибки в формах, скрытые контакты, неочевидные кнопки. Крупные структурные изменения оправданы, когда повторяются в тестах разных участников. Чтобы не обмануть себя при оценке результата, фиксируйте метрики до изменений, меняйте по возможности один ключевой элемент за раз и учитывайте сезонность и каналы трафика.
При малом трафике A/B-тестирование часто не даёт статистически надёжных выводов, и общего порога в найденных источниках нет. В таких проектах надёжнее сочетать качественные тесты, сравнение периодов «до и после» и осторожные формулировки в отчётах: данные показывают динамику, но не всегда доказывают причину.
Особенности юзабилити интернет-магазина, лендинга и сайта после редизайна
Интернет-магазин оценивается по сквозному сценарию: поиск товара, фильтры, карточка, корзина и чекаут. Здесь важны прозрачная стоимость, понятные условия доставки и возврата, гостевое оформление и ясные сообщения об ошибках. Метрики воронки по шагам показывают место потерь, а запись сессий и тест оформления заказа объясняют причину.
Лендинг и сайт услуг решают более короткую задачу: объяснить предложение и привести к заявке. Первый экран должен ясно отвечать, что предлагается, кому и каким должно быть следующее действие. Контакты, доказательства доверия и понятная форма важнее дополнительных блоков, которые отвлекают от цели.
После редизайна юзабилити нередко ухудшается, поскольку привычные пути пользователей меняются. Поэтому до запуска стоит зафиксировать базовые показатели и провести тест на прототипе, а после запуска — повторить тот же набор задач и сравнить результаты. Так видно, действительно ли новый дизайн улучшил результативность, а не только изменил внешний вид.
Самостоятельный аудит или агентство: как принять решение
Самостоятельный аудит подходит, когда сайт небольшой, сценариев мало, а в команде есть аналитик или маркетолог, умеющий работать с Метрикой. Внешняя экспертиза нужна, если проблемы повторяются после нескольких правок, сайт большой, команда «замылила глаз» или требуется независимая оценка до редизайна. Выбор подрядчика стоит делать по критериям, а не по обещаниям результата.
- Подрядчик объясняет методику: эвристическая оценка, тесты, анализ поведения.
- В отчёте проблемы привязаны к сценариям, данным и доказательствам, а не только к мнению эксперта.
- Рекомендации приоритизированы и имеют критерии проверки эффекта.
- Подрядчик не гарантирует рост позиций или конверсии на конкретную величину.
План действий на ближайшие две недели
Для старта достаточно выбрать один значимый сценарий и пройти его от первого касания до целевого действия. На первой неделе соберите данные Метрики и Вебвизора, проведите быструю эвристическую оценку по Нильсену и проверьте показатели Core Web Vitals на ключевых страницах. На второй неделе проведите минимальный тест, исправьте самые дорогие по влиянию проблемы и запланируйте повторный замер.
Результат такой работы — не абстрактная оценка «удобно или нет», а список подтверждённых проблем, приоритеты и метрики для сравнения. Если после первого цикла удалось улучшить хотя бы один сценарий и измерить эффект, процесс «гипотеза — тест — правка — повторное измерение» можно закрепить как регулярную практику. Так сайт будет улучшаться системно, а не по настроению и модным рекомендациям.
