Хороший дизайн сайта помогает клиенту понять предложение, найти нужные условия и сделать следующий шаг. Оценить это можно через конкретные задачи: что человек понял, где искал ответ, на каком действии остановился. Такая проверка даёт владельцу предметный разговор с дизайнером, даже если сам владелец не разбирается в композиции и шрифтах.
Подготовьте сценарий, а не голосование за красивый вариант
Выберите важный для бизнеса путь: например, посетитель ищет услугу, проверяет, подходит ли она ему, и собирается отправить запрос. Начните с той страницы, на которую он действительно может попасть: главной, страницы услуги или товара. Проверка только главной пропустит проблемы других входов.
Для работы нужны содержательные тексты, реальные условия и названия разделов. По макету с «Заголовком» и одинаковыми короткими абзацами трудно оценить, понятен ли продукт и помещается ли важная информация. Если часть содержания ещё не согласована, запишите, какие выводы придётся проверить позже.
Заранее определите результат каждой задачи. Например: человек нашёл ограничение услуги, объяснил его своими словами и выбрал подходящий способ обращения. Критерий «страница выглядит современно» такого результата не задаёт.
Шесть задач для проверки глазами клиента
Формулировки ниже — учебные примеры. Замените услугу и условия своими; не добавляйте в задание название нужной кнопки или раздела.
1. Объяснить, что здесь предлагают
Покажите страницу человеку, который не знаком с проектом, и попросите рассказать: «Что здесь можно получить? Для кого это предложение? Что вы сделали бы дальше, если бы оно вам подошло?» Дайте посмотреть страницу в обычном темпе, без обязательного секундомера.
Запишите ответ до собственного объяснения. Если человек принял услугу за продажу оборудования или понял «бесплатную консультацию» как бесплатное выполнение работы, найдите текст и оформление, которые создали это ожидание. Неясность может возникнуть из-за заголовка, иллюстрации или соседних обещаний — одной перестановкой кнопки её не всегда исправить.
Если проблема в составе и порядке информации на одностраничном сайте, пригодится разбор структуры лендинга.
2. Найти условие, которое влияет на решение
Дайте задачу: «Вы выбираете эту услугу для своей ситуации. Выясните, подходит ли она вам и что потребуется до начала работы». Выберите одно действительно важное условие: регион обслуживания, ограничения продукта, состав комплектации или порядок оценки.
Наблюдайте, замечает ли человек это условие и связывает ли его с нужным предложением. Так проверяется визуальная иерархия: что оформление выделяет, что группирует, а что делает почти незаметным. Большая декоративная фраза может отвлекать от существенного ограничения; несколько одинаково ярких кнопок — затруднять выбор следующего шага.
Если условия вообще нет в содержании, сначала нужно уточнить и добавить его. Нельзя исправить отсутствие информации размером шрифта.
3. Найти нужный раздел и вернуться
Попросите найти конкретную услугу или товар, затем сведения, необходимые перед обращением, и вернуться к выбранному предложению. Начните с разных входных страниц, если это обычный путь клиентов.
Записывайте, какие названия меню человек выбирает, что ожидает увидеть после перехода и как понимает своё текущее положение. Повторные переходы между неподходящими разделами — повод проверить названия и группировку. Сама по себе длинная последовательность переходов ещё не доказывает проблему: важно, мог ли человек уверенно решить задачу.
На макете попросите показать ожидаемый путь. В прототипе или на сайте проверьте реальные переходы, возврат, открытие и закрытие меню. Объяснение дизайнера «здесь потом будет ссылка» оставьте как непроверенную часть сценария.
4. Прочитать важный фрагмент и понять действие
Выберите описание условия, подпись поля или текст рядом с кнопкой. Попросите прочитать и объяснить смысл, а перед нажатием — предположить, что произойдёт. «Продолжить» может означать переход, отправку заявки или начало оплаты; ожидание должно совпадать с действием.
Проверяйте текст в размере, близком к реальному отображению. В Figma надпись может казаться удобной при увеличенном масштабе; это не подтверждает читаемость страницы в браузере. Отдельно посмотрите на слабоконтрастные подписи, текст поверх изображения и длинные абзацы без смысловых опор. Контраст стоит измерить — порядок проверки приведён ниже.
5. Исправить ошибку и понять результат
В тестовом интерфейсе попросите оставить обязательное поле пустым или ввести значение неподходящего формата, затем исправить ошибку. Человек должен понять, какое поле требует внимания, что изменить и удалось ли продолжить. Для сценариев отправки используйте согласованную тестовую среду, где обращение не уйдёт в рабочую обработку.
Одна цветная рамка вокруг поля не объясняет ошибку. Для автоматически обнаруженной ошибки ввода WCAG требует указать проблемный элемент и описать ошибку текстом; цвет может дополнять сообщение. Это следует из критериев 3.3.1 — идентификация ошибок и 1.4.1 — использование цвета.
Попросите команду показать также состояние ожидания, успешного завершения и сбоя отправки. Посетителю нужно различать «данные отправляются», «обращение принято» и «попытка не удалась». На статичных макетах можно оценить эти сообщения, но их появление и сохранение введённых данных проверяются в работающем интерфейсе.
6. Повторить главный путь на телефоне
Возьмите реальный телефон и повторите выбор предложения, поиск важного условия и переход к обращению. Проверьте, не исчезла ли нужная информация после перестроения страницы, удобно ли открывать меню и не перекрывает ли экранная клавиатура поле или действие. Разумная проверка касается завершения задачи, а не только того, поместилась ли страница по ширине.
Мобильный макет показывает предусмотренную компоновку. Работа касаний, клавиатуры и открытых состояний требует прототипа или сайта. Более подробная проверка устройств и адаптивности разобрана в статье о сайте на мобильных экранах.
Доступность: что владелец может проверить по WCAG
Ниже — несколько практических ориентиров из WCAG 2.2, а не полный аудит стандарта. Положительный результат этих проверок не позволяет заявить соответствие WCAG. W3C отдельно предупреждает, что первичная проверка доступности может пропустить существенные барьеры.
Контраст текста и элементов
Для обычного текста критерий 1.4.3 уровня AA устанавливает контраст с фоном не ниже 4,5:1, для крупного — 3:1. В определении WCAG крупный текст начинается от 18 pt обычного начертания или 14 pt жирного; название «заголовок» само по себе не даёт права использовать меньший контраст.
Попросите дизайнера или разработчика показать измерение для текста, подписей полей и сообщений, включая текст на фотографиях. Измерять следует заданные цвета текста и фактического фона, а не случайный сглаженный пиксель буквы на скриншоте. Если фон неоднородный, одной удобной пары цветов недостаточно.
Для визуальных признаков, необходимых, чтобы распознать доступный для действия элемент управления или его состояние, критерий 1.4.11 задаёт контраст не ниже 3:1 с соседним цветом. Например, это может быть граница поля или нарисованный сайтом индикатор фокуса. Этот критерий не требует обязательной контрастной рамки для любой кнопки; важно, какая визуальная информация нужна, чтобы распознать элемент и его состояние.
Увеличение и перестроение страницы
Увеличьте страницу в браузере до 200% и проверьте важный путь, в том числе промежуточные масштабы: остаются ли видимыми текст, подсказки и действия. Критерий 1.4.4 «Изменение размера текста» требует возможности увеличить текст до 200% без потери содержания и функциональности, с исключениями для субтитров и изображений текста.
Отдельно проверьте перестроение при ширине области страницы 320 CSS-пикселей. Для исходной области шириной 1280 CSS-пикселей это соответствует масштабу 400%. Обычный вертикальный текст должен читаться без необходимости прокручивать страницу ещё и по горизонтали. Для объектов, которым по смыслу нужна двумерная компоновка, например некоторых таблиц или карт, есть исключения. Эти условия относятся к критерию 1.4.10 «Перестроение», а не к увеличению картинки макета.
Клавиатура и видимый фокус
На работающем сайте уберите мышь и пройдите основной путь с клавиатуры: Tab и Shift+Tab для переходов, Enter для ссылок, соответствующие клавиши для кнопок и меню. Если браузер ограничивает переход по ссылкам, сначала включите полный клавиатурный доступ в его настройках.
Проверяйте три вещи:
- Можно ли выполнить нужные действия с клавиатуры. Это относится к критерию 2.1.1.
- Видно ли, какой элемент сейчас выбран для действия. Его визуальная отметка называется индикатором фокуса; видимость описывает критерий 2.4.7.
- Можно ли покинуть меню, окно или поле, продолжив работу с клавиатуры. Отсутствие такой возможности может быть клавиатурной ловушкой; её исключает критерий 2.1.2.
Проверьте также закреплённую шапку, баннеры и плавающие панели: они могут закрывать выбранный элемент. Минимальное требование 2.4.11 уровня AA — элемент с клавиатурным фокусом не должен быть полностью скрыт содержимым, созданным сайтом. Для удобства полезно видеть его целиком, но это более строгая цель, чем указанный минимум.
Что доказывает макет, а что нужно проверять на сайте
| Материал | Что можно оценить | Что остаётся непроверенным |
|---|---|---|
| Статичный макет с готовым содержанием | Понятность предложения, порядок блоков, предусмотренные цвета и сообщения | Реальные переходы, клавиатура, увеличение, работа ошибок и отправки |
| Кликабельный прототип | Ожидаемый путь и понимание переходов в предусмотренных сценариях | Поведение готового сайта вне возможностей прототипа, серверные ошибки, доступность реализации |
| Работающий сайт | Реальные действия и состояния в проверенных условиях | Непроверенные страницы, устройства, сценарии и способы доступа |
На макете можно потребовать отдельные состояния фокуса и ошибки. Наличие этих экранов подтверждает проектное решение; его корректное выполнение выясняется после разработки. Поэтому при согласовании дизайна сайта полезно отдельно зафиксировать, что проверено сейчас и что войдёт в приёмку работающего интерфейса.
Как провести небольшую проверку с людьми
Пригласите людей, похожих на предполагаемых клиентов по задаче и знанию продукта. Коллега, который участвовал в разработке, уже знает ответы и не заменяет нового посетителя. Если среди аудитории есть люди, использующие вспомогательные технологии, учитывайте их способы работы; самостоятельная попытка владельца воспользоваться экранным диктором не заменяет их опыт.
Давайте задачи по одной, без подсказки маршрута. Просите человека проговаривать ожидания и наблюдайте. Если пришлось помочь, отметьте место и содержание помощи: дальнейшее успешное действие уже произошло с подсказкой. Нейтральные задания и наблюдение за действиями описаны в руководстве GOV.UK по проверке удобства.
У такой проверки нет универсального числа участников, которое автоматически делает вывод доказанным. Её результат — наблюдения по определённым людям, задачам и версии интерфейса. Повторяющееся затруднение помогает выбрать проблему для исправления; отсутствие затруднений в этих встречах не доказывает, что их не будет у остальных клиентов. Не переводите результаты небольшой проверки в проценты всей аудитории или обещания роста продаж. Если решение требует надёжного сравнения вариантов, нужен исследовательский план под конкретный вопрос. W3C также предупреждает об ограниченности выводов из небольших проверок с пользователями.
Как описать дефект и отличить его от пожелания
«Мне не нравится синий» — предпочтение. «На странице услуги посетитель искал условия в меню, потому что их блок не распознал» — наблюдение. «Измеренный контраст подписи ниже применимого порога» — проверяемая проблема. Предпочтения могут быть основанием для согласованного фирменного решения, но не подтверждают неудобство для клиента.
Передайте команде одну запись на проблему: страница и состояние → задача → ожидаемый результат → фактическое поведение → последствия. Добавьте снимок экрана или короткую запись, устройство, браузер и масштаб, если они влияют на воспроизведение. Предложенный способ исправления храните отдельно от описания проблемы.
Учебный пример: «В тестовой форме на странице услуги после отправки без телефона появляется только цветная рамка. Участник не понял, что требуется заполнить, и не продолжил. Ожидаем: понятное сообщение, указывающее поле и причину ошибки». Здесь команда может проверить дефект и предложить решение. Пожелание «сделать ошибки ярче» этого не объясняет.
Сначала разбирайте блокировки важного действия и неверные ожидания, затем затруднения, после которых человек смог продолжить, и отдельно — вопросы визуального вкуса. Для исправленной версии повторите затронутую задачу. Если вопрос уже в масштабе изменений существующего сайта, граница между отдельными исправлениями и редизайном разобрана в материале о необходимости редизайна.
