Как провести аудит юзабилити сайта

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

Аудит юзабилити начинается не с дизайна, а с вопроса «что человек пришел сюда сделать». Если ответа на этот вопрос нет, любая проверка превращается в перечень личных претензий к шрифтам и отступам, а такой список невозможно ни защитить перед руководителем, ни поставить в работу программисту.

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

Что такое юзабилити-аудит и что он не решает

Юзабилити — не «красота» и не «удобство вообще». ГОСТ Р ИСО 9241-11-2010 определяет пригодность использования через 3 измеримые вещи: результативность (человек дошел до цели), эффективность (сколько сил и времени он на это потратил) и удовлетворенность (насколько ему было комфортно). Из этого определения следует вся методика: чтобы что-то проверять, нужно знать пользователя, его цель и условия, в которых он работает.

Отсюда и граница аудита. Он отвечает на вопрос «где человек спотыкается на пути к цели» и не отвечает на вопросы «почему мало трафика» и «почему сайт медленно грузится». Соседние задачи решают другие проверки:

• Технический аудит. Коды ответов, индексация, дубли, битые ссылки — это чек-лист технического аудита, а не юзабилити.
• Работа над конверсией. Пересборка предложения, цены, гарантии, аргументы на посадочной — отдельная история, мы разбирали ее в материале о том, как повысить конверсию сайта.
• Редизайн. Это следствие аудита, а не его замена. Если интерфейс переделывают до проверки, вместе с плохими решениями выбрасывают и рабочие.

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

Начните с 4 сценариев, а не с главной страницы

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

Сначала выпишите сценарии: зачем люди приходят на сайт и чем должен закончиться визит. Для большинства коммерческих сайтов их получается 3–5. Например, для магазина оборудования:

1. Найти конкретную модель по названию или артикулу и положить в корзину.
2. Подобрать товар по параметрам, не зная точного названия.
3. Узнать условия доставки в свой город до оформления заказа.
4. Связаться с менеджером, потому что нужной позиции нет в наличии.

Каждый сценарий описывается одинаково: кто идет (новый посетитель или клиент, телефон или десктоп), с какого экрана начинает, что считается успехом. Дальше весь аудит крутится вокруг этих маршрутов, и проверяются только те экраны, которые в них попадают. Страница «О компании», по которой не проходит ни один сценарий, в аудит не входит — даже если она выглядит хуже остальных.

У сценариев есть побочная польза. Когда правки дойдут до спора «нужна ли тут кнопка», аргументом будет не мнение, а маршрут: без нее человек не заканчивает второй сценарий.

Шаг 1. Собрать данные, а не мнения

До того как открыть сайт глазами дизайнера, посмотрите, что уже известно про поведение людей. Бесплатный набор в Яндекс Метрике закрывает большую часть задачи, если в настройках счетчика включена опция «Вебвизор, карта скроллинга, аналитика форм».

• Карта скроллинга. Показывает, до какой высоты страницы вообще доходят. Если блок с ценами лежит ниже зоны, куда добирается меньшинство, спор «видно его или нет» закрыт.
• Карта ссылок. Дает количество переходов по каждой ссылке и долю относительно остальных. Удобна, чтобы найти элементы, которые выглядят как главные, но не собирают кликов.
• Карта кликов. Ловит клики по тому, что кликабельным не является: по картинкам товара, по заголовкам, по иконкам рядом с ценой. Каждое такое пятно — несовпадение ожидания и реальности.
• Аналитика форм. Отвечает, на каком поле люди останавливаются и сколько времени тратят на каждое.
• Вебвизор. Нужен точечно: посмотреть 10–15 записей визитов, которые закончились ничем, по конкретному сценарию.

У инструмента есть ограничения, и знать их полезнее, чем потом гадать, почему отчет пустой. В отчете не больше 100 тыс. событий независимо от семплирования. Ссылки, ведущие на редирект, на карте не подсвечиваются. Карта отключается сама, если ее не открывали 6 мес. — тогда данные просто не пишутся, и включать опцию нужно заново. А если на сайте стоит заголовок X-Frame-Options, карты не покажутся вовсе: страница не открывается во фрейме. Лечится исключением для доменов Метрики.

location / {
    set $frame_options '';
    # пускаем во фрейм только свой домен и домены Метрики
    if ($http_referer !~ '^https?:\/\/([^\/]+\.)?(example\.ru|webvisor\.com|metri[ck]a\.yandex\.(com|ru|by|com\.tr))\/') {
        set $frame_options 'SAMEORIGIN';
    }
    add_header X-Frame-Options $frame_options;
}

Еще одна ловушка из справки: если в фильтрах счетчика включена операция «Заменять https на http», карта покажет «Нет данных» — адреса в отчете и адреса сайта перестают совпадать.

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

Шаг 2. Пройти сценарий руками и записать каждую заминку

Дальше вы проходите каждый выписанный сценарий сами, от начала до успеха, и фиксируете все места, где пришлось остановиться и подумать. Правила прохода жестче, чем кажется.

• Чистая сессия. Режим инкогнито, без автозаполнения и без сохраненных адресов. Ваш браузер знает про сайт слишком много.
• Сначала телефон. Если основной трафик мобильный, десктоп проверяется вторым. Обратный порядок приводит к тому, что половина находок мобильной версии просто не замечается.
• Медленная сеть. В инструментах разработчика включите ограничение скорости и посмотрите, что видит человек в первые 2–3 секунды: пустой экран, скачущий макет или контент.
• Вход с внутренней страницы. Люди из поиска приходят не на главную. Начинайте сценарий с карточки товара или страницы услуги — там часто нет ни навигации, ни цены, ни кнопки.

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

Мы в Design Lab держим эти записи в обычной таблице: экран, шаг сценария, что происходит, подтверждение, гипотеза, приоритет. Скриншот с обведенным местом прикладывается к строке, а не собирается в отдельную презентацию — так правка доезжает до разработчика без пересказа.

Шаг 3. Проверка по пунктам: 6 блоков интерфейса

Ручной проход ловит крупные провалы. Мелочи, которые складываются в общее ощущение неудобства, ловятся списком. Вот блоки, по которым мы идем, и вопросы внутри каждого.

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

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

Формы. Разбираются отдельно ниже, это самое доходное место аудита.

Мобильная версия. Помещается ли контент по ширине без горизонтальной прокрутки, не перекрывает ли плавающая кнопка поле ввода, работает ли зум на фотографиях товара, не прилипает ли к экрану баннер с cookie так, что до кнопки не добраться.

Доступность. Здесь есть измеримые критерии, их можно проверять без экспертных споров. Критерий 2.5.8 WCAG 2.2 требует, чтобы область нажатия была не меньше 24 на 24 CSS-пикселя, а если элемент меньше — чтобы вокруг него было достаточно свободного места и соседние цели не перекрывались. Исключения оговорены: ссылки внутри строки текста и случаи, когда рядом есть другой элемент с той же функцией нужного размера. Проверьте иконки удаления в корзине, стрелки слайдера, крестик закрытия модального окна и переключатели количества — на мобильном они почти всегда мельче нормы.

Отзывчивость. Скорость загрузки и скорость реакции — разные вещи. За реакцию отвечает метрика INP: по описанию Google значение до 200 мс на 75-м перцентиле считается хорошим, от 200 до 500 мс — требующим улучшения, выше 500 мс — плохим. Практический перевод: если после нажатия на «Купить» экран замирает на полсекунды и ничего не происходит, человек нажмет второй раз. Дальше — либо 2 одинаковых товара в корзине, либо 2 заявки в CRM. Про измерение и ускорение самой загрузки есть отдельный разбор о том, как проверить скорость загрузки сайта.

Формы: где теряется больше всего

Форма — единственное место, где человек обязан что-то сделать руками, и единственное, где ошибка стоит заявки целиком. Аналитика форм в Метрике показывает, на каком поле останавливаются, а дальше поле разбирается по 4 признакам.

• Нужно ли оно вообще. Отчество, компания, должность, «откуда вы о нас узнали» — каждое такое поле оплачивается частью заявок. Если менеджер все равно уточняет это в разговоре, поле лишнее.
• Понятно ли, что вводить. Подпись у поля, а не внутри него: плейсхолдер исчезает после первого символа, и человек перестает понимать, что он заполняет.
• Помогает ли браузер. Правильные type, inputmode и autocomplete включают на телефоне нужную клавиатуру и автоподстановку.
• Что происходит при ошибке. Сообщение рядом с полем, а не общей строкой вверху; введенные данные не стираются; текст объясняет, что исправить.

<label for="phone">Телефон для связи</label>
<input id="phone" name="phone" type="tel" inputmode="tel"
       autocomplete="tel" required
       aria-describedby="phone-hint">
<p id="phone-hint">Позвоним в рабочее время, до 19:00</p>

Разница между этой разметкой и обычным <input placeholder="Телефон"> — 4 строки кода и заметная часть незавершенных заполнений на мобильных.

Возьмем собирательный пример: в форме заказа 7 полей, из них 3 необязательные по сути. Аналитика форм показывает, что дольше всего люди сидят на поле «Адрес доставки» с ручным вводом. Вывод аудита формулируется как 2 конкретные правки: убрать 3 поля и подключить подсказку адреса. Обе формулируются как задача программисту и проверяются по той же аналитике через месяц.

Как оформить результат, чтобы его можно было внедрить

Отчет на 80 слайдов с рассуждениями о трендах не внедряется никогда. Работающий формат — таблица находок, отсортированная так, чтобы сверху лежало то, что делается первым.

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

К каждой строке прикладывается скриншот с обведенным местом и, если есть, номер записи из Вебвизора. Формулировка находки пишется так, чтобы ее можно было скопировать в задачу: не «неудобная корзина», а «на шаге оплаты кнопка „Оформить“ уезжает под клавиатуру на iPhone, поле промокода перекрывает ее».

Что делать с находками: чинить, а не начинать редизайн

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

Рабочий порядок другой. Сначала выкатываются правки из верхней части таблицы, потом смотрятся те же отчеты, что и до аудита: доходят ли теперь до блока с ценой, на каком поле останавливаются в форме, сколько кликов собирает кнопка. Спорные изменения, где мнения в команде разошлись, проверяются экспериментом в Вариокубе — это бесплатный инструмент Яндекса для A/B-тестов, связанный с Метрикой.

Отдельная категория находок — те, что упираются в структуру каталога или логику заказа. Их нельзя починить правкой шаблона, и именно они становятся основанием для проектирования новых экранов. Если таких набирается больше трети списка, разговор про редизайн сайта становится обоснованным, и аудит превращается в исходные данные для него. Точечные же правки шаблонов и форм — это обычная доработка сайта, ее объем считается в часах.

Сколько это занимает и когда аудит не нужен

Для сайта с 3–5 сценариями сбор данных и ручной проход занимают 2–3 рабочих дня, проверка по пунктам и оформление — еще столько же. Если в проекте есть личный кабинет или сложный конфигуратор, сроки растут: там сценариев больше и каждый длиннее.

Есть ситуации, в которых аудит проводить рано.

• Сайт запущен неделю назад. Данных нет, а проверка по сценариям делается быстрее и дешевле как часть приемки, а не как отдельная работа.
• На сайт не идет трафик. Сначала нужен хоть какой-то поток посетителей, иначе улучшать нечего, и проблема лежит не в интерфейсе.
• Уже принято решение о редизайне. Тогда исследование встраивается в проектирование, а не живет отдельным документом, который потом никто не откроет.

С чего начать на этой неделе

Не пытайтесь провести аудит целиком с первого раза. Возьмите один сценарий — тот, который приносит деньги, — и пройдите его на своем телефоне в режиме инкогнито. Записывайте каждое место, где пришлось остановиться и подумать. Обычно на 1 сценарий набирается от 5 до 15 заминок, и половина из них чинится правкой шаблона.

Дальше откройте карту скроллинга по той же странице и сверьте: то, что вы считали главным на экране, люди вообще видят? Эти 2 действия занимают час и дают больше, чем пересказ чужих рекомендаций по дизайну.