Константин ВасинБлог
Свой сайт

Юзабилити-аудит сайта: что проверять и почему это не про вкус

Я собираю сайты сам и для заказчиков, и на каждом рано или поздно наступает момент «вроде всё работает, но почему-то не конвертит». Обычно это значит, что сайт никто не проверял по сценариям — только смотрели, красиво ли. Расскажу, как я на самом деле провожу юзабилити-аудит: что мерю, где нахожу расхождения данных с реальностью и почему свежий взгляд находит то, что автор проекта пропускает.

Коротко
  • Юзабилити-аудит — это проверка по сценариям и метрикам, а не оценка «нравится/не нравится». У него есть измеримый результат: список конкретных мест, где пользователь теряется или уходит.
  • Свежий взгляд находит то, что не видит автор проекта. Я гоняю параллельный аудит нескольких проектов через нейросеть и нахожу ошибки, которые раньше пропускал при обычной проверке.
  • Аудит — это не только интерфейс, но и данные на сайте. У меня был случай, когда прайс на сайте разошёлся с официальным документом на 2000–8000 ₽ по позициям — это тоже юзабилити-проблема: пользователь видит неверную цену.
  • Технические метрики считаются, а не ощущаются. TTFB, число редиректов, путь пользователя до целевого действия — конкретные числа, а не «сайт вроде быстрый».
  • Аудит без повторной проверки после правок — не аудит, а список пожеланий. Изменения нужно измерить до и после, иначе непонятно, что реально сработало.
Содержание статьи
  1. Аудит — это сценарии, а не впечатление
  2. Свежий взгляд находит то, что автор не видит
  3. Аудит данных, а не только интерфейса
  4. Где заканчивается интерфейс и начинается оффер
  5. Технические метрики считаются, а не ощущаются
  6. Где аудит превращается в список пожеланий, а не в план работ
  7. Повторная проверка — обязательная часть, а не бонус
  8. Кто должен проводить аудит

Юзабилити-аудит на словах звучит как «посмотреть на сайт и сказать, что не нравится». На практике это ровно то, из-за чего аудиты чаще всего бесполезны: субъективное мнение одного человека, оформленное как экспертиза. Я собираю сайты сам — свои и заказные — и давно перестал доверять аудиту без цифр. Расскажу, как я на самом деле его провожу.

Аудит — это сценарии, а не впечатление

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

На каждый сценарий считается два числа: сколько кликов нужно, чтобы дойти до цели, и на каком шаге человек реально останавливается. Второе выясняется либо из аналитики (карта скролла, вебвизор, воронка), либо честным прогоном сценария самому с чистой историей браузера — без привычного знания, где что лежит.

Порядок, по которому я реально провожу аудит

  1. Фиксирую 3–5 сценариев, которые совпадают с реальными целями посетителей (не «посмотреть на дизайн», а «понять цену и оставить заявку»).
  2. Прохожу каждый сценарий сам, с чистой историей браузера, фиксируя каждую заминку и лишний клик.
  3. Сверяю данные на странице (цены, условия, сроки) с официальным источником, а не с тем, что уже написано на сайте.
  4. Замеряю технические метрики: скорость загрузки, путь до формы в кликах, поведение на мобильном.
  5. Прогоняю параллельный аудит через нейросеть на нескольких проектах сразу — она находит формальные нестыковки быстрее и без усталости.
  6. Свожу находки в список с приоритетом: что ломает сценарий полностью, что просто раздражает.
Дальше по теме

Как я на самом деле провожу аудит своих и заказных сайтов

В канале показываю разборы конкретных сайтов — что находил, что чинил и что это давало в цифрах.

Свежий взгляд находит то, что автор не видит

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

Из моей практики

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

Дело не в том, что нейросеть «умнее» человека в оценке дизайна — она просто не устаёт и не привыкает. Она честно проходит сценарий заново каждый раз, без предположений «а, это же тут, я помню».

Аудит данных, а не только интерфейса

Юзабилити-аудит часто сводят к интерфейсу: кнопки, форма, навигация. Но пользователь теряет доверие не только из-за неудобной кнопки — он теряет доверие, когда видит на сайте неверную информацию. И это тоже находится аудитом, только другого типа.

Грабли

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

Это относится не только к прайсам: условия доставки, сроки, контакты — всё, что меняется в бизнесе быстрее, чем правится сайт, нужно сверять с первоисточником при каждом аудите, а не доверять тому, что уже написано.

Где заканчивается интерфейс и начинается оффер

Отдельная ловушка юзабилити-аудита — списывать на интерфейс то, что на самом деле проблема оффера или контента. Кнопка «Оставить заявку» может быть идеально видна, форма — работать без сбоев, а заявок всё равно нет, потому что за кнопкой стоит невыгодное предложение или пользователь не понял, что именно он получит.

У меня был случай, когда на одном из проектов подняли минимальный заказ до 100 000 ₽ — сама форма и кнопка не менялись ни на пиксель, но конверсия обвалилась в шесть раз: с 2,2% (496 визитов, 11 целей) до 0,39% (776 визитов, 3 цели). Формально это выглядело как «сломанный сайт», а по факту сломался не интерфейс, а условие сделки. Хороший юзабилити-аудит обязан разделять эти два типа проблем — иначе чинят не то, и цифры не двигаются.

Поэтому в чек-лист аудита я всегда включаю отдельный вопрос: если конверсия просела, менялся ли за последнее время сам оффер, цена или условие — до того, как искать проблему в вёрстке.

Технические метрики считаются, а не ощущаются

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

622 → 92 мсTTFB до и после технического редизайна одного из заказных сайтов
2,28% → 4,26%конверсия в заявку по той же паре замеров
138страниц в структуре после переезда сайта на новую платформу
594редиректа настроено, позиции в поиске не потеряны

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

Отдельно у меня есть статья про то, что конкретно убивает скорость загрузки и как её проверить по-честному — если у вас сайт «вроде не тормозит», но заявок мало, начните оттуда: читайте про скорость загрузки сайта.

Где аудит превращается в список пожеланий, а не в план работ

Частая ошибка — сдать заказчику список из тридцати пунктов без приоритета: «поправить текст кнопки» стоит рядом с «форма не отправляется на мобильном». Это разные по цене ошибки, и аудит без ранжирования просто перекладывает работу по приоритезации на того, кто и так не эксперт в этом.

Что должно быть в результате аудита, а не только в процессе

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

Если аудит делает подрядчик, а не вы сами, — тем более важно требовать числа до/после и конкретный список сценариев, а не общий отчёт на десять страниц с прилагательными. Больше про то, как принимать такую работу и не платить дважды, — в статье про работу с подрядчиками.

Повторная проверка — обязательная часть, а не бонус

Аудит без повторного замера после правок — это не аудит, а гипотеза. Я всегда фиксирую числа «до» именно для того, чтобы через месяц-два свериться: то, что казалось очевидным улучшением, иногда не даёт вообще ничего, а иногда даёт больше, чем ожидалось, — и тогда понятно, что чинить в первую очередь на следующем проекте.

Кто должен проводить аудит

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

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

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

Что забрать из статьи
  1. Прежде чем звать кого-то на аудит, зафиксируйте 3–5 ключевых сценариев пользователя (найти цену, оставить заявку, найти контакты) — аудит без сценариев превращается в список случайных придирок.
  2. Проверяйте не только интерфейс, но и данные: цены, контакты, условия — сверяйте с официальным источником, а не с тем, что уже стоит на сайте.
  3. Замеряйте технические метрики до правок и после — без цифр «стало лучше» нельзя проверить.
  4. Зовите на аудит человека или инструмент со свежим взглядом — автор проекта слепнет к собственным решениям через пару недель работы.
  5. Не считайте аудит законченным после одного прохода — на сложном сайте по-настоящему полезные находки появляются на втором-третьем сценарии, когда вы уже понимаете логику страницы.
Забрать материал

Гайд «SEO-машина»: как собрать её на ИИ-агентах

Карта из десяти систем: что делает каждая и как собрать такую же — с любым ИИ-агентом, Claude Code или Codex. Бесплатно, отдаёт бот в Telegram.

Частые вопросы

Что такое юзабилити-аудит сайта?

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

Чем юзабилити-аудит отличается от технического аудита сайта?

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

Как провести юзабилити-аудит сайта самостоятельно?

Составьте 3–5 сценариев, которые реально выполняет ваш посетитель, и пройдите их сами с чистой историей браузера, засекая, где возникает заминка. Отдельно сверьте данные на сайте (цены, условия, контакты) с официальным источником. Замерьте технические метрики — скорость загрузки, путь до формы в кликах, работоспособность формы на мобильном.

Сколько стоит юзабилити-аудит сайта?

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

Как часто нужно проводить юзабилити-аудит?

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

Может ли нейросеть провести юзабилити-аудит сайта?

Нейросеть или headless-браузер с прогоном по сценариям хорошо ловит формальные вещи: битые ссылки, расхождения текста, медленные страницы, нелогичную структуру. Финальную оценку «понятно ли это живому человеку» я всё равно проверяю сам — здесь автоматика ускоряет процесс, но не заменяет его целиком.

Константин Васин
Предприниматель, маркетолог

10 лет в маркетинге и онлайн-образовании. Запускаю проекты в одиночку на Claude Code и показываю экономику как есть. Все методы из блога сначала обкатываю на своих проектах и только потом описываю.