Нужны ли отдельные макеты сайта для телефона, планшета и компьютера?

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

До начала работ важно договориться, что означает «адаптивный сайт»: какие экраны проектируются в дизайне, что меняется на узком экране, кто проверяет мобильную версию и какие состояния считаются принятыми. Иначе заказчик ожидает отдельную отрисовку каждой модели смартфона, а разработчик закладывает только автоматическое сжатие блоков. Это разные объёмы работы и разный результат.

Что именно называют макетом для разных устройств

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

В проекте обычно различают три уровня:

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

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

Нужно ли рисовать отдельный планшетный вариант

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

Отдельное состояние стоит спроектировать, если на промежуточном экране появляется самостоятельная логика. Так бывает, когда:

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

Решение принимают по контенту и задаче, а не по названию устройства. У двух планшетов может быть разная ширина окна; кроме того, браузер часто работает в split-screen. Сайт должен оставаться пригодным и за пределами одной выбранной модели.

Как определить, какие экраны действительно нужно проектировать

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

1. Выберите типовые шаблоны страниц. Не нужно независимо проектировать двадцать похожих страниц, если у них одна структура. Достаточно определить уникальные типы: главная, категория, карточка товара, услуга, форма, корзина.
2. Опишите ключевые сценарии. Запишите, что пользователь делает на большом экране и на телефоне. Например: открыть каталог, отфильтровать товары, посмотреть наличие, положить товар в корзину.
3. Найдите места, где сценарий меняется. Навигация может свернуться, фильтр — открываться по кнопке, таблица — перестраиваться, а форма — показывать ошибки рядом с полями.
4. Назначьте контрольные ширины. Зафиксируйте в дизайн-системе точки, где меняется компоновка. Это рабочие размеры для проверки, а не перечень поддерживаемых телефонов.
5. Проговорите исключения. Для широких сравнительных таблиц или интерактивных схем может быть допустима горизонтальная прокрутка. Для обычного текста и основных кнопок она чаще всего означает, что макет требует доработки.

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

Чем адаптивная верстка отличается от «уменьшенной версии»

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

В адаптивном интерфейсе проверяют:

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

Содержание при этом не следует автоматически удалять только потому, что экран стал меньше. В рекомендациях Google по mobile-first indexing сказано, что для индексирования используется мобильная версия содержимого; важно сохранять на ней основной контент и понятные заголовки. Это особенно важно, если на большом экране в карточке товара показаны характеристики, описание или важные условия, а на телефоне их спрятали или вовсе убрали. Справка Google также рекомендует адаптивный дизайн как один из более простых в поддержке вариантов. Официальные рекомендации Google для мобильных версий.

Пример: как меняется карточка интернет-магазина

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

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

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

Что включить в техническое задание и приёмку

Чтобы не спорить после сдачи, заранее запишите ожидаемое поведение, а не только слова «адаптивный дизайн». В ТЗ можно включить такую матрицу:

В приёмке следует проверять не один URL и не только главную страницу. Для каждого шаблона возьмите обычный и крайний сценарий. В магазине это могут быть категория с фильтрами и карточка со сложным выбором; на сайте услуг — длинная страница с формой; в веб-приложении — рабочая таблица.

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

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

Типовые проблемы, которые стоит искать:

• Слишком плотные элементы. Текстовые ссылки, переключатели и иконки стоят так близко, что человек промахивается пальцем. Увеличить нужно не только саму иконку, но и область нажатия.
• Главное действие потерялось. На широком экране кнопка заметна рядом с заголовком, а на телефоне уехала ниже нескольких экранов или спряталась между второстепенными ссылками.
• Липкая шапка закрывает содержание. Меню или панель покупки закреплена сверху, но занимает слишком много высоты; после перехода к якорю заголовок оказывается под ней.
• Форма не дружит с клавиатурой. При вводе телефонного номера кнопка отправки закрыта клавиатурой, поле не видно, а сообщение об ошибке расположено далеко от него.
• Сложные данные теряют смысл. Таблица перестраивается в карточки, но заголовки столбцов исчезают, и становится непонятно, к какому параметру относится значение.
• Пользователю предлагают скачать документ без альтернативы. На небольшом экране длинный PDF или таблица может быть неудобна; краткое резюме и понятный файл помогают быстрее решить задачу.

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

Как проверять адаптивность после выпуска

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

1. Откройте главную страницу, раздел услуги, контактную форму, а для магазина — категорию, карточку, корзину и оформление заказа.
2. Проверьте узкую ширину, промежуточное окно и широкий экран; при возможности используйте реальные устройства разных платформ.
3. Пройдите сценарий с клавиатурой и касанием: открытие меню, заполнение формы, выбор варианта, фильтрация, добавление товара и возврат назад.
4. Посмотрите на длинные названия, пустые поля, ошибки, загрузку, отсутствие результатов и состояние после успешной отправки.
5. Проверьте контраст, читаемость, подписи кнопок и доступность интерактивных элементов с клавиатуры, если это важно для аудитории проекта.

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

Как согласовать объём до начала разработки

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

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

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

Как проходит адаптация в проекте

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

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

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

«Дизайн уникальный, верстка адаптивная, программирование и базовое заполнение».

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

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

Кирилл Перфильев
Разработка сайтов и интернет-магазинов, SEO и интернет-реклама