Сервис ремонта кофемашин получает переходы из Яндекса, но почти не получает заявок со страницы услуги. На первом экране написано «Качество. Надёжность. Результат», срок выезда спрятан ниже, чат перекрывает кнопку на телефоне, а форма после одной ошибки очищает все поля.
Юзабилити-аудит должен показать не то, что сайт «устарел» или «выглядит неудобно», а точное место, где посетитель не может сделать следующий шаг. Для этого возьмём один учебный путь: запрос о срочном ремонте кофемашины для кафе, посадочную страницу, мобильный телефон и отправку формы. В конце получим задачи, которые разработчик сможет воспроизвести, а владелец сайта — принять.
Начните не с сайта, а с одного посетителя
Аудит всего сайта без границ быстро превращается в прогулку по страницам. Один участник обсуждает цвет кнопки, второй — меню, третий — шрифт. При этом никто не проверяет, может ли реальный посетитель решить свою задачу.
Сначала запишите четыре вещи:
- запрос — что человек искал в Яндексе;
- посадочная страница — куда он попал из выдачи;
- устройство — телефон или компьютер;
- результат — что должно произойти: звонок, заявка, заказ или переход к расчёту.
Для нашего примера запись выглядит так: «Владелец кафе ищет срочный ремонт кофемашины, открывает страницу услуги на телефоне и хочет узнать срок выезда мастера, затем оставить номер». Это и есть сценарий пользовательского аудита. Он задаёт порядок проверки и не даёт смешать в одной задаче навигацию, дизайн всего сайта и общую SEO-стратегию.
Не начинайте с показателя отказов. Сначала воспроизведите конкретный путь. Метрика поможет найти похожие эпизоды позже, но не объяснит сама, почему человек ушёл.
Проверьте первый экран на соответствие запросу
Посетитель открывает страницу, чтобы выбрать исполнителя и решить проблему. Он хочет быстро понять, ремонтируете ли вы нужную технику, работаете ли с кафе в его городе и когда сможете приехать. Первый экран должен ответить хотя бы на эти вопросы или показать, где получить ответ.
Фраза «Качество, надёжность, результат» не помогает выбрать сервис: её можно поставить на сайт клининга, юриста или производителя мебели. Замените общий лозунг предметным сообщением: «Ремонт профессиональных кофемашин в Москве — выезд мастера в согласованный день».
Если точный срок зависит от адреса и загрузки, так и напишите. Не придумывайте обещание ради конверсии.
Проверьте первый экран пятью вопросами:
- Название услуги совпадает с задачей посетителя?
- Понятно, для кого и в каком регионе работает компания?
- Названо важное условие: срок, формат выезда, цена диагностики или способ расчёта?
- Кнопка описывает следующее действие, а не просто говорит «Подробнее»?
- Чат, баннер или запрос cookie не закрывает заголовок и кнопку?
Яндекс Вебмастер рекомендует давать человеку прямой доступ к нужному материалу, не заставляя его пробираться через рекламу и всплывающие окна. Это полезный критерий и для UX: важный ответ должен находиться на самой странице, а не только в чате после передачи телефона.
Пройдите путь до формы без подсказок
Нажмите основную кнопку и продолжайте как новый посетитель. Не используйте знания о структуре сайта и не исправляйте маршрут мысленно. Если кнопка открыла общий раздел услуг вместо формы ремонта, запишите это как отдельный барьер.
На пути к заявке человек обычно ищет ответы на три группы вопросов:
| Решение посетителя | Что проверить на странице |
|---|---|
| «Вы решаете мою проблему?» | Типы техники, перечень работ, ограничения и регион |
| «Можно ли вам доверять?» | Реквизиты, контакты, реальные условия гарантии, специалисты и подтверждённые примеры |
| «Что будет после обращения?» | Состав заявки, срок ответа, порядок диагностики и следующий шаг |
Следите за логикой навигации только там, где она участвует в сценарии. Посетителю страницы ремонта не обязательно изучать всё меню. Ему нужны понятные переходы к условиям, ценам или форме. Хлебные крошки и меню полезны, если помогают вернуться или выбрать соседнюю услугу, но не заменяют ответ на самой посадочной.
Остановитесь в каждом месте, где приходится угадывать. Кнопка «Рассчитать» открывает форму консультации? Слово «сервис» ведёт к ремонту или к гарантийному обслуживанию?
Что входит в цену? Если ответа нет, посетителю приходится гадать. Такие расхождения ломают путь воронки даже при аккуратном дизайне интерфейса.
Отправьте заявку с телефона
Форма проверяется настоящей отправкой, а не взглядом на макет. Откройте страницу на телефоне, нажмите кнопку и заполните поля. Убедитесь, что клавиатура не закрывает подсказку, маска телефона принимает корректный номер, а кнопка остаётся доступной после появления системной клавиатуры.
Сначала намеренно допустите ошибку: пропустите обязательное поле или введите неполный номер. Хорошая форма указывает конкретное место и объясняет, что исправить. Остальные введённые данные сохраняются. В нашем примере форма очищает имя, телефон и комментарий после одной ошибки — человек должен повторить всю работу.
Затем отправьте корректную тестовую заявку. На экране должно появиться понятное подтверждение: данные приняты, когда ждать ответ и как связаться срочно. Проверьте, дошло ли обращение в почту или CRM и сработала ли цель в Метрике. Сообщение «Успешно» без фактической заявки не считается пройденным тестом.
Отдельно посмотрите, не перекрывают ли форму чат, панель cookie, кнопка звонка или меню. На небольших мобильных экранах два плавающих элемента могут занять половину видимой области. Подробная техническая проверка адаптивности вынесена в материал о мобильной версии сайта; здесь нас интересует конкретно завершение заявки.
Найдите подтверждение в Яндекс Метрике
Ручной тест показывает возможный барьер. Теперь проверьте, встречается ли он у посетителей. В Яндекс Метрике создайте сегмент: источник — переходы из поиска Яндекса, посадочная — проверяемая страница, устройство — смартфон. Сравнивать все каналы и все URL сразу бессмысленно: у них разные ожидания и сценарии.
Вебвизор показывает то содержимое, которое видел посетитель, его переходы, клики, прокрутку и действия на мобильном устройстве. Найдите визиты, в которых человек дошёл до формы, вызвал клавиатуру, получил ошибку или несколько раз нажал перекрытую кнопку. Одна запись — пример, а не доказательство масштаба проблемы. Ищите повторение в сопоставимых визитах.
Карта скроллинга показывает, какие области страницы получали больше внимания. Если большинство посетителей не доходит до блока со сроком выезда, это повод проверить расположение информации. Но карта не объясняет причину: человек мог получить ответ выше, уйти из-за цены или отвлечься. Поэтому наблюдение соединяют с ручным сценарием и записями визитов.
Карта кликов помогает заметить неработающие ожидания. Например, люди нажимают на фотографию мастера, считая её ссылкой, или пытаются раскрыть заголовок без интерактивного элемента. Сначала проверьте элемент вручную.
Граница вывода: Метрика показывает, что делал посетитель, но не читает его мысли. Причину подтверждают повторяемый эпизод, воспроизведение ошибки и, при необходимости, разговор с пользователем.
Если цели для заявки ещё нет, сначала настройте измерение. Отдельная инструкция объясняет, как настроить цели в Яндекс Метрике для SEO-заявок. Без события успешной отправки команда видит посещения, но не знает, закончился ли пользовательский путь.
Записывайте барьер как воспроизводимую задачу
Фраза «форма неудобная» не помогает разработчику. Он не знает, на какой странице, устройстве и шаге возникла проблема. Запишите барьер так, чтобы другой человек воспроизвёл его без устного пояснения.
| Поле задачи | Пример |
|---|---|
| Условие | Страница ремонта, смартфон шириной 360 px, форма из первого экрана |
| Шаги | Заполнить имя и комментарий, оставить телефон неполным, нажать «Отправить» |
| Фактический результат | Появляется ошибка телефона, имя и комментарий очищаются |
| Ожидаемый результат | Подсвечивается поле телефона, остальные данные сохраняются |
| Доказательство | Запись экрана, URL, время теста и примеры похожих визитов |
Добавьте владельца задачи и критерий приёмки. Для примера критерий звучит так: «После ошибки телефона имя и комментарий остаются заполненными; сообщение находится рядом с полем; после корректной отправки заявка появляется в CRM и срабатывает цель». Это точнее, чем требование «улучшить UX формы».
Расставьте приоритеты без вкусовых споров
Срочность найденных проблем различается. Сравните их по четырём вопросам:
- Тяжесть. Ошибка полностью останавливает заявку или только замедляет чтение?
- Охват. Она есть на одной странице или во всех формах шаблона?
- Подтверждение. Проблема воспроизводится и встречается в данных или остаётся гипотезой?
- Стоимость исправления. Нужна правка текста, шаблона или отдельная разработка?
Первым исправьте очистку формы. Она останавливает заявку и воспроизводится. Перекрытая кнопка на мобильных — следующая критическая ошибка, особенно если тот же виджет подключён ко всем услугам. Общий лозунг на первом экране важен, но его можно исправлять после восстановления работоспособности формы.
Не складывайте четыре критерия в выдуманный «точный» балл, если у команды нет согласованной шкалы. Достаточно записать основание решения: блокирует заявку, затрагивает все страницы услуг, подтверждено тестом, исправляется в общем шаблоне. Такой приоритет можно обсудить без спора о личных вкусах.
Повторите сценарий после исправления
Сообщение разработчика «готово» не завершает аудит. Откройте ту же страницу на том же типе устройства и повторите исходные шаги. Сначала вызовите ошибку телефона, затем исправьте номер и отправьте заявку. Проверьте сохранение полей, сообщение об успехе, получение обращения и цель Метрики.
После технической приёмки сохраните дату релиза и наблюдайте за тем же сегментом. Сравнивайте сопоставимые периоды, устройства и посадочные страницы. Рост конверсии может зависеть от спроса, источника, предложения и других изменений, поэтому одна правка интерфейса не гарантирует новый показатель.
Результат юзабилити-аудита — не длинный чек-лист, а короткая очередь подтверждённых задач. Для каждой понятно, кто столкнулся с барьером, на каком шаге, что произошло и как принять исправление. Если проблем много и они затрагивают структуру, контент, аналитику и техническую часть, включите их в общий SEO-аудит и план развития сайта, сохранив отдельные критерии для каждого сценария.