Проверить мобильный сайт: путь, который проходит посетитель

На широком мониторе страница может выглядеть готовой, а на телефоне посетитель не найдёт кнопку или не сможет отправить форму. Проверить мобильный сайт означает пройти задачу человека на узком экране. На сайте «Гутман Групп» это поиск направления и контакта; у «Православной Трапезы» выбор товара и корзина; у «Лёд и Пламя» выбор процедуры. Ниже порядок проверки, который я применяю после сборки интерфейса с ИИ.

Выберите один маршрут вместо осмотра всех блоков

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

У магазина на узком экране первым должно быть понятно, как дойти до товаров за фотографией. У СПА нужно пройти от выбора направления к конкретной услуге и записи.

Проверьте, что первый экран объясняет место

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

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

На первом экране выполните короткую проверку:

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

Нажмите каждую кнопку маршрута

Кнопка может быть видимой, но слишком маленькой для пальца, находиться под плавающим виджетом или открывать неверный адрес. На каждом шаге маршрута нажмите её рукой, без точного наведения мышью. Меню должно раскрыться и закрыться; ссылка на раздел должна вести в нужное место; действие «Позвонить» должно вызвать набор номера. Если кнопка предлагает запись, после неё должен начаться именно путь записи или честно обозначенная заявка на обратную связь.

На странице «Гутман Групп» две основные кнопки ведут к расчёту и портфолио. Для теста важно проверить обе, потому что разные посетители входят с разным намерением. В магазине количество товара управляется кнопками «+» и «−». С телефона они должны обновлять состав корзины, не закрывая её случайно. Для СПА название выбранной услуги должно сохраниться после нажатия записи.

Форму проверяйте реальной отправкой

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

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

Как использовать ИИ для исправления конкретного дефекта

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

Перед правкой посмотрите структуру проекта и кто использует компонент. Для Next.js и React это можно сделать поиском имени. После исправления проверьте diff и сборку. Эти команды показывают изменённые файлы и технические ошибки; реальный телефон остаётся обязательной частью приёмки. Если сайт на другом стеке, подставьте его команду сборки. При публикации русского сайта проверьте также шрифты и внешние подключения: зависимость от недоступного домена может задержать первый экран на мобильной сети.

rg -n 'ИмяКомпонента' app components lib
git diff --check
npm run build

Составьте короткий список дефектов с доказательством

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

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

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

Частые вопросы

Достаточно ли режима телефона в инструментах разработчика?

Он полезен для поиска размеров и переполнения, но на реальном телефоне иначе ощущаются касание, клавиатура и плавающие элементы. Финальный маршрут пройдите на устройстве.

Что проверять раньше: дизайн или форму?

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

Нужно ли тестировать каждую страницу сайта?

Начните с основных маршрутов и всех разных шаблонов. Затем проверьте страницы с длинными названиями, таблицами и необычными блоками: они чаще ломают сетку.

Как объяснить агенту мобильную ошибку?

Назовите страницу, узкий размер, действие и видимый сбой. Попросите проверить все места, использующие тот же компонент, и повторите путь после правки.

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