Ошибки начинающего веб-дизайнера в первом макете сайта

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

Что происходит с блоком на узком экране? Как выглядит кнопка под курсором и в момент нажатия? Неделя уходит на переписку, хотя сама картинка была красивой.

Макет оценивают по числу решений, которые он снимает с разработчика: сколько вопросов закрыто, столько файл и стоит.

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

Какая ошибка в первом макете стоит дороже всего?

Что важно знать: дороже всего обходится макет, нарисованный под одну ширину экрана, без правил поведения на остальных. Критерий Reflow из WCAG 2.2 (пункт 1.4.10, уровень AA) требует, чтобы содержимое работало при ширине 320 пикселей CSS без прокрутки в двух направлениях. Файл с одной десктопной страницей этот вопрос не закрывает, и разработчик решает его наугад.

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

Разработчик делает единственное, что может: придумывает поведение сам. Угадывает он редко, и отсюда берётся правка на неделю.

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

Обязательного списка брейкпоинтов ни W3C, ни вендоры не публикуют. У Google опубликован набор, на который можно опереться и сослаться: пять диапазонов ширины окна с точными границами перечислены в документации Android.

Название размера окна у Google	Диапазон ширины	Что обычно рисуют
Compact	до 599 dp	телефон
Medium	600 dp и шире, вплоть до 839	планшет вертикально
Expanded	840 dp и шире, вплоть до 1199	планшет горизонтально, узкий ноутбук
Large	1200 dp и шире, вплоть до 1599	десктоп
Extra-large	1600 dp и шире	широкий монитор

Три оговорки к таблице, без которых она вводит в заблуждение:

• dp это андроидная единица Google, в вебе она не применяется, и переносить диапазоны в макет один в один нельзя;
• границы взяты из документации Android: Compact, Medium и Expanded совпадают с брейкпоинтами Material Design, а Large и Extra-large добавлены под десктоп и внешние экраны;
• адрес страницы про эти диапазоны в Material Design сменился: старый путь со словами window size classes отдаёт 404, рабочий адрес теперь про breakpoints.

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

Какие ещё ошибки начинающего веб-дизайнера ломают вёрстку?

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

• Шрифтовая каша и кегли на глаз. В файле оказывается шесть размеров текста с разницей в пару пикселей, два семейства шрифтов без причины и три оттенка серого для одного и того же по смыслу текста. Собрать из этого стили невозможно, и вёрстка ставит свои значения.
• У кнопок и полей нет состояний. Нарисована одна кнопка в покое. Что показать под курсором, в момент нажатия, при фокусе с клавиатуры и когда действие недоступно, в макете не сказано.
• Заглушка вместо реального текста. Латинская рыба ровная, поэтому блок всегда выглядит аккуратно. Реальный заголовок бывает в три раза длиннее, описание товара иногда состоит из одного слова, и на боевых данных карточка рвётся.
• Нет шага отступов, слои без имён. Расстояния между блоками выставлены на глаз: где 18, где 21, где 24. Слои называются Frame 427 и Rectangle 12. Через месяц в такой файл не вернётся и сам автор.

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

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

Почему макет разваливается на мобильной ширине?

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

Популярный совет «рисуй мобильную версию на 375 пикселей» опирается на ширину конкретной модели телефона. Устройства меняются, и цифра тихо устаревает. Требование из WCAG живёт дольше, потому что описывает границу поведения безотносительно к моделям телефонов.

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

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

Про число колонок стоит сказать отдельно, потому что «сетка обязательно 12 колонок» кочует из статьи в статью. В WCAG такого требования нет. В гайдлайнах Google по сеткам число колонок меняется вместе с шириной окна, и одного обязательного значения там не задано.

Число 12 это значение по умолчанию у переменной $grid-columns в Bootstrap, то есть настройка конкретного инструмента вёрстки. Соглашение удобное и привычное, держится оно на популярности самого инструмента. Если тема сеток пока туманна, начните с материала о том, что вообще входит в работу дизайнера интерфейсов.

Как назначать кегли и сколько шрифтов брать?

Что важно знать: кегли назначают шкалой из четырёх ступеней, это заголовки, основной текст, подписи и текст кнопок. Правила «максимум три шрифта» нет ни в WCAG, ни в гайдлайнах Google. Минимального кегля в WCAG тоже нет, есть критерий 1.4.4 Resize Text уровня AA про масштаб до 200 процентов и критерий 1.4.3 с контрастом 4,5:1.

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

Контраст проверяется в редакторе плагином или калькулятором. Проверяют все пары «текст на фоне»: серый на белом, белый на цвете бренда, текст на фотографии. Крупным считается кегль от 18 pt или от 14 pt полужирного, для него планка 3:1.

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

Зачем рисовать состояния кнопок и полей?

Что важно знать: состояния рисует дизайнер, потому что это решения интерфейса и принимать их приходится до вёрстки. Справка Figma по вариантам приводит кнопку с набором значений default, hover, pressed, disabled как типовой пример свойства состояния. Плюс два требования WCAG уровня AA: 2.4.7 Focus Visible про видимый фокус клавиатуры и 2.4.11 Focus Not Obscured про его перекрытие.

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

Минимальный набор для интерактивного элемента выглядит так:

• спокойное состояние;
• под курсором;
• в момент нажатия;
• в фокусе с клавиатуры;
• недоступное;
• состояние ошибки для полей ввода.

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

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

Какого размера делать зоны нажатия?

Что важно знать: у требования к зоне нажатия есть два разных числа, и путать их нельзя. Критерий 2.5.8 Target Size (Minimum) уровня AA требует цель размером не меньше 24 на 24 пикселя CSS, с пятью исключениями. Критерий 2.5.5 Target Size (Enhanced) поднимает планку до 44 на 44 пикселей CSS, но это уже уровень AAA.

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

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

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

Требование	Значение	Уровень	Документ
зона нажатия, минимум	24 на 24 пикселя CSS	AA	WCAG 2.2, критерий 2.5.8
зона нажатия, повышенно	44 на 44 пикселя CSS	AAA	WCAG 2.2, критерий 2.5.5
ширина для вертикальной прокрутки	320 пикселей CSS	AA	WCAG 2.2, критерий 1.4.10
контраст обычного текста	4,5:1	AA	WCAG 2.2, критерий 1.4.3
масштабирование текста	до 200 процентов	AA	WCAG 2.2, критерий 1.4.4

Знаменитые «44 пикселя» из мобильной практики пришли по другой линии: у Apple свои рекомендации по размеру элементов, они опубликованы в Human Interface Guidelines отдельно от WCAG. Прежде чем брать оттуда число, откройте документ и посмотрите, в какой единице оно записано. Если берёте число, называйте документ, критерий и единицу разом.

Почему ошибки начинающего веб-дизайнера повторяются у всех?

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

Самая вредная из причин это числа из интернета: три из них кочуют по статьям как индустриальный стандарт, и ни одно им не является.

• «Сетка 12 колонок». Значение по умолчанию у переменной $grid-columns в Bootstrap, то есть настройка инструмента вёрстки.
• «Контейнер 1440 пикселей». Ширина популярного шаблона в редакторе. В гайдлайнах W3C, Google и Apple такой нормы нет.
• «Отступы кратны восьми». Полезная привычка родом из гайдлайнов Google по сеткам, где базовая сетка описана восьмёркой в dp, то есть в андроидной единице.

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

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

В каком порядке собирать макет, чтобы этих ошибок не было?

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

1. Соберите реальный контент. Настоящие заголовки, названия, цены, фотографии. Возьмите короткий вариант и самый длинный, какой может встретиться.
2. Назначьте ширины проверки. Возьмите узкую, среднюю и широкую и запишите их прямо в файле отдельной подписью.
3. Настройте сетку и шаг отступов. Одно значение шага на весь макет, поля и колонки заданы числами.
4. Соберите шкалу кеглей и цвета. Четыре ступени текста, проверенный контраст пар по критерию 1.4.3.
5. Нарисуйте компоненты и их состояния. Кнопки, поля и карточки, а состояния держите вариантами внутри компонента.
6. Собирайте экраны из компонентов. Копии слоёв в дело не идут: копия не обновится вместе с остальными.
7. Прогоните крайние состояния. Пустой список, очень длинное название, ошибка загрузки, отсутствие картинки.
8. Проверьте узкую ширину и назовите слои. 320 пикселей CSS как нижняя граница проверки, имена по смыслу перед передачей.

Шаги 1 и 7 пропускают чаще всего, хотя стоят они дешевле остальных: полчаса на реальные тексты и крайние случаи снимают большую часть будущих правок.

Чек-лист перед сдачей макета

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

• [ ] Ширины, на которых макет проверен, перечислены в файле.
• [ ] Правила поведения блоков между ширинами описаны словами.
• [ ] Шаг отступов один на весь макет и задан числом.
• [ ] Шкала кеглей закрыта: заголовки, текст, подписи, кнопки.
• [ ] Контраст текстовых пар проверен по критерию 1.4.3.
• [ ] У кнопок и полей нарисованы все состояния, включая фокус и ошибку.
• [ ] Зоны нажатия не мельче 24 на 24 пикселей CSS.
• [ ] Фокус клавиатуры виден и не перекрыт липкой шапкой.
• [ ] В макете стоят реальные тексты, заглушек не осталось.
• [ ] Слои и фреймы названы по смыслу, мусорные группы удалены.

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

Что делать, если макет уже завернули?

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

Завёрнутый первый макет это обычная точка в работе, через неё проходят все. Файл возвращают потому, что по нему нельзя верстать, и чинится он добавлением решений.

Первый ход: попросите замечания письменным списком. Устный разбор рассыпается через час, а список превращается в задачи.

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

Спорные решения выносите отдельно и приносите аргумент из документа. Фраза «мне кажется, так лучше» работает хуже, чем «критерий 2.5.8 просит цель от 24 пикселей CSS, поэтому я расширил зону иконки».

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

Где этот разбор не поможет?

Что важно знать: статья закрывает передачу макета в вёрстку и типовые провалы новичка. Она не заменяет исследование пользователей и не превращает слабую идею в сильную. Требования WCAG тоже покрывают не всё: это критерии доступности, вкус и уместность они не оценивают.

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

И неприятное: аккуратный макет по чек-листу может остаться скучным. Система убирает брак, а красота приходит от насмотренности и практики. Генеративная графика помогает на этапе поиска идей: нейросети для референсов и макетов.

Что нужно на старте и сколько это стоит?

Что важно знать: денежный вход в первый макет близок к нулю, потому что рисовать можно в браузерном редакторе интерфейсов, а гайдлайны W3C, Google и Apple опубликованы открыто. Figma считает доступ местами разных типов: Full, Dev и Collab. Актуальные условия смотрите на странице вендора, потому что тарифная модель менялась и суммы устаревают быстрее статей.

Что нужно на старте, кроме самого редактора:

Что нужно	Зачем	Где взять
редактор интерфейсов	сетки, компоненты, варианты	браузерная версия
шрифты с открытой лицензией	легальное коммерческое использование	каталоги открытых шрифтов
проверка контраста	критерий 1.4.3	плагин редактора или калькулятор
текст гайдлайнов	ссылка на требование в споре	сайты W3C и вендоров
реальный контент	проверка блоков на длинных строках	заказчик или собственный текст

Главная трата на старте измеряется в часах: разобраться с компонентами и вариантами быстрее, чем перерисовывать макет по третьему кругу. Отдельно стоит освоить автораскладку: она сама пересобирает блок под длинный текст. Если нужен ориентир по профессии в целом, посмотрите, чем UX/UI-дизайнер отличается от веб-дизайнера и как оформить портфолио без опыта.

Вопросы новичков

Сколько колонок должно быть в сетке?

Столько, сколько удобно вашей раскладке. Двенадцать колонок это значение по умолчанию у переменной $grid-columns в Bootstrap, удобное делением на 2, 3, 4 и 6. Ни WCAG, ни гайдлайны Google по сеткам обязательного числа не задают: у Google оно меняется вместе с шириной окна. Свой выбор зафиксируйте в файле.

С какой ширины начинать мобильную версию?

Считайте нижней границей 320 пикселей CSS: это ширина из критерия 1.4.10 Reflow уровня AA. Ширина конкретной модели телефона годится как удобный холст для рисования и устаревает вместе с устройством.

Обязательно ли называть слои по какому-то стандарту?

Обязательного стандарта именования нет ни в WCAG, ни в справке Figma: остаётся договорённость внутри команды или файла. Рабочий минимум такой: имя отвечает на вопрос, что это за элемент. Форму и цвет оставьте самому слою.

Нужно ли рисовать состояния, если их всё равно делает разработчик?

Нужно. Без макета разработчик выбирает цвет и поведение сам, и результат расходится с остальным интерфейсом. Справка Figma приводит default, hover, pressed, disabled как типовой набор значений у кнопки.

Кнопка меньше 44 пикселей: это ошибка?

Не обязательно. Уровень AA по критерию 2.5.8 требует цель от 24 на 24 пикселя CSS, а 44 на 44 это уже критерий 2.5.5 уровня AAA. Плюс в 2.5.8 есть пять исключений, включая случай, когда мелкие цели разнесены достаточным расстоянием.

Источники

• W3C, WCAG 2.2, Understanding SC 2.5.8 Target Size (Minimum), уровень AA, 24 на 24 пикселя CSS. Проверено 2026-08-02: https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
• W3C, WCAG 2.2, Understanding SC 2.5.5 Target Size (Enhanced), уровень AAA, 44 на 44 пикселя CSS. Проверено 2026-08-02: https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html
• W3C, WCAG 2.2, Understanding SC 1.4.10 Reflow, уровень AA, 320 и 256 пикселей CSS. Проверено 2026-08-02: https://www.w3.org/WAI/WCAG22/Understanding/reflow.html
• W3C, WCAG 2.2, Understanding SC 1.4.3 Contrast (Minimum), уровень AA, 4,5:1 и 3:1. Проверено 2026-08-02: https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
• W3C, WCAG 2.2, Understanding SC 1.4.4 Resize Text, уровень AA, 200 процентов. Проверено 2026-08-02: https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html
• W3C, WCAG 2.2, Understanding SC 2.4.7 Focus Visible, уровень AA. Проверено 2026-08-02: https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html
• W3C, WCAG 2.2, Understanding SC 2.4.11 Focus Not Obscured (Minimum), уровень AA. Проверено 2026-08-02: https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html
• Material Design 3, Breakpoints. Рабочий адрес проверен 2026-08-02, старый адрес про window size classes отдаёт 404. Страница рендерится скриптом, без JS отдаёт пустой каркас, числовая опора взята с developer.android.com: https://m3.material.io/foundations/layout/breakpoints/overview
• Android Developers, Window size classes: диапазоны Compact, Medium, Expanded, Large, Extra-large в dp; Large и Extra-large добавлены сверх брейкпоинтов Material Design. Проверено 2026-08-02: https://developer.android.com/develop/ui/compose/layouts/adaptive/window-size-classes
• Android Developers, Grids and units: базовая сетка 8 dp, число колонок меняется под ширину окна. Проверено 2026-08-02: https://developer.android.com/design/ui/mobile/guides/layout-and-content/grids-and-units
• Bootstrap, Grid system: переменная $grid-columns со значением 12 по умолчанию. Проверено 2026-08-02: https://getbootstrap.com/docs/5.3/layout/grid/
• Figma Learn, Create and use variants: свойства и значения состояний кнопки. Проверено 2026-08-02: https://help.figma.com/hc/en-us/articles/360056440594-Create-and-use-variants
• Figma Learn, Add auto layout to a design. Проверено 2026-08-02: https://help.figma.com/hc/en-us/articles/5731482952599-Add-auto-layout-to-a-design
• Figma Learn, Manage seats in Figma: типы мест Full, Dev, Collab и что даёт каждое. Проверено 2026-08-19: https://help.figma.com/hc/en-us/articles/360039960434-Manage-seats-in-Figma
• Apple, Human Interface Guidelines: отдельный от WCAG документ с рекомендациями вендора. Страница рендерится скриптом, без JS отдаёт пустой каркас, ни одно число статьи на неё не опирается. Проверено 2026-08-02: https://developer.apple.com/design/human-interface-guidelines/
• Трекер W3C, обсуждение критерия 2.5.8 практиками. Проверено 2026-08-02: https://github.com/w3c/wcag/issues/1894