Как подготовить макет к вёрстке

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

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

Сначала договоритесь о результате

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

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

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

Покажите, как страница меняется на телефоне

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

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

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

CSS media queries позволяют менять оформление в зависимости от условий просмотра. Но сам факт существования такого инструмента не определяет, как должна перестраиваться именно ваша страница. Это решение стоит описать в макете и обсудить с разработчиком. Основы media queries в MDN.

Нарисуйте состояния, а не только идеальный экран

Для каждого интерактивного элемента ответьте на вопрос: «Что происходит до действия, во время него и после?» У кнопки могут быть обычное состояние, фокус с клавиатуры и временная недоступность во время отправки. У формы — пустые поля, заполненные поля, объяснение ошибки и подтверждённый результат.

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

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

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

Соберите повторяющиеся элементы в систему

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

Отдельно проверьте стили текста, используемые цвета и кнопки. Один и тот же заголовок по смыслу может выглядеть по-разному в карточке и в статье. Поэтому названия стилей должны объяснять роль, а не только размер. «Заголовок карточки» обычно понятнее, чем ещё один «Text 24».

В Figma auto layout помогает описывать размещение элементов и их поведение при изменении содержимого. Он полезен, когда текст становится длиннее или к списку добавляется новый пункт. Но наличие auto layout ещё не означает, что все правила будущей веб-страницы определены. Руководство Figma по auto layout.

Хорошая передача макета уменьшает количество догадок. Она не запрещает вопросы — она делает их конкретными.

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

Подготовьте тексты, изображения и правила поведения

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

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

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

Договоритесь, как принимать готовую страницу

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

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

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

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

Проверьте свой макет

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

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

Главное перед передачей

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

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

Источники и примечания

Материал подготовлен редакцией KEIVO. Примеры интерфейсов учебные; это не клиентский кейс и не автоматическая оценка вашего макета.

• MDN: media queries — техническая основа адаптивных правил.
• MDN: проверка форм — различие клиентской и серверной проверки.
• Figma: auto layout — инструмент компоновки; процесс передачи в статье предложен редакцией, а не приписан Figma.