# Как заказать вёрстку сайта по макету и принять результат

Как выбрать исполнителя вёрстки, подготовить вводные, сравнить предложения и договориться о проверке и передаче готовой работы

Автор: Редакция KEIVO
Дата публикации: 2026-10-29
Обновлено: 2026-10-29
Канонический URL: https://keivo.ru/blog/kak-zakazat-verstku-po-maketu/

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



Выбор исполнителя часто начинается с портфолио и вопроса о цене

Но даже подходящие работы не покажут, кто подготовит недостающие состояния, подключит форму и исправит замечания после передачи

В этом материале собран порядок обсуждения заказа — что отправить, что спросить и как понять, одинаковый ли результат предлагают разные исполнители

## Сформулируйте результат своими словами

Опишите страницу, её задачу и то, что должно работать после завершения

Например: «Нужна адаптивная страница услуги по утверждённому макету, с меню, раскрывающимися ответами и ссылкой на документ — размещение выполняет наш разработчик»

Если нужна форма, укажите способ получения обращения и ответственного за обработку — это уже другая цепочка проверки

Так в предложении будет видно, что делает исполнитель и какие материалы он ждёт от вас

О разнице между интерфейсом и полной системой можно прочитать в [объяснении состава услуги вёрстки](/blog/chto-vhodit-v-uslugu-verstki/)


![Генеративная иллюстрация согласования работы: два человека обсуждают веб-макет и компоненты на экране](/blog/_media/p1-20261029/a15-cover-c082408e4ec0.webp)

Генеративная иллюстрация KEIVO — вымышленные интерфейсы, не клиентский проект



## Подготовьте один комплект вводных

Отправляйте исполнителям одну актуальную версию материалов — иначе ответы будут относиться к разным задачам

- Ссылка на макет и перечень страниц или шаблонов
- Мобильные варианты и известные правила адаптации
- Реальные тексты, изображения, шрифты и файлы
- Список действий и важных состояний
- Действующая система управления и необходимые подключения
- Формат передачи и ответственный за публикацию
- Ограничения по сроку или бюджету, если они уже есть

Если что-то неизвестно, пометьте это отдельно — исполнитель сможет предложить проверку или обозначить условие оценки

Пароли и ключи не нужны в общем брифе — доступы передают через подходящий механизм после согласования роли и объёма

Проверка самого файла дизайна вынесена в [статью о подготовке макета](/blog/podgotovit-maket-k-verstke/), чтобы не смешивать её с выбором исполнителя

## Как смотреть портфолио

Попросите объяснить роль исполнителя в приведённом примере — он мог отвечать за дизайн, отдельный компонент, вёрстку или весь запуск

Если есть доступный работающий сайт, посмотрите не только первый экран — откройте меню, измените ширину окна и пройдите несколько действий

Содержание чужого проекта не обязано совпадать с вашим — ищите опыт работы с похожей структурой и поведением, а не одинаковую отраслевую фотографию

### Что спросить о примере




| Вопрос | Что помогает понять ответ |
|---|---|
| Что именно вы делали | Где проходила ответственность исполнителя |
| Какие ограничения были у макета | Как он решает вопросы до и во время реализации |
| Как проверяли разные экраны | Есть ли понятный способ приёмки адаптива |
| Что передали заказчику | Соответствует ли формат вашему следующему шагу |
| Кто занимался подключениями | Не приписываются ли исполнителю чужие части работы |


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



| Вопрос заказчика | Ответ, после которого нужна конкретика | Ответ, по которому можно продолжить работу |
|---|---|---|
| Как таблица будет выглядеть на телефоне? | «Сделаем адаптивно» | «В мобильном макете таблицы нет — предложу карточки или горизонтальную прокрутку, выберем вариант до вёрстки» |
| Сотрудник сможет менять подписи сам? | «Да, всё можно менять» | «Сейчас в задаче статическая страница — для редактора нужны CMS и перечень редактируемых полей» |
| Что получим при завершении? | «Полностью готовый сайт» | «Передам исходники и сборку, размещение выполняет ваш разработчик — ему заранее нужны требования к хостингу» |


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



- Одинаковые вводные Одна версия макета, содержания и списка действий

- Понятный состав Что входит, что отдельно и что выполняете вы

- Проверка результата Тестовая версия и согласованные сценарии приёмки

- Дальнейшие изменения Как сообщать об ошибках и согласовывать новые задачи


Схема KEIVO — порядок сопоставления предложений





Разницу в цене имеет смысл обсуждать после уточнения состава — предложение только на код нельзя напрямую сравнивать с предложением, которое включает установку и проверку подключения

Разовые и регулярные расходы тоже стоит разделить — подробный пример есть в [статье о стоимости вёрстки](/blog/stoimost-verstki-sayta/)

Попросите назвать открытые вопросы и способ их закрытия — неизвестное условие лучше увидеть до работы, чем считать его незаметно включённым

## Что зафиксировать перед началом

Сохраните перечень результатов, исключений, ответственных и порядок согласования

Для каждого этапа должно быть понятно, что вы смотрите и каким способом сообщаете замечания

Назначьте одного человека, который собирает согласованные комментарии со стороны заказчика — противоречащие указания разных участников сначала требуют решения внутри команды

Полезно посмотреть одну собранную страницу до завершения всего набора — так можно заметить повторяющуюся ошибку, пока она не появилась во всех шаблонах

Проверки доступности тоже нужны в процессе работы — такой подход описан в [руководстве W3C по планированию](https://www.w3.org/WAI/planning-and-managing/)

## Как принять готовую вёрстку

Проверяйте тестовую версию в браузере с теми текстами и изображениями, которые будут опубликованы — изображение страницы не покажет, куда ведут ссылки и что перекрывает открытое меню

Начните с одного полного пути посетителя: открыть услугу, найти условие, перейти к действию и увидеть результат — затем повторите его на телефоне

### Как записать замечание, которое можно воспроизвести

Предположим, на телефоне вы открыли меню, выбрали «Условия», но меню осталось поверх текста — это учебная ситуация, по которой можно заполнить карточку ошибки




| Поле | Пример записи |
|---|---|
| Где | Страница услуги, мобильное меню, браузер и модель телефона указываются в реальном отчёте |
| Действие | Открыть меню и нажать «Условия» |
| Ожидалось | Меню закрылось, заголовок условий и текст доступны |
| Получилось | Страница прокрутилась, но меню осталось поверх текста |
| Что приложить | Короткая запись действия или скриншот с открытым меню |
| Как перепроверить | Повторить те же действия на исправленной версии и проверить остальные пункты меню |




Фраза «на телефоне всё съехало» не даёт исполнителю такого маршрута — он может открыть другую ширину или состояние и не увидеть проблему

Если ссылка ведёт на другой документ, приложите ожидаемый файл — если форма входит в заказ, кроме сообщения на экране проверьте тестовое обращение у получателя

### Ошибка или новая задача

Меню, перекрывающее текст вопреки принятому макету, — замечание к реализации — просьба добавить поиск, которого не было в задании, меняет состав работы

В спорном случае откройте сохранённый макет и перечень действий — сначала установите, что было принято, затем обсуждайте способ исправления или оценку дополнения

После правки отметьте результат рядом с исходным замечанием — сохраняйте незакрытые вопросы отдельно, чтобы сообщение «готово» не потеряло их в переписке

Предварительные проверки доступности помогают найти часть проблем, но не заменяют полную оценку — границы такого подхода описаны в [W3C Easy Checks](https://www.w3.org/WAI/test-evaluate/preliminary/)

## Что получить при передаче

Уточните состав исходников, ресурсов и пояснений, которые остаются у вас

Если дальше работает другая команда, ей должны быть понятны актуальная версия, способ запуска и ещё не подключённые части

Договоритесь, кто владеет нужными аккаунтами и кто выполняет публикацию — код в архиве и работающий сайт на домене являются разными результатами

Отдельно запишите порядок обращения по ошибкам и оценки новых пожеланий — не рассчитывайте на неописанную бессрочную поддержку

Для заказа одного лендинга есть [отдельный план подготовки к запуску](/blog/verstka-lendinga/)

## Как подготовить обсуждение с KEIVO

На [странице вёрстки по готовому макету](/services/verstka/) описаны состав результата, этапы и технические границы

Сейчас можно [скачать бриф](/materials/brief-na-verstku.md) и заполнить вводные самостоятельно — приём заявок на этой странице пока не открыт

Такой файл пригодится и для сравнения предложений разных исполнителей — в нём остаётся одна версия задачи, а не несколько разрозненных переписок

## Вопросы о заказе


### Выбирать фрилансера или агентство?

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



### Нужно ли выдавать доступы до оценки?

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



### Можно заказать вёрстку без готовых текстов?

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



## Источники и границы

- [W3C — планирование и управление доступностью](https://www.w3.org/WAI/planning-and-managing/)
- [W3C — предварительные проверки](https://www.w3.org/WAI/test-evaluate/preliminary/)

Источники проверены 29 октября 2026 года — учебные диалог и карточка замечания подготовлены редакцией KEIVO
