Как сделать макет сайта: от структуры до проверки в 2026

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

Определите результат страницы, а не её украшения

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

• Целевая аудитория описана через ситуацию и задачу, а не через абстрактный возраст.
• Главное действие можно назвать одним глаголом: записаться, выбрать, отправить, купить или скачать.
• Для действия перечислены обязательные данные и подтверждение результата.
• Есть ограничение: что страница не обещает и какую задачу решает другой раздел.

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

Сначала соберите содержание и каркас

Запишите реальные заголовки, подписи кнопок, поля формы и ответы на возражения. Серые прямоугольники с текстом «тут будет контент» скрывают проблемы: неизвестно, поместится ли заголовок, понятна ли кнопка и хватает ли данных для решения.

1. Составьте список обязательных фактов и действий без дизайна.
2. Расположите блоки в порядке вопросов читателя: что это, подходит ли мне, что получу, почему можно доверять, что сделать сейчас.
3. Нарисуйте каркас одной колонки для узкого экрана. Так быстрее обнаруживается лишний контент и неверный порядок.
4. Добавьте широкое состояние, объединяя блоки в колонки только там, где сравнение действительно удобнее.
5. Свяжите основные экраны кликами и пройдите сценарий от входа до подтверждения.

Подход mobile first начинает с малого экрана и затем добавляет возможности для более широкой области. MDN описывает его как способ сначала обеспечить рабочий опыт на малом экране, а потом расширять его (MDN).

Сделайте не три картинки, а систему состояний

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

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

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

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

Соберите компоненты и правила

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

Имена слоёв и компонентов должны описывать роль: button/primary, form/error, card/service, а не цвет или номер. Кнопка может сменить цвет, но её роль останется. Для изображений укажите пропорции и поведение при обрезке, для текста задайте пример самой длинной реальной строки.

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

По теме: Как сделать сайт-каталог сайтов: структура и проверка в 2026

Проверьте адаптивность и доступность макета

W3C требует, чтобы обычный контент мог перестроиться до ширины, эквивалентной 320 CSS-пикселям, без потери информации и горизонтальной прокрутки, кроме элементов, которым двумерная структура действительно нужна (W3C WAI). Поэтому проверьте узкое состояние отдельно, а не уменьшайте широкий макет целиком.

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

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

Проведите пятишаговую приёмку до кода

Второй практический артефакт, протокол приёмки. Дайте макет человеку, который не видел задачу, и не подсказывайте первые две минуты.

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

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

По теме: Как сделать женский сайт без стереотипов в 2026 году

Когда детальный макет не подходит

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

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

В какой программе делать макет сайта?

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

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

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

Чем макет отличается от прототипа?

Макет показывает структуру и внешний вид состояния. Прототип связывает состояния и позволяет пройти сценарий кликами. Для проверки формы или покупки нужны оба уровня.

Можно ли сразу отдать ИИ картинку макета и получить сайт?

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