Юзабилити сайта: как проверить удобство без больших исследований

Почему список замечаний не помогает переделать сайт

Как понять, что сайт неудобен, если каждому сотруднику не нравится что-то своё? Юзабилити сайта — удобство выполнения задачи: человек находит нужное, понимает условия и завершает действие без лишних затруднений. При оценке учитывают результат, усилия и удовлетворённость пользователя — эти составляющие входят в определение ISO, приведённое NIST. Разбор начинает приносить пользу, когда вместо оценки красоты появляется конкретное препятствие. Для сайта услуг ниже рассмотрим путь от прямого входа на услугу до подтверждения запроса.

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

Мнение полезно как вопрос. Причиной переделки оно становится после объяснения того, чему мешает элемент.

Юзабилити-тестирование отличается от общего обсуждения: человеку предлагают задачу и наблюдают, как он её выполняет. Экспертный аудит изучает интерфейс по выбранным критериям. Небольшая компания может начать с обоих способов в ограниченном объёме. Проектирование нового пути отдельно разобрано в статье об UX/UI-дизайне; здесь речь о поиске и исправлении препятствий на действующем сайте.

Одна задача вместо экскурсии по страницам

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

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

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

Сотрудник компании знает слишком много. Его прохождение полезно для поиска поломки, однако понятность предложения лучше обсудить с человеком, которому не объясняли устройство сайта заранее.

Участников выбирают по близости к реальной задаче: умеет ли человек покупать такую услугу и какие сведения у него обычно есть до обращения. Коллега из другого отдела может помочь на первом просмотре, если он не знает страницу, но это ограничение записывают в результате. Заодно заранее решают, как завершится тестовое обращение. Рабочий отдел получает пометку, чтобы проба не стала случайной заявкой клиента.

Подсказка скрывает место затруднения

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

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

Отсутствие действия тоже требует контекста. Человек мог отказаться из-за неподходящей цены, а мог не найти способ уточнить расчёт. Во втором случае интерфейс мешает полезному продолжению, в первом он способен вполне правильно объяснить предложение и помочь человеку отказаться. Поэтому цель исследования — понять препятствие на подходящем пути, а не заставить каждого участника оставить контакт любой ценой.

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

Это заготовка записи наблюдения. Она не сообщает о проведённом исследовании или результате конкретного сайта.

Карты Метрики подсказывают место, но не причину

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

Карта кликов Метрики показывает нажатия по всем элементам, включая те, которые не являются ссылками. Если человек нажимает на изображение, а переход спрятан в маленькой подписи, это основание изучить понятность элемента. Такое наблюдение ещё не отвечает, зачем он нажал: открыть подробности, увеличить фотографию или перейти к другой странице.

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

Карта скроллинга показывает просмотры и среднее время на участках страницы. Срок хранения её данных — 15 дней с учётом текущего дня. Результат нужного периода лучше разобрать вовремя. После долгого согласования та же карта уже может быть недоступна.

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

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

Что искать в форме и на узком экране

Форма может выглядеть исправной и оставлять человека без объяснения. Сообщение об ошибке — часть пути обращения.

Критерий WCAG 3.3.1 требует текстового описания обнаруженной ошибки ввода и указания проблемного элемента. Для маркетолога отсюда следует простой вопрос: узнает ли посетитель, какое поле мешает отправке? Одна красная рамка этого ответа не даёт. Текст полезно располагать у соответствующего поля и сохранять введённое, чтобы человек исправил недостающие сведения вместо повторного заполнения всей формы.

Область нажатия оценивают отдельно от значка. В WCAG 2.5.8 базовый размер цели составляет 24 на 24 CSS-пикселя, при этом документ перечисляет исключения и условия достаточного расстояния между небольшими целями. Для основной кнопки обращения разумнее просторное нажатие, чем попытка удержаться на нижней границе.

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

Исправлять сначала то, что прерывает задачу

Длинный список затруднений легко превращается в дорогой редизайн. Приоритет начинается с последствий для выбранного пути.

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

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

Для каждого замечания достаточно назвать задачу, наблюдаемое действие, последствие и способ повторения. Полезно отделить исправление очевидной ошибки от гипотезы об улучшении. Неработающую кнопку чинят, а изменение подачи цены испытывают после содержательного объяснения причины. При большом потоке проверку гипотез можно продолжить через A/B-тестирование, не превращая несколько наблюдений в обещание роста конверсии.

После правки путь проходят заново. Иначе исправленная подпись может скрыть новую трудность на следующем шаге.

Задание, которое можно принять повторным прохождением

Хорошее задание на исправление возвращается к действию посетителя. Из него понятно, что мешало и какой результат ждёт компания. В документ включают адрес начала, задачу человека, запись затруднения и ожидаемое продолжение. Устройство и условия входа сохраняют рядом, потому что замечание с телефона может не воспроизводиться на широком экране, а вход с главной скрывает отсутствие контекста, которое сразу заметит новый посетитель страницы услуги. Подрядчик получает предложение решения и право обсудить более простой способ. Предмет приёмки при этом остаётся прежним: человек завершает ту же задачу без объяснений сотрудника.

Повторите задачу после исправления. Отдельно отметьте, что изменилось в понимании, действиях и полученном подтверждении.

Для обращения в ШТАБ ИТ достаточно подготовить такие записи по выбранному пути и приложить примеры экранов без лишних сведений о посетителях. По ним можно оценить состав работ. Команда получит предметный разговор о содержании, интерфейсе и отправке, а не очередной круг согласования того, кажется ли сайт современным.