Как проверить качество вёрстки сайта: чек-лист для приёмки

01

Приёмка начинается со сценария, а не со скриншота

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

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

В типовой практике ICONICA макет может быть визуально принят за один день, но при проверке живого контента обнаруживаются длинные названия услуг, незаполненные изображения, ошибки валидации и перекрытия на ширине 320 px. Поэтому результат приёмки — не комментарий «похоже на дизайн», а список воспроизводимых дефектов с URL, устройством, шагами и ожидаемым поведением.

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

03

Сверьте макет, но не принимайте пиксели без контекста

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

Не ограничивайтесь главной. Возьмите по одной странице каждого шаблона: услуга, статья, каталог, карточка, поиск, контакты, страница 404 и форма. На сайтах на 1С-Битрикс внешний шаблон может выглядеть одинаково, но подключённые компоненты выводят разные классы, изображения и длину полей. Из-за этого ошибка проявляется только на конкретном типе страницы.

Используйте реальные или намеренно «неудобные» данные: название в 80–100 символов, цену с копейками, три строки преимуществ, пустое изображение, ссылку с длинным анкором. Так проверяется устойчивость шаблона, а не удачный демо-набор.

04

Проверьте адаптивность на контенте и в мобильном меню

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

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

Тестируйте не только эмулятор браузера, но и хотя бы один реальный iOS- и Android-смартфон. Встроенные браузеры, масштабирование текста и системная клавиатура часто показывают проблемы, которых нет в desktop DevTools.

05

Формы и состояния интерфейса: место, где теряются обращения

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

У каждого элемента должны быть понятные состояния: обычное, наведение, фокус с клавиатуры, заполненное поле, ошибка, отправка и успешный ответ. Сообщение об ошибке размещают рядом с конкретным полем и формулируют действие: «Введите телефон в формате +7 999 123-45-67», а не «Ошибка 400». Если кнопку блокируют на время отправки, пользователь должен видеть, что запрос выполняется.

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

06

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

Часть ошибок невозможно увидеть мышью и быстрым интернетом. Нажмите Tab с первого элемента страницы и пройдите шапку, меню, ссылки, форму и футер. Фокус должен быть видимым, а порядок переходов — логичным. В открытом модальном окне он не должен уходить на элементы фона; после закрытия обязан вернуться к кнопке, которая открыла окно. Это одновременно проверка доступности и практическая проверка качества интерфейса.

Затем посмотрите вкладку Network в инструментах разработчика. Ошибки 404 у шрифтов, изображений, CSS или JavaScript нередко маскируются кешем разработчика. На чистой загрузке они дают скачки вёрстки, невидимые иконки, работающий через раз слайдер или долгую загрузку первого экрана. Для публичного сайта это влияет и на конверсию, и на SEO.

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

1. 1

   Откройте чистую сессию. Используйте инкогнито, чтобы исключить авторизацию, кеш и расширения браузера.

2. 2

   Пройдите Tab-навигацию. Убедитесь, что фокус виден на ссылках, кнопках, полях и элементах меню.

3. 3

   Замедлите сеть. Проверьте, не прыгают ли блоки и доступна ли кнопка до загрузки всех ресурсов.

4. 4

   Посмотрите ошибки. В Console и Network не должно быть необъяснённых 404 и ошибок JavaScript.

5. 5

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

08

Как оформить замечания, чтобы их исправили без споров

Фраза «на мобильном всё съехало» редко приводит к быстрой правке. Разработчику нужно воспроизвести проблему, а руководителю — оценить приоритет. Каждое замечание оформляйте отдельной строкой: URL, устройство или браузер, ширина экрана, шаги, фактический результат, ожидаемый результат и вложение. Скриншот полезен, но не заменяет описание: по нему не всегда понятно, как была открыта страница и что делал пользователь.

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

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

09

Когда вёрстку можно считать принятой

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

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

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