Исправление UX-ошибок мобильной версии сайта

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

Исправление мобильного UX начинается с воспроизведения конкретных пользовательских сценариев и анализа данных. Такой порядок помогает отличить реальный дефект от вкусового замечания и проверить, что доработка улучшила путь пользователя, а не только внешний вид страницы.

Что относится к мобильному UX

Мобильный UX — это весь опыт работы с сайтом на небольшом экране и с сенсорным вводом: читаемость, порядок блоков, навигация, формы, скорость реакции, устойчивость интерфейса при появлении клавиатуры и возможность завершить задачу одной рукой. Адаптивная вёрстка составляет только техническую основу. Рекомендации web.dev предлагают учитывать ширину viewport, гибкие сетки, размеры изображений и возможности устройства, а не подгонять страницу под несколько заранее выбранных моделей телефонов.[1]

Проверять стоит не абстрактную «мобильную версию», а основные маршруты:

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

Симптомы, по которым находят проблему

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

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

Аналитика форм в Яндекс Метрике показывает просмотры, начало взаимодействия, отправки, время работы с полями и поля, после которых посетитель покинул страницу. Данные полезны как ориентир, а отдельные ошибки затем воспроизводят вручную: отчёт не объясняет причину автоматически.[2]

Типичные UX-ошибки мобильной версии

Горизонтальная прокрутка и обрезанный контент

Чаще всего страницу расширяет фиксированная ширина таблицы, изображения, iframe, длинная строка, всплывающее окно или элемент с неверно рассчитанными отступами. Пользователь видит только часть цены, кнопки или поля. Базовая проверка включает метатег viewport, отсутствие элементов шире контейнера и корректное поведение на промежуточных ширинах, а не только на 320, 375 и 430 пикселях.[1]

Мелкие или тесно расположенные элементы

Ссылка может быть визуально заметной, но её активная область остаётся размером со строку текста. На сенсорном экране это приводит к ошибочным нажатиям. WCAG 2.2 задаёт для критерия уровня AA минимальную цель 24 × 24 CSS-пикселя либо достаточный интервал вокруг меньшей цели; для основных действий обычно разумно проектировать более крупную активную область.[3] Проверяют фактическую область нажатия, а не размер надписи внутри кнопки.

Навигация теряет контекст

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

Форма конфликтует с виртуальной клавиатурой

Поле оказывается под клавиатурой, экран масштабируется, кнопка отправки уходит за нижнюю границу, маска телефона запрещает вставку или удаляет корректные символы. Атрибут inputmode помогает браузеру показать подходящую клавиатуру, но сам по себе не проверяет формат значения.[4] Атрибуты autocomplete сообщают назначение имени, телефона, адреса и других полей и сокращают ручной ввод.[5]

У каждого поля должна быть видимая подпись, связанная с элементом управления. Placeholder может привести пример, но он исчезает после ввода и поэтому не заменяет label.

Ошибка описана слишком общо

Сообщение «Заполните обязательные поля» заставляет просматривать всю страницу. Хорошая валидация называет поле и объясняет исправление: «Укажите телефон в формате +7…» или «Выберите пункт выдачи». W3C отдельно требует, чтобы автоматически обнаруженная ошибка была идентифицирована и описана текстом; одного красного контура недостаточно.[6] После неудачной отправки фокус переводят к сводке ошибок или первому проблемному полю, сохраняя уже введённые значения.

Интерфейс реагирует с задержкой или прыгает

Кнопка без состояния загрузки провоцирует повторные отправки. Поздно появившийся баннер сдвигает форму под пальцем. Крупное изображение задерживает основной контент. Для технической оценки используют Core Web Vitals: LCP отражает скорость появления основного содержимого, INP — отзывчивость на взаимодействия, CLS — визуальную стабильность. Ориентиры «хорошего» опыта составляют LCP до 2,5 секунды, INP до 200 миллисекунд и CLS до 0,1 для 75-го перцентиля посещений.[7]

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

Попап или плавающая кнопка перекрывает задачу

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

Как провести мобильный UX-аудит

1. Зафиксировать сценарии и исходные показатели

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

2. Проверить реальные устройства и браузеры

Эмуляция в инструментах разработчика удобна для поиска переполнения и проверки сетки. Реальный смартфон нужен для виртуальной клавиатуры, жестов, системного автозаполнения, панели браузера, поворота экрана и особенностей Safari или Chrome. Набор устройств выбирают по аналитике сайта; редкие конфигурации тестируют после наиболее посещаемых.

3. Пройти сценарии с разными данными

Форму проверяют с короткими и длинными именами, вставкой номера, пустыми обязательными полями, медленным соединением, повторным нажатием и возвратом назад. Каталог — с длинными названиями, отсутствующей картинкой, нулевой ценой, вариантом товара и пустой выдачей. Это выявляет ошибки состояний, которые не видны на «идеальном» демонстрационном товаре.

4. Сопоставить наблюдения с аналитикой

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

5. Составить приоритет доработок

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

Как учитывать персональные данные в мобильной форме

Количество полей определяют целью обработки. Закон требует, чтобы состав данных соответствовал заявленной цели и не был избыточным. Согласие — одна из возможных правовых основ, но не единственная: статья 6 закона № 152-ФЗ предусматривает, в частности, обработку, необходимую для исполнения договора или его заключения по инициативе самого человека.[8]

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

Как проверить исправления после разработки

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

Сразу после выпуска контролируют технические ошибки, отправки форм и оплату. Изменение конверсии оценивают на сопоставимом трафике и периоде: один удачный день не показывает устойчивый эффект.

Критерии приёмки для разных типов страниц

Каталог и фильтры

• панель фильтров открывается и закрывается без скачка страницы;
• выбранные значения видны до применения и после возврата из карточки;
• количество найденных товаров обновляется понятным образом;
• длинные названия и диапазоны цены помещаются в контейнер;
• нулевая выдача предлагает снять конкретные ограничения.

Карточка товара или услуги

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

Форма заявки

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

Как избежать повторного появления ошибок

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

Компоненты проектируют с запасом для реального содержимого: длинного заголовка, цены со скидкой, двухстрочной кнопки, сообщения об ошибке и системного увеличения текста. Новые плавающие элементы подключают через единый слой, который знает о cookie-уведомлении, меню и нижней панели. Это надёжнее, чем исправлять z-index каждого виджета отдельно.

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

Что должно получиться

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

Источники

1. web.dev: Responsive web design basics.
2. Яндекс Метрика: аналитика форм.
3. W3C: Understanding Success Criterion 2.5.8 — Target Size (Minimum).
4. MDN: атрибут inputmode.
5. MDN: атрибут autocomplete.
6. W3C: Understanding Success Criterion 3.3.1 — Error Identification.
7. web.dev: Web Vitals.
8. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».