Адаптивная вёрстка сайта: что согласовать и как принять работу

Принимать адаптивную вёрстку нужно по поведению страницы на разных ширинах и в разных состояниях — два совпавших скриншота ещё не описывают готовую работу

Если заранее согласовать только «компьютер и телефон», спор появится на первом длинном заголовке, открытом меню или промежуточном экране — поэтому результат удобнее описать небольшой матрицей

Она не требует от заказчика знания CSS — нужно перечислить страницы, важные действия, варианты содержимого и признаки исправной работы

Что входит в адаптивную вёрстку

Адаптивная страница перестраивает представление под доступное пространство — меняются колонки, переносы, размеры изображений и расположение элементов, сохраняя содержание и доступ к действиям

MDN описывает responsive design как подход с гибкими сетками, медиа и правилами для разных условий — это полезная основа, но не готовый перечень обязательств конкретного исполнителя

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

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

Какие страницы считать разными шаблонами

Соберите список типов страниц: услуга, статья, каталог, карточка и документы, если они предусмотрены проектом — рядом запишите реальные адреса или согласованные макеты

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

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

Сгруппируйте адреса по общим шаблонам — тогда будет видно, где достаточно исправить один компонент, а где нужно проверить отдельное устройство страницы

Как договориться о ширинах и браузерах

Зафиксируйте основные размеры из макетов и диапазоны между ними — конкретные контрольные ширины выбирайте по сетке и аудитории, а не по одному списку популярных телефонов

Попросите проверить плавное изменение ширины — переход от трёх колонок к двум должен происходить до того, как карточки становятся непригодными для чтения

Браузеры и устройства перечислите отдельно — если есть данные посещений, они помогут выбрать приоритеты, а при отсутствии данных набор нужно согласовать явно

Эмуляция полезна для диапазона ширин, но реальные устройства остаются отдельной проверкой — это ограничение объясняется в документации Chrome Device Mode

Как выбрать контрольные ширины по содержимому

Начните с блока, которому теснее всего при уменьшении окна — это может быть сетка карточек, строка навигации, сравнительная таблица или группа кнопок

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

Переход к другому расположению нужен до этого момента — число в media query описывает решение для блока, а не обязательную границу между всеми телефонами и планшетами

Учебный расчёт для сетки: у карточки согласована удобная ширина 280 пикселей, между карточками 24 пикселя, боковые отступы контейнера по 32 пикселя — три колонки занимают 3 × 280 + 2 × 24 + 2 × 32 = 952 пикселя

Для этого примера команда может выбрать переход около 960 пикселей — затем проверить не только 960, но и 959, чтобы убедиться, что обе стороны границы работают

Две такие колонки с теми же отступами занимают 648 пикселей — ниже этой границы понадобится один столбец или другое согласованное решение

На самом узком экране отступы могут уменьшаться отдельно — например, при ширине 320 пикселей поля по 20 оставляют карточке 280 — это тоже часть решения, которую нужно записать

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

Как выбрать браузеры без выдуманной статистики

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

Затем согласуйте набор реальных устройств и способы дополнительной эмуляции — указание «мобильные браузеры» не объясняет, проверялся ли Safari на iPhone или только узкое окно Chrome на компьютере

Если статистики пока нет, выберите явный стартовый набор и пометьте основание как предположение — например, доступные Chrome на Android, Safari на iPhone и настольные браузеры из задания

Не подменяйте отсутствие устройства обещанием поддержки — исполнитель должен показать, что реально проверено, а что остаётся согласованным ограничением

Какие состояния часто забывают

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

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

Для интерактива запишите, что остаётся доступно без JavaScript — например, статья должна сохранять объяснение и ссылку на документ, даже если вспомогательный чек-лист не пересчитывается

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

Это учебная матрица — замените строки на фактические блоки своего проекта и добавьте конкретные адреса, устройства и ожидаемое поведение

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

Рассмотрим учебный сайт мастерской — у него есть услуга ремонта, статья с памяткой и сравнительная таблица условий — набор выбран, чтобы проверить разные типы содержимого

Для этой работы согласованы контрольные ширины 320, 412, 648, 959, 960 и 1440 пикселей — крайние точки показывают узкую и широкую подачу, а соседние значения проверяют переходы учебной сетки

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

В реальном задании добавьте к этим строкам точные адреса — иначе проверяющий может выбрать другой экземпляр страницы с более коротким текстом и не повторить нужную ситуацию

Для каждой строки удобно оставить результат, ссылку на доказательство и статус — «не проверено» отличается от «проверено, замечаний нет» и не должно превращаться в зелёную отметку

Как заполнить одну строку полностью

Объект: услуга ремонта с длинным названием — условие: Chrome на согласованном Android, вертикальная ориентация — действие: открыть меню и перейти к условиям

Ожидается: выбранный блок виден, меню закрыто, страницу можно прокручивать — наблюдается: панель закрылась, но страница осталась заблокированной

Это конкретный дефект общей навигации — в задаче нужно назвать исходное состояние и проверить после исправления обычный переход, якорь и закрытие без перехода

У такой строки есть завершение — повторный проход на опубликованной версии с зафиксированным результатом — запись «разработчик сообщил, что готово» сама по себе её не закрывает

Что делать, если мобильного макета нет

Сначала отделите решения, которые можно вывести из согласованной системы, от тех, которые меняют способ использования страницы

Перестройка обычной сетки в один столбец может следовать существующему шаблону — но превращение сложной таблицы в набор карточек меняет представление данных и требует обсуждения

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

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

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

Если содержимое ещё не готово, используйте близкий к будущему объём и структуру — идеальный короткий текст в демонстрационной карточке скрывает те проблемы, которые проявятся после реального наполнения

Как отличить дефект от нового пожелания

Дефект нарушает согласованное поведение — например, карточка перекрывает кнопку на ширине внутри принятого диапазона

Новое пожелание меняет решение — например, вместо согласованного раскрывающегося списка требуется отдельная панель с поиском и фильтрами

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

Учебная формулировка: «Таблица сравнения остаётся таблицей — на узком экране прокручивается внутри своего блока, заголовки и все значения доступны — общий контейнер страницы не расширяется»

Такое описание проверяется — фраза «сделать красиво на мобильном» оставляет слишком много разных трактовок

Как оформить результат приёмки

Как вести список замечаний

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

Не собирайте разные дефекты одной строкой «исправить мобильную вёрстку» — после частичной правки будет непонятно, что осталось и почему задача считается незавершённой

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

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

Что должно остаться в результате приёмки

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

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

Появление нового длинного названия или большого документа после запуска — повод проверить затронутую строку заново — прежняя приёмка не подтверждает любой будущий контент автоматически

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

Для повторяющегося блока запишите, какое содержимое уже использовалось в проверке — длину названия, наличие пояснения, соотношение сторон изображения, возможное отсутствие второстепенного поля

Это помогает редактору обновлять сайт — например, название услуги может занимать несколько строк, но добавление в кнопку всего описания требует отдельной проверки, потому что меняется роль элемента

У таблицы укажите, допускаются ли новые столбцы и длинные значения — иначе исправление может случайно оказаться рассчитанным только на конкретные шесть коротких подписей

У изображения зафиксируйте, допустим ли кадр с иной пропорцией и что должно оставаться видно после обрезки — автоматическое заполнение рамки не гарантирует, что важная часть фотографии сохранится

Как завершить учебную приёмку

Для версии v1 матрица сохранила проблемы сетки, таблицы и меню — после передачи версии v2 проверяющий повторяет каждую соответствующую строку, затем рабочий контрольный пример статьи

Если длинная карточка теперь помещается на 959 и 960, но таблица всё ещё обрезана, закрывается только первое замечание — общий статус «мобильный адаптив готов» пока не соответствует результатам

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

Так матрица становится основанием приёмки, а не списком галочек к макету — она показывает, какое поведение действительно подтвердили и что нужно проверить после следующего изменения

Что принять до публикации и после неё

До выпуска проверьте все согласованные шаблоны и состояния на сборке-кандидате — сохраните список замечаний, выполненных исправлений и ограничений проверки

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

Публичный замер скорости отличается от локального — на результат влияют сеть и сервер, поэтому в отчёте должны быть адрес, устройство, время и условия измерения

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

Для отдельного прохода используйте план мобильной проверки — для подготовки исходников перед работой пригодится разбор передачи макета в вёрстку

Что передать исполнителю

Соберите макеты, реальные тексты, список шаблонов и матрицу состояний — рядом укажите, какие решения уже приняты, а какие нужно предложить

На странице вёрстки KEIVO можно сверить общий состав работ — конкретный объём определяется вашим набором страниц и поведения

Скачать матрицу приёмки адаптивной вёрстки — с примером строки, полями для устройств и отдельными проверками до и после выпуска

Достаточно ли вводных для приёмки

Без интерактива проверьте эти же четыре пункта вручную — список помогает подготовить приёмку, но не тестирует сайт автоматически

Источники проверены 31 октября 2026 года — матрица и пример требований подготовлены редакцией KEIVO