Собственники сайтов чаще всего теряют деньги не на вёрстке, а до неё, когда принимают макет от дизайнера на глаз, по общему впечатлению «красиво или нет». За практику я видел десятки проектов, где клиент утверждал макет за один созвон, а через полторы-две недели вёрстки выяснялось: нет мобильной версии, не прописаны состояния кнопок, а в форме заказа не хватает половины полей. Переделка на этом этапе стоит дороже, чем час внимательной проверки макета до старта, поэтому я держу под рукой фиксированный список того, как принять макет сайта у дизайнера так, чтобы вёрстка не превращалась в продолжение дизайна за счёт бюджета на разработку.
Зачем принимать макет по чеклисту, а не на глаз
Устный ответ «выглядит хорошо, давайте в разработку» ничего не фиксирует. Через месяц, когда вёрстальщик или подрядчик спросит, почему на десктопе кнопка одна, а на мобильном другая, никто не вспомнит, обсуждали это или нет. На одном проекте на Tilda клиент утвердил макет из шести блоков, но мобильную адаптацию дизайнер прислал только для трёх. Вёрстка встала на четыре дня, потому что решения по остальным блокам принимались уже во время работы, а не до неё, и это время оплачивалось отдельно от базовой сметы.
Приёмка макета по списку решает две задачи разом. Во-первых, она переносит ответственность за пробелы на этап дизайна, где исправить дешевле: подвинуть блок в Figma стоит часы, переверстать готовую страницу под новый вариант - дни. Во-вторых, письменное подтверждение становится точкой отсчёта для сметы вёрстки. Любые правки после этой даты - уже отдельная задача, а не бесплатная доработка внутри той же сметы.
Сетка, отступы и адаптивные версии в макете
Первое, что я открываю в Figma, это сетку и версии под разные экраны. Дизайнер может сдать красивый десктоп на 1440 пикселей и не потрудиться над остальным, а без адаптива вёрстка превращается в отдельное проектирование раскладки прямо на месте.
| Устройство | Типовая ширина макета | Что проверить |
|---|---|---|
| Десктоп | 1440-1920 px | Поведение контента на широких мониторах, максимальная ширина контейнера |
| Планшет | 768‑1024 px | Перестроение колонок, скрытие второстепенных блоков |
| Мобильный | 375-428 px | Порядок блоков, размер кнопок под тач, читаемость текста без зума |
Если в макете нет отдельной версии для планшета, я не считаю это критичным при условии, что дизайнер явно указал: планшет наследует мобильную сетку с увеличенными отступами. Проблема, когда про адаптив вообще ничего не сказано, и вёрстальщик додумывает пропорции сам, а потом владелец сайта удивляется, почему на телефоне всё не так, как на демонстрации в переговорке.
Типографика, цвета и графика в макете дизайнера
Шрифты - отдельная головная боль. Проверяю три вещи: название шрифта совпадает в файле макета и в лицензии (платный шрифт без прав на веб-использование заменять на аналог уже на этапе вёрстки дорого и обидно), указаны начертания для заголовков и текста отдельно, прописан межстрочный интервал, а не оставлен по умолчанию в Figma.
Второе - иконки и изображения. Прошу выгрузку в SVG для иконок и векторной графики и оригиналы фотографий в высоком разрешении, а не скриншоты из макета. Растровые картинки, вытащенные экспортом из Figma без ретина-версии, на экранах с высокой плотностью пикселей выглядят размыто, и это заметно сразу после публикации.
Третье - контраст текста и фона. Норма для основного текста - соотношение контрастности не ниже 4.5 к 1, для крупных заголовков - не ниже 3 к 1. Если дизайнер поставил серый текст на светло-сером фоне ради воздушности, я прошу проверить контраст до вёрстки, а не спорить с готовым сайтом после запуска.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Интерактивные состояния и логика элементов
Статичный макет показывает страницу в идеальном состоянии: все поля пустые и без ошибок, корзина не пустая, список заказов заполнен. В реальности пользователь вводит неправильный email, оставляет пустую корзину, а страница каталога иногда возвращает ноль товаров по фильтру. Каждое такое состояние должно быть в макете отдельным экраном или хотя бы описанием, иначе решение принимает вёрстальщик на ходу, и оно не всегда совпадает с ожиданиями владельца.
Что обязательно спрашиваю у дизайнера:
- Как выглядят кнопки в состояниях hover, active и disabled - на десктопе это заметно, а без описания вёрстальщик оставит браузерные стили по умолчанию
- Что показывается при ошибке валидации формы: текст под полем, подсветка рамки или всплывающее сообщение
- Есть ли макет пустых состояний - пустая корзина, пустой поиск, страница без результатов
- Как выглядит подтверждение отправки формы и куда уходят данные - на почту, в CRM, в Telegram через бота на aiogram, вебхуком в n8n
Последний пункт важен для интернет-магазинов и лендингов с заявками. Если форма на сайте должна триггерить сценарий в n8n или писать заказ в Telegram-бота, это стоит обсудить на этапе макета, а не после вёрстки: часто под интеграцию нужны дополнительные поля (согласие на обработку персональных данных, выбор способа доставки через СДЭК, выбор способа оплаты), и дизайнеру проще добавить их сейчас, чем вёрстальщику изобретать для них место в готовой раскладке.
Технические файлы и передача макета в разработку
Красивая картинка в Figma - это не всё, что нужно для вёрстки. Прошу доступ в режиме разработчика (Dev Mode), чтобы видеть точные отступы, размеры шрифтов в пикселях и hex-коды цветов без пересчёта на глаз. Отдельно проверяю названия слоёв и страниц: если в файле пятнадцать страниц без подписей и слои называются случайными именами вроде «Frame 47», работать с таким макетом дольше, потому что время уходит на разбор структуры, а не на код.
| Тип сайта | На что обратить внимание в макете |
|---|---|
| Лендинг на Tilda | Совместимость раскладки со стандартными блоками конструктора, ограничения Zero Block по анимациям |
| Интернет-магазин на WooCommerce | Макеты статусов заказа, страницы оплаты через T‑Bank, карточки товара с вариациями |
| Сайт на WordPress | Как будет выглядеть блог или каталог с реальными длинными заголовками, а не с демо-текстом |
| Веб-сервис или SPA | Состояния загрузки, поведение интерфейса при ошибке запроса к API |
Если по чеклисту всплывает нестандартная логика - сложные фильтры, калькулятор, интеграция с зонами доставки СДЭК, я прошу отдельную страницу с описанием сценариев, а не рассчитываю угадать логику по картинке. Доработку такой логики на Tilda оцениваю отдельно от базовой вёрстки блоков: простая правка скрипта - от 3 000 ₽, комплексная интеграция с CRM, эквайрингом или СДЭК - от 40 000 ₽. Если по итогам разбора макета ясно, что нужен не конструктор, а сайт на WordPress с собственным шаблоном, такой проект я считаю от 60 000 ₽, и в эту стоимость сразу закладываю доработанный, а не сырой макет. Если нужен именно взгляд со стороны на уже готовый макет перед наймом верстальщика, эту задачу я тоже беру в разработку и вёрстку сайтов под ключ.
Типичные ошибки при приёмке макета у дизайнера
Из практики я собрал список ошибок, которые повторяются почти в каждом втором макете:
| Ошибка в макете | Чем грозит на вёрстке |
|---|---|
| Нет версии для мобильных экранов | Верстальщик придумывает адаптив сам, результат не совпадает с ожиданиями заказчика |
| Длинные тексты заменены на короткие плейсхолдеры | Реальный контент ломает вёрстку: заголовки переносятся, кнопки растягиваются |
| Нет состояний ошибок форм | Валидация делается на глаз вёрстальщика без согласования с владельцем |
| Не выгружены исходники шрифтов и иконок | Используются похожие, но не идентичные шрифты, итоговый сайт визуально расходится с макетом |
| Нет favicon и картинки для соцсетей | Сайт запускается без иконки во вкладке и с пустой превью-картинкой при шаринге ссылки |
Отдельно слежу за юридическими страницами - политика конфиденциальности, согласие на обработку персональных данных, публичная оферта для интернет-магазина. Дизайнеры часто оставляют для них минимальный шаблон текста, а верстальщик копирует эту заглушку на сайт как есть. Уточняю заранее, что это временный текст и его заменит юрист или сам заказчик до запуска.
Когда подписывать макет и что фиксировать перед стартом
Я фиксирую утверждение макета письменно, даже если это просто сообщение в переписке: макет проекта, версия и дата, ссылка на файл, принят без замечаний. Эта дата становится границей: всё, что обсуждалось до неё, входит в стоимость вёрстки по смете, всё, что появляется после, это новая задача с отдельной оценкой по времени. Без такой границы правки накапливаются бесконечно, а спор о том, кто и что обещал на словах, решить уже нельзя.
Второй момент - у кого остаётся исходный файл макета. Если дизайнер работал по разовому договору, пропишите в переписке или договоре, что финальная версия файла с доступом для разработчика передаётся заказчику вместе с остальными материалами проекта. Иначе через полгода, когда понадобится доработать раздел сайта, макета может не оказаться под рукой вообще.
Частые вопросы
Сколько времени в среднем уходит на полную приёмку макета?
На лендинг из 5-7 блоков у меня уходит 40-60 минут: проход по чеклисту сетки, типографики, состояний и экспортов. Многостраничный интернет-магазин с личным кабинетом и оплатой требует 2-3 часа, потому что нужно проверить связки между страницами - переходы из каталога в карточку товара, из корзины в оформление заказа.
Что делать, если дизайнер не сделал мобильную версию макета?
Не подписывать приёмку до её появления. Если сроки поджимают, а мобильная версия правда не критична для проекта (например, B2B-сайт с трафиком почти полностью с десктопа), фиксируйте это отдельным пунктом в переписке: мобильная адаптация делается вёрстальщиком по общим правилам без согласования макета, чтобы результат не стал сюрпризом.
Нужно ли утверждать макет официально, если работаю с дизайнером по устной договорённости?
Да, хотя бы перепиской в мессенджере или письмом на почту. Устное согласие ничего не доказывает через месяц, когда возникнет спор о том, что именно было в макете на момент утверждения. Достаточно одного сообщения со ссылкой на файл, датой и словом «принято».
Кто оплачивает изменения макета, которые вылезли уже во время вёрстки?
Зависит от причины. Если правка связана с тем, что макет не учитывал реальный контент или сценарий, а это должно было быть проверено на этапе приёмки, расходы обычно ложатся на бюджет заказчика как доработка сверх сметы. Если проблему создал сам верстальщик, неверно истолковав макет, это его зона ответственности и его время. Поэтому чем подробнее чеклист на входе, тем меньше споров о том, чья это правка.