Как за 2 часа провести UX-аудит сайта: чек-лист
Почему двух часов достаточно, чтобы найти реальные проблемы
Практически каждый клиент, с которым я работал, в какой-то момент просил «полный UX-аудит». Обычно под этим подразумевается двухнедельная работа с тепловыми картами, записями сессий, слайдами конкурентного анализа и 40-страничным PDF, который никто в команде не дочитает дальше шестой страницы. У такого аудита есть своё место, но это не то, что нужно большинству сайтов в первую очередь. Большинству сайтов нужно, чтобы кто-то сел, попользовался продуктом как реальный посетитель, и записал каждую точку трения, пока не потерял нить того, что действительно не так.
Я проводил такую двухчасовую версию десятки раз — для собственных клиентов перед стартом редизайна, для агентств, подхватывающих проект на середине, для основателей бизнеса, которые просто хотят получить трезвую оценку перед тем, как тратить деньги на переделку. Она стабильно вскрывает 80% проблем, которые найдёт полноценный аудит, потому что большинство проблем UX не скрыты. Они лежат прямо на главной странице, в процессе оформления заказа, в форме обратной связи, которая молча не работает в мобильном Safari. Не нужно шесть недель исследований, чтобы заметить кнопку отправки того же цвета, что и фон.
Смысл ограничения по времени не в том, чтобы работать поверхностно. Он в том, чтобы заставить себя расставить приоритеты. Когда у вас есть два часа, вы перестаёте гоняться за каждой микродеталью и начинаете искать ту небольшую горстку проблем, которая реально стоит компании конверсий, доверия или времени. Для клиента это куда полезнее документа, где чуть-чуть маленький line-height получает такое же внимание, как и сломанный чекаут.
Этот чек-лист рассчитан на то, чтобы пройти его за один присест, по порядку, с таймером. Предполагается, что у вас есть доступ к живому сайту, по возможности — к аналитике (не обязательно), и блокнот или простой документ, куда вы записываете находки по ходу дела, а не в конце. Приступим.
Перед началом: настройка на 10 минут
Пропуск подготовительного этапа — главная причина, по которой самостоятельные аудиты превращаются в бесцельное блуждание по сайту. Потратьте первые десять минут на это, и остальная часть аудита пойдёт сама собой.
- Определите, за кого вы себя выдаёте. Выберите одну основную персону пользователя и одну основную цель — «новый посетитель из поиска Google, пытающийся понять, занимается ли это агентство брендингом» или «постоянный клиент, пытающийся повторить заказ». Запишите это в начале заметок. Каждое суждение во время аудита должно проходить через эту призму, а не через ваш личный вкус.
- Очистите кэш или откройте окно в режиме инкогнито. Вам нужно увидеть то, что видит новый посетитель, а не версию с сохранёнными логинами и закрытыми баннерами про cookie.
- Откройте три среды. Chrome на десктопе, реальное мобильное устройство (не только режим адаптива в DevTools — реальные размеры зон касания и реальное время загрузки имеют значение) и, если есть возможность, эмуляцию медленного соединения. Устройства «врут» друг другу: макет, который отлично выглядит на вашем MacBook, регулярно ломается на среднем Android.
- Загляните в аналитику на пять минут, если есть доступ. Глубокое погружение не нужно — только топ-5 страниц по трафику, показатель отказов на этих страницах и точка, где люди «отваливаются» в любой воронке (корзина, форма, регистрация). Это подскажет, куда потратить ограниченное время. Если доступа к аналитике нет, по умолчанию берите главную страницу, основную страницу продукта/услуги и главную форму конверсии.
- Поставьте таймер на каждый раздел ниже. Это тот пункт, который люди пропускают и потом жалеют. Без таймера вы потратите 40 минут на главную страницу и 5 — на чекаут, что для большинства сайтов совершенно неверное распределение.
Ещё одна важная вещь: сначала записывайте, что не так, а не почему. Хочется сразу диагностировать и предлагать решение, но это замедляет вас и часто приводит к преждевременным решениям. Фиксируйте симптом, идите дальше, к исправлениям вернётесь в последние 20 минут.
Минуты 10–30: первые 8 секунд под стресс-тестом
Этот блок посвящён главной странице — или, если большая часть трафика приходит на другую страницу, той странице, которую большинство людей видят первой. Загрузите страницу «с холодного старта», запустите секундомер и дайте себе ровно 8 секунд, прежде чем разрешить себе скроллить. Затем ответьте вслух или письменно: чем занимается эта компания и для кого она?
Если вы не можете ответить уверенно — это не мелкая придирка, это и есть находка. Я проводил аудиты для по-настоящему хороших компаний, где заголовок главной страницы был размытой фразой вроде «Строим будущее человеческих связей» без единого намёка на индустрию, аудиторию или предложение. Остроумные слоганы — это роскошь, которую могут себе позволить только очень известные бренды. Всем остальным нужна ясность раньше, чем остроумие.
Пройдитесь по этому списку в hero-секции и в области, видимой без скролла:
- Тест ценностного предложения. Заголовок сообщает, чем занимается бизнес, для кого и почему это важно — простым языком, понятным незнакомцу? Если приходится перечитывать дважды, отметьте это как проблему.
- Основной призыв к действию. Есть ли один очевидный следующий шаг, или там четыре конкурирующие кнопки («Начать», «Узнать больше», «Забронировать демо», «Связаться с нами») без визуальной иерархии, которая подсказывала бы посетителю, что важнее?
- Проверка визуальной иерархии. Прищурьтесь на страницу или слегка расфокусируйте взгляд. На чём первым останавливается глаз? Это то, что должно быть первым — как правило, ценностное предложение или CTA — или это декоративное изображение, анимация слайдера или карусель логотипов?
- Сигналы доверия в первом экране. Для чего-либо транзакционного (агентства, SaaS, e-commerce) — есть ли какое-то указание на надёжность, видимое рано: логотипы клиентов, количество отзывов, упоминание узнаваемого бренда? Необязательно, но их отсутствие особенно важно на страницах с холодным трафиком.
- Скорость загрузки на ощущениях, а не по замерам. Открывать Lighthouse для этого пункта пока не нужно (это будет позже) — просто заметьте: контент hero-секции появился мгновенно, или вы сидели, глядя на пустой экран или скачки макета, пока подгружались шрифты и изображения?
Затем пролистайте оставшуюся часть главной страницы в нормальном темпе — таком, в каком её листал бы нетерпеливый посетитель, а это быстрее, чем вы думаете — и фиксируйте всё, что нарушает ритм сканирования: стены текста без подзаголовков, разделы, чьё назначение неясно с первого взгляда, стоковые фото, которые ничего не говорят о реальном бизнесе, или CTA, повторённые настолько одинаково, что ни один из них не ощущается как «то самое» действие.
Полезный приём: читайте только заголовки и подзаголовки на странице, пропуская весь основной текст. Если страница всё равно рассказывает связную историю, используя только их, значит иерархия контента работает как надо. Если это читается как случайный список названий разделов, структуре нужна работа — независимо от того, насколько хорош текст под этими заголовками.
Минуты 30–60: навигация и информационная архитектура
Здесь большинство аудитов находят либо золото, либо ничего — в зависимости от того, насколько осознанно вы это тестируете. Случайное кликание по меню навигации не выявляет проблем ИА — их выявляет навигация на основе конкретных задач.
Запишите три-пять реалистичных задач, с которыми посетитель приходит на сайт. Для сайта агентства: «найти цены», «найти кейс в определённой индустрии», «узнать, как связаться с командой». Для e-commerce: «найти политику возврата», «найти конкретную категорию товаров», «проверить, доставляет ли товар за границу». Для SaaS: «узнать, есть ли бесплатный пробный период», «найти информацию об интеграциях», «узнать, как отменить подписку».
Для каждой задачи засекайте время выполнения и считайте клики. Затем оцените:
- Уложились ли вы в три клика? После трёх кликов большинство реальных пользователей уже бросили бы это дело или открыли чат поддержки. Если задача требует четырёх-пяти кликов — это структурная проблема, а не вопрос визуальной полировки.
- Соответствовали ли пункты навигации вашей мысленной модели? Это самый распространённый сбой ИА, который я вижу. Компании обожают внутренний жаргон в навигации — «Решения», «Платформа», «Экосистема» — который что-то значит для команды и ничего не значит для нового посетителя. Если вы замешкались, выбирая, на какой пункт меню кликнуть для задачи, то замешкается и любой другой пользователь.
- Есть ли функция поиска, и работает ли она? Введите в поиск по сайту (если он есть) реальное название продукта или реальный вопрос. Удивительное количество внутренних поисков выдаёт «ничего не найдено» по терминам, которые точно есть на сайте — обычно потому, что поиск индексирует только заголовки страниц, а не содержимое.
- Хлебные крошки и подсказки «где я нахожусь». На любом сайте глубже трёх уровней проверьте, может ли посетитель понять, где он находится в структуре, и как вернуться на уровень выше без многократного нажатия кнопки «назад» в браузере.
- Аудит подвала (футера). Именно в футере прячется умирающая информационная архитектура. Проверьте, бесполезно ли дублирует футер навигацию в хедере, или он действительно выводит на поверхность второстепенные вещи, которые люди ищут — юридические страницы, карту сайта, дополнительные способы связи, социальные доказательства.
Пока вы двигаетесь по навигации, ведите отдельный список тупиков: страниц без явного следующего шага, страниц, которые никуда релевантно не ведут, «осиротевшего» контента, который, кажется, существует лишь потому, что кому-то он когда-то понадобился. Такое накапливается на сайтах, которые работают несколько лет без обслуживания ИА, и незаметно повышает показатель отказов на страницах, у которых в остальном вполне неплохой контент.
Ещё одна проверка, занимающая тридцать секунд и вылавливающая реальные проблемы: откройте мобильную навигацию (меню-гамбургер) и посчитайте, сколько тапов требуется, чтобы его закрыть, и корректно ли оно захватывает фокус. Меню, которые не закрываются при клике по ссылке или требуют скролла внутри уже проскроленной страницы — распространённая проблема, которую стоит проверять каждый раз.
Минуты 60–90: пройдите основной путь конверсии от начала до конца
Это самые ценные 30 минут во всём аудите, и именно их большинство людей проходят второпях, потому что они требуют реально заполнить форму, чекаут или регистрацию — иногда с фейковыми данными, иногда по-настоящему. Всё равно сделайте это. Прочитать форму — не то же самое, что заполнить её.
Определите один поток, который важнее всего для бизнеса — чекаут для e-commerce, форму заявки/запроса цены для агентства или B2B-услуги, регистрацию для SaaS, форму бронирования для сервисного бизнеса — и пройдите его так, как это сделала бы выбранная вами персона, от начала до конца, и на десктопе, и на мобильном.
На каждом шаге проверяйте:
- Количество полей и их необходимость. Посчитайте каждое поле ввода. Для каждого спросите, действительно ли оно нужно на этом этапе, или его можно собрать позже. Форма обратной связи, спрашивающая размер компании, диапазон бюджета и «как вы о нас узнали» до того, как человек хотя бы получил ответ — это трение, которое стоит завершённых заявок, особенно на мобильном.
- Ясность подписей и плейсхолдеров. Кликните в каждое поле. Если подпись исчезает в момент, когда вы начинаете печатать (плейсхолдер вместо подписи — паттерн, который должен был умереть много лет назад), проверьте, можно ли всё же понять, для чего это поле, когда оно уже заполнено. Это постоянно сбивает пользователей с толку на длинных формах, когда они прокручивают назад проверить введённые данные.
- Обработка ошибок, намеренно. Специально отправьте форму неправильно — оставьте обязательное поле пустым, введите неверный email, укажите телефон в неправильном формате. Появляется ли сообщение об ошибке рядом с полем, к которому оно относится, простым языком, без сброса всей формы или прокрутки наверх с потерей остальных введённых данных? Плохая обработка ошибок — один из самых распространённых тихих убийц конверсии, потому что она не проявляется, если не вызвать её специально.
- Индикация прогресса в многошаговых потоках. Если это несколько экранов, виден ли пользователю понятный сигнал, сколько шагов осталось? Немаркированные многошаговые потоки вызывают отказы, потому что пользователи не могут оценить оставшиеся усилия.
- Подтверждение и следующие шаги. После успешной отправки очевидно ли, что всё сработало? Смутное или отсутствующее подтверждение («спасибо» без указания, что происходит дальше, или, ещё хуже, перенаправление на главную страницу без единого сообщения) оставляет пользователя в неуверенности, стоит ли пытаться снова, что иногда приводит к повторным отправкам.
- Проверки, специфичные для оплаты, для e-commerce. Показываются ли стоимость доставки и налоги до последнего шага, или они выскакивают на пользователя только на финальном экране? Доступен ли гостевой чекаут, или регистрация обязательна? И то, и другое — хорошо изученные, документированные причины отказа от корзины, и обе легко проверить за пять минут.
Пройдите тот же поток на мобильном устройстве, а не просто в уменьшенном окне Chrome на десктопе. Зоны касания, которые выглядели нормально с курсором мыши, регулярно оказываются слишком маленькими или слишком близко друг к другу для пальца — классический случай, когда две кнопки или две ссылки расположены достаточно близко, чтобы чуть неточный тап попал не туда. Также проверьте, соответствует ли всплывающая мобильная клавиатура типу поля: поле для email должно вызывать раскладку с клавишей @, поле для телефона — цифровую клавиатуру. Если нет — это небольшая, но реальная точка трения, которая накапливается на форме с несколькими полями.
Если поток включает вход в личный кабинет, создайте тестовый аккаунт «на выброс» и пройдите онбординг так, как это сделал бы совершенно новый пользователь. Опыт первого запуска обычно плохо протестирован внутри команды, потому что у всех уже есть аккаунт с данными — они никогда не видят пустого состояния, запутанного экрана первого входа или онбординг-тура, который ссылается на функции, пока не видимые.
Минуты 90–110: выборочные проверки мобильной версии, скорости и доступности
Вы уже тестировали мобильную версию во всех предыдущих разделах, и это осознанно — мобильная версия не должна быть отдельным проходом «под конец», она должна быть встроена в каждую задачу, которую вы выполняли до этого. Этот блок — для проверок, которые касаются именно технической производительности и доступности, которые легко упустить, когда вы сосредоточены на потоках и текстах.
Для скорости прогоните главную страницу и одну «глубокую» страницу через бесплатный инструмент — подойдут Google PageSpeed Insights или GTmetrix, каждая проверка занимает меньше двух минут. Вы не пытаетесь стать в рамках этого аудита инженером по производительности — вы ищете красные флаги:
- Largest Contentful Paint больше 2,5 секунд. Обычно это означает неоптимизированное изображение или видео в hero-секции, и это часто исправление на пять минут (сжатие, правильный формат, ленивая загрузка ниже сгиба) с несоразмерно большим влиянием на показатель отказов.
- Cumulative Layout Shift. Заметьте, заметно ли «прыгает» контент по мере загрузки страницы — изображения без зарезервированных размеров, реклама или встроенные элементы, сдвигающие контент вниз, шрифты, которые подменяются и переупаковывают текст. Это одна из проблем, наиболее раздражающих пользователей и легко пропускаемых командой, потому что она происходит в первую секунду загрузки, которую человек, собравший страницу, обычно уже не отслеживает во время тестирования.
- Разрыв в показателях специфично для мобильной версии. Часто бывает, что производительность на десктопе в норме, а на мобильном — реально плохая, потому что мобильные соединения и процессоры вскрывают неэффективности, которые скрывает десктоп. Если разрыв большой, отметьте это отдельным пунктом — это требует отдельного внимания, а не общего исправления.
Для доступности полноценный аудит по WCAG за два часа не нужен, но эти проверки занимают пять минут и вылавливают реальные проблемы:
- Навигация с клавиатуры. Отложите мышь. Используйте только Tab, Shift+Tab и Enter, чтобы пройти по главной странице и одной форме. Можете ли вы добраться до каждого интерактивного элемента в логичном порядке, и видна ли на каждой остановке заметная индикация фокуса? Сайты без видимого состояния фокуса непригодны для пользователей, работающих только с клавиатуры, и это удивительно частая проблема даже на в остальном хорошо спроектированных сайтах, потому что она никогда не всплывает при QA с мышью.
- Контраст цвета на ключевом тексте. Используйте расширение браузера для проверки контраста или прикиньте на глаз соотношение 4,5:1 по WCAG для основного текста — светло-серый текст на белом фоне — самый распространённый нарушитель, обычно возникающий потому, что он «выглядит чисто» в файле дизайна при 100% масштабе на откалиброванном мониторе.
- Alt-текст у значимых изображений. Кликните правой кнопкой или изучите код нескольких содержательно важных изображений (не декоративных) и проверьте, есть ли alt-текст и является ли он описательным, а не пустым или заполненным именем файла.
- Тест масштабирования. Увеличьте масштаб браузера до 200% и проверьте, работает ли макет по-прежнему — текст не перекрывается, ничего не обрезается, горизонтальный скролл не появляется там, где не должен. Это симулирует и опыт слабовидящих пользователей, и, на практике, любого пользователя с нестандартным размером экрана.
Ничего из этого не требует специализированных инструментов сверх тех, что бесплатны и уже есть в вашем браузере. Цель этого блока — не сертификация на соответствие стандартам, а выявление той небольшой горстки пробелов в доступности, которые одновременно являются пробелами в удобстве использования для всех — а это большинство из них.
Минуты 110–120: превратите находки в конкретный план действий
К этому моменту у вас будет длинный, беспорядочный список — от пятнадцати до пятидесяти пунктов, в зависимости от возраста и сложности сайта. Последние десять минут посвящены тому, чтобы превратить этот список в то, с чем клиент или команда реально смогут работать, потому что неприоритизированный список всех недочётов бесполезен — он воспринимается либо как пугающий объём, либо как придирки, а часто и то, и другое.
Быстро разложите всё по трём корзинам, руководствуясь интуицией, а не формальной моделью оценки — на формальную модель у вас нет времени, и, откровенно говоря, для такого прохода интуиция человека, только что провёдшего два часа с продуктом — вполне легитимный метод:
- Исправить на этой неделе. Сломанные формы, отсутствующие состояния ошибок, всё, что блокирует основной путь конверсии, всё, что является явным багом, а не дизайнерским решением. Обычно это дёшево исправить и дорого оставить сломанным.
- Исправить в этом квартале. Переименование пунктов навигации, проблемы иерархии на главной странице, размер зон касания на мобильных, оптимизация производительности ключевых страниц. Это требует некоторого времени дизайнера или разработчика, но не полноценного проекта.
- Рассмотреть для следующего редизайна. Более глубокая перестройка ИА, полное обновление визуального стиля, всё, что требует пересборки, а не патча. Это законные находки, но они не должны блокировать действия по первым двум корзинам, пока все ждут запуска более крупного проекта.
Особенно для каждого пункта из первой корзины напишите одну фразу, связывающую проблему с влиянием на бизнес, а не просто с принципом UX. «Поле email не проверяет формат перед отправкой, что, вероятно, приводит к потере лидов, когда пользователи опечатываются и никогда этого не замечают» звучит для заинтересованной стороны совсем иначе, чем «полю email не хватает встроенной валидации». Первая формулировка получает одобрение бюджета; вторая откладывается в папку «неплохо бы, но не сейчас».
Если вы презентуете это клиенту, а не сами беретесь за исправления, устоите перед желанием включить абсолютно всё, что нашли. Отчёт из шестидесяти пунктов ощущается основательным, когда его пишешь, и парализующим, когда его получаешь. По моему опыту, оптимум — пять-десять пунктов на корзину, максимум — всё, что сверх этого, либо было недостаточно важным, чтобы попасть в отчёт, либо принадлежит следующему, более глубокому аудиту, а не этому проходу.
Также стоит прямо перечислить, что вы не успели проверить, а не позволять клиенту думать, что двухчасовой аудит был исчерпывающим. Такие вещи, как полноценное тестирование на соответствие требованиям доступности, реальное юзабилити-тестирование с настоящими целевыми пользователями, технический SEO-аудит или кросс-браузерное тестирование за пределами Chrome и одного мобильного устройства — всё это разумно отметить как «вне рамок этого прохода», чтобы никто не путал быструю диагностику с исчерпывающей.
Как сделать это привычкой, а не разовым мероприятием
Настоящая ценность такого чек-листа не в единичном аудите — она в том, что происходит, когда вы прогоняете его по одному и тому же сайту каждый квартал или по каждому новому клиентскому проекту, прежде чем открыть хоть один файл дизайна. Проявляются закономерности, которые не покажет разовый снимок ситуации: возвращается ли одна и та же категория проблем (трение в формах, мобильная производительность, неясные подписи в навигации) снова и снова после исправлений — что обычно указывает на проблему процесса, а не дизайна: возможно, новые страницы публикуются без проверки на соответствие базовому уровню, или никто не отвечает за проверку форм после изменений в тексте.
Отдельно фрилансерам и агентствам я бы посоветовал проводить именно эту последовательность как самую первую рабочую сессию на любом новом проекте, до всяких стратегических звонков и мудборд. Это даёт конкретные, предметные вещи для разговора на стартовой встрече вместо абстрактных вопросов типа «какая у вас личность бренда», и обычно сразу вызывает доверие у клиента, потому что вы приходите с наблюдениями о его реальном продукте, а не с общей рамкой. Это также защищает вас в будущем — если вы отметили сломанную обработку ошибок в чекауте на первой неделе, а клиент отложил это в приоритетах, теперь это документировано, и вас нельзя будет за это упрекнуть на двенадцатой неделе.
Ограничение в два часа — это не компромисс, а особенность метода. Оно заставляет доверять своей практической интуиции вместо того, чтобы прятаться за исчерпывающим процессом, и в результате получается документ, который кто-то действительно прочитает и начнёт применять в этом же месяце — а это, по сравнению с обстоятельным аудитом, лежащим неоткрытым на общем диске, почти всегда лучший результат.
