Юзабилити-аудит сайта: что проверять и почему это не про вкус
Я собираю сайты сам и для заказчиков, и на каждом рано или поздно наступает момент «вроде всё работает, но почему-то не конвертит». Обычно это значит, что сайт никто не проверял по сценариям — только смотрели, красиво ли. Расскажу, как я на самом деле провожу юзабилити-аудит: что мерю, где нахожу расхождения данных с реальностью и почему свежий взгляд находит то, что автор проекта пропускает.
- Юзабилити-аудит — это проверка по сценариям и метрикам, а не оценка «нравится/не нравится». У него есть измеримый результат: список конкретных мест, где пользователь теряется или уходит.
- Свежий взгляд находит то, что не видит автор проекта. Я гоняю параллельный аудит нескольких проектов через нейросеть и нахожу ошибки, которые раньше пропускал при обычной проверке.
- Аудит — это не только интерфейс, но и данные на сайте. У меня был случай, когда прайс на сайте разошёлся с официальным документом на 2000–8000 ₽ по позициям — это тоже юзабилити-проблема: пользователь видит неверную цену.
- Технические метрики считаются, а не ощущаются. TTFB, число редиректов, путь пользователя до целевого действия — конкретные числа, а не «сайт вроде быстрый».
- Аудит без повторной проверки после правок — не аудит, а список пожеланий. Изменения нужно измерить до и после, иначе непонятно, что реально сработало.
Содержание статьи
- Аудит — это сценарии, а не впечатление
- Свежий взгляд находит то, что автор не видит
- Аудит данных, а не только интерфейса
- Где заканчивается интерфейс и начинается оффер
- Технические метрики считаются, а не ощущаются
- Где аудит превращается в список пожеланий, а не в план работ
- Повторная проверка — обязательная часть, а не бонус
- Кто должен проводить аудит
Юзабилити-аудит на словах звучит как «посмотреть на сайт и сказать, что не нравится». На практике это ровно то, из-за чего аудиты чаще всего бесполезны: субъективное мнение одного человека, оформленное как экспертиза. Я собираю сайты сам — свои и заказные — и давно перестал доверять аудиту без цифр. Расскажу, как я на самом деле его провожу.
Аудит — это сценарии, а не впечатление
Первый шаг любого нормального аудита — не открыть сайт и полистать, а выписать конкретные сценарии, которые реально проходит посетитель: найти цену на услугу, понять условия, оставить заявку, найти контакты, вернуться назад после ошибки в форме. Без списка сценариев аудитор смотрит на сайт глазами дизайнера, а не глазами клиента, который пришёл решить свою задачу за три минуты между делами.
На каждый сценарий считается два числа: сколько кликов нужно, чтобы дойти до цели, и на каком шаге человек реально останавливается. Второе выясняется либо из аналитики (карта скролла, вебвизор, воронка), либо честным прогоном сценария самому с чистой историей браузера — без привычного знания, где что лежит.
Порядок, по которому я реально провожу аудит
- Фиксирую 3–5 сценариев, которые совпадают с реальными целями посетителей (не «посмотреть на дизайн», а «понять цену и оставить заявку»).
- Прохожу каждый сценарий сам, с чистой историей браузера, фиксируя каждую заминку и лишний клик.
- Сверяю данные на странице (цены, условия, сроки) с официальным источником, а не с тем, что уже написано на сайте.
- Замеряю технические метрики: скорость загрузки, путь до формы в кликах, поведение на мобильном.
- Прогоняю параллельный аудит через нейросеть на нескольких проектах сразу — она находит формальные нестыковки быстрее и без усталости.
- Свожу находки в список с приоритетом: что ломает сценарий полностью, что просто раздражает.
Как я на самом деле провожу аудит своих и заказных сайтов
В канале показываю разборы конкретных сайтов — что находил, что чинил и что это давало в цифрах.
Свежий взгляд находит то, что автор не видит
Я держу несколько проектов одновременно, и есть закономерность: в четырёх окнах терминала, запустив параллельный аудит нескольких проектов сразу нейросетью, я находил ошибки, которые раньше не замечал при обычной ручной проверке — просто потому, что глаз замыливается на собственном сайте через пару недель работы с ним.
Из моей практики
Параллельный аудит четырёх проектов сразу — токены на такой прогон улетают быстро, «за 20 минут», но результат стоит того: находятся расхождения, которые пропускаешь месяцами, потому что смотришь на привычный интерфейс, а не читаешь его как новый посетитель.
Дело не в том, что нейросеть «умнее» человека в оценке дизайна — она просто не устаёт и не привыкает. Она честно проходит сценарий заново каждый раз, без предположений «а, это же тут, я помню».
Аудит данных, а не только интерфейса
Юзабилити-аудит часто сводят к интерфейсу: кнопки, форма, навигация. Но пользователь теряет доверие не только из-за неудобной кнопки — он теряет доверие, когда видит на сайте неверную информацию. И это тоже находится аудитом, только другого типа.
Грабли
На одном из заказных проектов сверил прайс на сайте клиента (389 позиций) с официальным прейскурантом (364 позиции) — расхождение по отдельным позициям составило 2000–8000 ₽. Сайт транслировал цену, которая уже разошлась с реальностью. Вывод, который я теперь применяю всегда: источник цены — официальный документ клиента, а не то, что уже опубликовано на сайте. Съём цифр «как есть» с живой страницы — это копирование чужой возможной ошибки.
Это относится не только к прайсам: условия доставки, сроки, контакты — всё, что меняется в бизнесе быстрее, чем правится сайт, нужно сверять с первоисточником при каждом аудите, а не доверять тому, что уже написано.
Где заканчивается интерфейс и начинается оффер
Отдельная ловушка юзабилити-аудита — списывать на интерфейс то, что на самом деле проблема оффера или контента. Кнопка «Оставить заявку» может быть идеально видна, форма — работать без сбоев, а заявок всё равно нет, потому что за кнопкой стоит невыгодное предложение или пользователь не понял, что именно он получит.
У меня был случай, когда на одном из проектов подняли минимальный заказ до 100 000 ₽ — сама форма и кнопка не менялись ни на пиксель, но конверсия обвалилась в шесть раз: с 2,2% (496 визитов, 11 целей) до 0,39% (776 визитов, 3 цели). Формально это выглядело как «сломанный сайт», а по факту сломался не интерфейс, а условие сделки. Хороший юзабилити-аудит обязан разделять эти два типа проблем — иначе чинят не то, и цифры не двигаются.
Поэтому в чек-лист аудита я всегда включаю отдельный вопрос: если конверсия просела, менялся ли за последнее время сам оффер, цена или условие — до того, как искать проблему в вёрстке.
Технические метрики считаются, а не ощущаются
«Сайт вроде быстрый» — это не результат аудита, это отсутствие результата. Технические метрики нужно снимать числом: время до первого байта (TTFB), число переходов до целевого действия, поведение формы на мобильном соединении, число редиректов в структуре.
Это конкретный случай редизайна заказного сайта (переезд с одной платформы на другую): при том же трафике конверсия в заявку почти удвоилась. Важная оговорка, которую я всегда держу в голове при разборе таких результатов: это была связка изменений — ускорение TTFB, новая структура, исправленные редиректы — а не одна волшебная правка. Аудит должен честно фиксировать, что именно менялось, иначе непонятно, что повторять на следующем проекте.
Отдельно у меня есть статья про то, что конкретно убивает скорость загрузки и как её проверить по-честному — если у вас сайт «вроде не тормозит», но заявок мало, начните оттуда: читайте про скорость загрузки сайта.
Где аудит превращается в список пожеланий, а не в план работ
Частая ошибка — сдать заказчику список из тридцати пунктов без приоритета: «поправить текст кнопки» стоит рядом с «форма не отправляется на мобильном». Это разные по цене ошибки, и аудит без ранжирования просто перекладывает работу по приоритезации на того, кто и так не эксперт в этом.
Что должно быть в результате аудита, а не только в процессе
- [ ] Список сценариев, которые проверялись, а не общее «посмотрели сайт»
- [ ] Для каждой находки — на каком шаге сценария она возникает
- [ ] Приоритет: что полностью ломает сценарий, что просто раздражает
- [ ] Числа до правок — чтобы после было с чем сравнивать
- [ ] Отдельная проверка данных (цены, условия) с официальным источником, не только интерфейса
- [ ] Техническое ТЗ на правки, а не абстрактные пожелания — если аудит заказной, здесь помогает техническое задание на сайт
Если аудит делает подрядчик, а не вы сами, — тем более важно требовать числа до/после и конкретный список сценариев, а не общий отчёт на десять страниц с прилагательными. Больше про то, как принимать такую работу и не платить дважды, — в статье про работу с подрядчиками.
Повторная проверка — обязательная часть, а не бонус
Аудит без повторного замера после правок — это не аудит, а гипотеза. Я всегда фиксирую числа «до» именно для того, чтобы через месяц-два свериться: то, что казалось очевидным улучшением, иногда не даёт вообще ничего, а иногда даёт больше, чем ожидалось, — и тогда понятно, что чинить в первую очередь на следующем проекте.
Кто должен проводить аудит
Отдельный вопрос — кому доверить сам аудит. Автор проекта видит сайт слишком часто, чтобы замечать очевидное для новичка: он помнит, где что лежит, и неосознанно проходит сценарии короче, чем реальный посетитель. Штатный дизайнер тоже рискует оценивать сайт по своим критериям красоты, а не по факту прохождения сценария.
Рабочий вариант — сочетать два источника: свежий взгляд человека, который сайт не делал, и формальный прогон по сценариям через инструмент или агента, который не устаёт и не привыкает к интерфейсу. Второе особенно полезно, когда нужно проверить несколько проектов сразу и нет времени проходить каждый сценарий руками десятки раз — здесь автоматика выигрывает по скорости, но окончательное решение «понятно ли это живому человеку» я всё равно оставляю за собой.
Итог простой: юзабилити-аудит работает, только когда он измеримый, сценарный и повторяемый. Всё остальное — мнение одного человека о дизайне, которое стоит ровно столько, сколько стоит любое чужое мнение.
- Прежде чем звать кого-то на аудит, зафиксируйте 3–5 ключевых сценариев пользователя (найти цену, оставить заявку, найти контакты) — аудит без сценариев превращается в список случайных придирок.
- Проверяйте не только интерфейс, но и данные: цены, контакты, условия — сверяйте с официальным источником, а не с тем, что уже стоит на сайте.
- Замеряйте технические метрики до правок и после — без цифр «стало лучше» нельзя проверить.
- Зовите на аудит человека или инструмент со свежим взглядом — автор проекта слепнет к собственным решениям через пару недель работы.
- Не считайте аудит законченным после одного прохода — на сложном сайте по-настоящему полезные находки появляются на втором-третьем сценарии, когда вы уже понимаете логику страницы.
Гайд «SEO-машина»: как собрать её на ИИ-агентах
Карта из десяти систем: что делает каждая и как собрать такую же — с любым ИИ-агентом, Claude Code или Codex. Бесплатно, отдаёт бот в Telegram.
Частые вопросы
Что такое юзабилити-аудит сайта?
Это проверка сайта по конкретным пользовательским сценариям (найти товар, оставить заявку, найти контакты) с фиксацией мест, где человек теряется, ошибается или уходит. В отличие от дизайн-ревью, юзабилити-аудит опирается на измеримые метрики и реальное поведение, а не на субъективную оценку внешнего вида.
Чем юзабилити-аудит отличается от технического аудита сайта?
Технический аудит проверяет код, скорость, индексацию и структуру. Юзабилити-аудит проверяет путь пользователя — насколько легко ему найти нужную информацию и совершить целевое действие. На практике они пересекаются: медленная загрузка или битая форма — это одновременно и техническая, и юзабилити-проблема.
Как провести юзабилити-аудит сайта самостоятельно?
Составьте 3–5 сценариев, которые реально выполняет ваш посетитель, и пройдите их сами с чистой историей браузера, засекая, где возникает заминка. Отдельно сверьте данные на сайте (цены, условия, контакты) с официальным источником. Замерьте технические метрики — скорость загрузки, путь до формы в кликах, работоспособность формы на мобильном.
Сколько стоит юзабилити-аудит сайта?
Разброс большой: от бесплатного самостоятельного прогона по сценариям до заказного аудита у агентства. У меня нет универсальной цифры — конкретно стоимость аудита я в проектах отдельно не выставлял, обычно это часть более крупной работы по редизайну или технической проверке.
Как часто нужно проводить юзабилити-аудит?
После любого значимого изменения — редизайна, смены оффера, добавления новой формы — и вдобавок раз в несколько месяцев на живом сайте, потому что поведение пользователей и контент меняются, а старые сценарии могут устаревать незаметно.
Может ли нейросеть провести юзабилити-аудит сайта?
Нейросеть или headless-браузер с прогоном по сценариям хорошо ловит формальные вещи: битые ссылки, расхождения текста, медленные страницы, нелогичную структуру. Финальную оценку «понятно ли это живому человеку» я всё равно проверяю сам — здесь автоматика ускоряет процесс, но не заменяет его целиком.