Юзабилити аудит сайта: проверка пути до заявки, а не красоты интерфейса
Юзабилити аудит сайта проверяет, насколько просто посетителю дойти до целевого действия: заявки, звонка или заказа. Проверку удобно разделить на восемь блоков: первый экран, навигация, мобильная версия, скорость, формы, доверие, читаемость и обработка ошибок, а каждую находку привязать к цели в Яндекс Метрике. Результат такой проверки не оценка «удобно или нет», а список правок, отсортированный по близости к заявке. Отдельный юзабилити-аудит мы как услугу не оказываем: эта статья чек-лист для самостоятельной проверки, а вместе с ним разберём, как юзабилити связано с конверсией и где аудит бессилен.
Юзабилити аудит сайта проверяет путь до заявки, а не красоту интерфейса
Юзабилити аудит сайта отвечает на один вопрос: может ли посетитель без подсказок сделать то, ради чего вы сайт запускали, то есть оставить заявку, позвонить или оформить заказ. Это проверка по задачам, а не по вкусу. Дизайнер скажет «современно», владелец скажет «мне нравится», а аудит юзабилити сайта фиксирует только то, что посетитель споткнулся: не нашёл цену, не понял, что нажимать, не смог отправить форму с телефона.
Термины часто смешивают. UX-аудит шире: он включает впечатление, эмоции, весь опыт взаимодействия с брендом. Юзабилити, или usability, уже и практичнее: насколько эффективно, без ошибок и с каким удовлетворением человек выполняет конкретную задачу. В B2B важно именно оно, потому что у сайта обычно одна-две целевые задачи, и каждую можно измерить.
От остальных проверок юзабилити-аудит отличается предметом. Проверка сайта на ошибки ищет технические сбои: коды ответов, дубли, битые ссылки. SEO-аудит смотрит, почему страницы не ранжируются. Юзабилити-аудит начинается там, где посетитель уже пришёл, и спрашивает, что с ним происходит дальше. Если вам нужна общая рамка, как устроены все эти проверки вместе, её разбирает статья «Структура SEO-аудита».
Заявку приносит путь, а не страница: разрыв обещания
При проверке сразу стоит нарисовать путь посетителя целиком: источник, первый экран, поиск нужного, доверие, форма, подтверждение. Заявка нередко теряется не на «плохой странице», а на конкретном шаге этой цепочки, и у шагов бывают разные причины. Поэтому чек-лист ниже устроен по шагам пути, а не по разделам сайта.
Один из типов потерь называют разрывом обещания. Это расстояние между тем, что человеку пообещал источник (строка в выдаче, объявление, ответ нейросети, ссылка в письме), и тем, что он видит на первом экране. В выдаче написано «стоматология без боли, имплантация под ключ», а на экране слайдер с общими словами про заботу и кнопка «Узнать больше». Многие в такой ситуации просто возвращаются назад, не жалуясь. В статистике это выглядит как обычный отказ, и без разбора путей причину не различить.
Разрыв обещания легко проверить руками: вбейте в поиск запрос, по которому страница получает трафик, откройте её с телефона и ответьте за пять секунд, подтверждено ли то, что вы только что прочитали в сниппете. Если нет, правьте первый экран прежде, чем трогать цвет кнопок.
Чек-лист юзабилити: 8 блоков проверки
Опорой для чек-листа служат десять эвристик юзабилити Якоба Нильсена из исследовательской компании Nielsen Norman Group (статья датирована 1994 годом, текст обновлён в 2020 году): видимость состояния системы, соответствие реальному миру, свобода и контроль пользователя, последовательность и стандарты, предупреждение ошибок и другие. Эвристики не привязаны к отрасли, поэтому их стоит перевести на язык сайта с заявкой. Ниже восемь блоков: что именно спрашивать, как проверить и где у B2B-сайтов ломается нередко. Это практические ориентиры, а не статистика по рынку.
| Блок | Вопрос проверки | Как проверить | Где чаще всего ломается |
|---|---|---|---|
| 1. Первый экран | Понятно ли за пять секунд, что это, для кого и что делать дальше | Показать экран постороннему человеку на пять секунд и спросить, что он запомнил | Абстрактное обещание вместо предложения, нет видимого следующего шага |
| 2. Навигация | Находит ли человек нужную услугу и цену, не гадая, где искать | Дать задачу: «найдите стоимость X и условия доставки» и засечь путь | Меню по внутренней логике компании, а не по задачам клиента |
| 3. Мобильная версия | Можно ли с телефона позвонить, прочитать и отправить заявку одной рукой | Пройти путь до заявки на реальном телефоне, не в эмуляторе браузера | Мелкие и тесно стоящие кнопки, телефон не нажимается, фиксированная панель закрывает контент |
| 4. Скорость и стабильность | Не прыгает ли страница под пальцем и не ждёт ли человек главного блока | Search Console и PageSpeed Insights, затем тот же путь на медленной сети | Тяжёлое изображение на первом экране, сдвиг вёрстки при подгрузке баннеров и виджетов |
| 5. Формы и заявка | Сколько полей, понятны ли ошибки, видно ли, что заявка ушла | Заполнить форму самому с ошибкой, потом правильно, и посмотреть, что произошло | Обязательные поля, которые клиент не хочет отдавать, сообщение об ошибке без объяснения, капча, молчаливая отправка |
| 6. Доверие и содержание | Цена или вилка, сроки, реквизиты, примеры работ, гарантии и условия проверяются в статье про коммерческий аудит сайта по правилу пяти ответов. В юзабилити-аудите достаточно убедиться, что эти сведения находятся без поиска по меню: типичная поломка этого блока — контакты только в подвале. | ||
| 7. Читаемость | Читается ли текст в плохом свете и без напряжения | Проверить контраст и размер шрифта, открыть страницу на экране смартфона на улице | Светло-серый текст на белом, длинные простыни без подзаголовков |
| 8. Ошибки и состояния | Что видит человек, когда что-то пошло не так или он сделал лишнее | Открыть несуществующий адрес, отправить пустую форму, закрыть и снова открыть окно | Баннер cookies перекрывает кнопку, всплывающее окно не закрывается, страница 404 без пути назад |
Конкретные пороги, на которые стоит опираться
Часть пунктов чек-листа можно сверить с документами, а не со вкусом. По документации Google на web.dev, страница проходит оценку «хорошо» по Core Web Vitals при LCP не больше 2,5 секунды, INP не больше 200 миллисекунд и CLS не больше 0,1 для 75-го процентиля загрузок страницы (отдельно для мобильных и десктопных устройств) (описание метрик). Подробнее, чем измерять и как читать результат, мы разбирали в статье «Проверить сайт на скорость».
Для мобильной версии и читаемости есть стандарт WCAG 2.2 (спецификация W3C): уровень AA требует контраста обычного текста с фоном не ниже 4,5 к 1 и интерактивных элементов размером не меньше 24 на 24 CSS-пикселя либо с достаточными отступами. Это не гарантия конверсии, но разумный минимум: если в кнопку трудно попасть пальцем, заявка может потеряться раньше, чем человек прочитает формулировку.
Находка без метрики остаётся мнением: как связать юзабилити и конверсию
Самая слабая часть большинства отчётов в том, что находка висит в воздухе: «кнопка плохо заметна». Заказчик справедливо спрашивает, сколько заявок это стоит. Точного ответа до правки у нас нет и быть не может, но связь между юзабилити и конверсией можно показать, если у каждой находки есть измеримый признак. Нужны три вещи: цель в Яндекс Метрике до начала работ, срез по устройству и источнику, запись реальных визитов для подтверждения.
Что для этого нужно настроить. Цели на каждый шаг пути: клик по телефону, начало заполнения формы, отправка формы, а не только «заявка получена». Отчёты Метрики: страницы входа, карта кликов и скроллинга, аналитика форм (справка Метрики: аналитика форм) и Вебвизор для просмотра записей визитов (справка Метрики: Вебвизор). Поля форм с личными данными можно закрыть от записи, как описано в справке Метрики (класс ym-disable-keys). Срез по устройству обязателен: если на десктопе заявок заметно больше, чем на мобильном при сопоставимом трафике, смотреть надо в первую очередь мобильную версию.
| Находка при проверке | Что измерять | Где смотреть | Что считать подтверждением |
|---|---|---|---|
| Первый экран не подтверждает запрос (разрыв обещания) | Доля визитов, дошедших до второго шага, по страницам входа и источникам | Метрика: страницы входа с сегментом по источнику | Страница, на которую идёт целевой запрос, уступает остальным по прохождению дальше при сопоставимом трафике |
| Телефон и кнопка трудно нажимаются на смартфоне | Клики по телефону и отправки формы по типам устройств | Цель «клик по номеру», сегмент «мобильные» | Разрыв между устройствами и записи, где человек несколько раз промахивается |
| Форма длинная или ошибки непонятны | Начали заполнять против отправили, поля, на которых уходят | Метрика: аналитика форм | Много начавших и мало отправивших, заметная доля уходов с одного и того же поля |
| Нет цены, сроков или реквизитов | Возвраты на страницу цен, уход с карточки услуги, вопросы менеджеру | Карта кликов, журнал вопросов отдела продаж | Повторяющийся вопрос в звонках, ответ на который на сайте есть, но его не найти |
| Баннер или окно перекрывает действие | Выход после появления элемента | Вебвизор, записи визитов | Несколько записей, где человек пытается закрыть элемент и уходит |
| Страница тяжёлая или двигается | LCP, INP, CLS по реальным пользователям | Search Console, PageSpeed Insights | Метрики вне порога на страницах, куда идёт основной трафик |
Одно предупреждение: корреляция из Метрики не доказательство причины. Если конверсия страницы выросла после правки, это ещё не значит, что правка сработала, поскольку в те же недели мог измениться трафик, сезон или реклама. Общий принцип работы с такими цифрами мы описывали в материале «Метрики сайта и статистика: 7 цифр для владельца бизнеса».