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

Что такое HTML и зачем он нужен

HTML (Hyper Text Markup Language) — это язык разметки, который создает структуру и содержание веб-страниц. Язык состоит из тегов — специальных маркеров, которые указывают браузеру, как интерпретировать и отображать содержимое.

Когда разработчик смотрит на ваш макет, он видит не просто картинку, а набор HTML-элементов: заголовки, абзацы, кнопки, картинки, списки. И от того, насколько ваш макет соответствует логике этих элементов, зависит, как быстро и качественно сайт будет свёрстан.

Блочная модель и поток документа

Это самый важный пункт для дизайнера. Все элементы вёрстки вписаны в прямоугольные области — их называют боксами (англ. box). Боксов существует несколько типов, за тип бокса отвечает свойство display.

Основных типов боксов два — блочный бокс display: block и строчный бокс display: inline, они ставятся по умолчанию большинству элементов.



Рисунок 1. Позиционирование блочных и строчных блоков на странице.

• Поток документа — это естественный порядок расположения элементов на странице.
• Блочные элементы (<div>, <p>, <h1>–<h6>) занимают всю ширину родителя и располагаются друг под другом. Как кирпичи в стене.
• Строчные элементы (<span>, <a>, <img>) располагаются в одну строку и занимают только необходимое место.

Почему это важно понимать? Потому что многие дизайнерские решения, могут красиво выглядеть в Figma, но противоречить логике блочной модели. Например, вы решили поставить два абзаца в одну строку. Абзац или <p> это блочный элемент, поэтому, чтобы поставить 2 абзаца в 1 строку это потребует дополнительных CSS-настроек.

Иерархия заголовков

Очень частая ошибка: дизайнер делает текст большим и жирным, потому что «так красивее», и называет это заголовком. Но для разработчика и поисковиков важно, какой именно тег используется: <h1>, <span> или <p>.

Правило простое:

• На странице должен быть только один <h1> — главный заголовок.
• Подзаголовки идут по порядку: <h2>, затем <h3>, <h4>.
• Нельзя пропускать уровни (например, после <h1> сразу ставить <h4>).

Это важно для SEO и доступности. Когда вы передаёте макет, указывайте не просто «заголовок крупный», а «H1», «H2», «текст». Это упростит задачу разработчику и сэкономит время.

Семантическая разметка

Некоторые теги несут не только визуальную, но и смысловую нагрузку. Ниже представлен перечень основных семантических тегов.

Рисунок 2. Основные семантические теги.

Семантическая разметка помогает поисковикам и скринридерам правильно интерпретировать содержание страницы. Поэтому, создавая макет, важно думать не только о внешнем виде, но и о смысле каждого блока. Будь это шапка сайта (header), навигационное меню (nav) или основной контент (main).

Дизайнеру стоит заранее продумывать эту логику и соответственно группировать и подписывать слои в макете.

Что такое CSS и как он работает

CSS (Cascading Style Sheets) — язык описания внешнего вида HTML-документа. Он отвечает за цвета, шрифты, отступы, позиционирование, анимации. Практически ни один сайт не обходится без CSS, поэтому HTML и CSS действуют в единой связке.

В Figma вы задаёте свойства для элементов: цвет фона, отступы, скругление и так далее. В CSS всё то же самое, но в виде кода. И чем точнее ваш макет повторяет логику CSS, тем быстрее разработчик его реализует.

Блочная модель (Box Model)

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

• содержимого (content);
• внутренних отступов (padding);
• границы (border);
• внешних отступов (margin).

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



Рисунок 3. Схема построения блочной модели.

В Figma вы работаете с содержимым (content) и отступами (padding). Но разработчик считает по-другому. Размер элемента включает в себя: ширину содержимого (content) + padding + border. Из-за этого часто возникают расхождения.

В CSS есть свойство, которое решает эту проблему — box-sizing: border-box. Оно заставляет браузер включать padding и border в общую ширину и высоту элемента.

Важно: дизайнеру не обязательно знать синтаксис, но полезно понимать, что разработчик может использовать этот подход. Если вы видите расхождения в размерах, просто обсудите с разработчиком, использует ли он box-sizing: border-box — это часто объясняет разницу.

Когда использовать padding, а когда margin?

Если элемент должен быть больше и кликабельнее (кнопка, ссылка) — используйте padding, а если нужно просто отодвинуть блок от соседей, чтобы они не слипались — используйте margin.

Совет: используйте Auto Layout в Figma, он работает по схожей логике. Это поможет вам мыслить как разработчик и создавать макеты, которые легко и точно сверстать.

Позиционирование элементов

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

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



Рисунок 4. Типы позиционирования элементов в CSS.

Дизайнеру важно знать эти типы, чтобы не рисовать макеты, которые невозможно реализовать без сложных CSS ухищрений.

Самые частые ошибки в макетах и как их избежать

Ошибка 1: Забытые состояния элементов

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



Рисунок 5. Основные состояния элементов.

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

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

Ошибка 2: Игнорирование «живого» контента

В макете дизайнер использует идеальный, короткий текст, который помещается ровно в одну строку. Но в реальном проекте клиент, например, вставит в форму длинное название, которое не помещается в проектируемые границы заголовка. Или изображение в макете — 600×400px, а в реальности загружают квадратное фото 800×800px. В итоге картинка обрезается, текст переносится на вторую строку, и макет «плывёт».

Как избежать ошибки:

1. Проектируйте с запасом. Используйте в макетах длинные тексты, чтобы показать, как блок выглядит в «плохом» случае.
2. Показывайте примеры с разными изображениями. Добавьте в макет вариант, где картинка слишком широкая или слишком узкая.
3. Используйте «резиновые» элементы. В Figma с Auto Layout вы можете показать, как блок расширяется при добавлении контента.
4. Обсуждайте с разработчиком ограничения. Уточните: какая максимальная длина текста может быть в этом поле? Что делать, если картинка не подходит по пропорциям?

Ошибка 3: Отсутствие спецификации

Многие делают библиотеку, в которой показаны все состояния элементов. Но разработчик не всегда понимает в какой момент состояние элемента в интерфейсе меняется, поэтому:

• дополнительно опишите как работает тот или иной элемент в спецификации. В ней можно использовать ссылки на разные части систем или анимации, чтобы разработчик посмотрел, как эта анимация работает в интерфейсе;
• для сложных сценариев возможно использовать прототипирование в Figma или составить схему user-flow, в которой видны все переходы;
• обязательно оформляйте дизайн-систему, в ней содержатся все компоненты, стили, цвета, шрифты, брендинг;
• не стесняйтесь очно обсудить с разработчиком все важные моменты или запишите видео с пояснениями. Видео всегда можно пересмотреть.

Ошибка 4: Хаос в Figma

Нет ничего страшнее для разработчика, чем макет, где:

1. 100 слоёв с названиями «Rectangle 45», «Group 12», «Copy 3»;
2. компоненты не используются;
3. мусор на полях (лишние фреймы, старые версии блоков);
4. отсутствие стилей в макете.

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

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

Адаптивность и как дизайнеру её учитывать

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

Основные принципы адаптива:

• Mobile-first. Сначала дизайн для телефона, потом для планшета и десктопа. Это проще и эффективнее.
• Контент первичен. На мобильном экране не нужно пытаться уместить всё. Оставляйте главное, второстепенное скрывайте или упрощайте.
• Гибкие сетки. Вместо фиксированных размеров используйте проценты и относительные единицы.
• Типографика. Шрифты должны адаптироваться: на мобильном они не могут быть такими же крупными, как на десктопе.

Чек-лист подготовки макета для разработчика

• Все состояния кнопок и полей ввода (hover, active, disabled, loading) отрисованы
• Адаптив проработан для 3 ключевых разрешений (десктоп, планшет, мобильный)
• Показаны состояния экранов: загрузка (loading), ошибка (error), пустой экран (empty)
• Все шрифты и цвета вынесены в стили (текстовые стили, цветовые стили)
• Сложные элементы и логика описаны в комментариях в Figma
• Нет «мусора» на полях макета (лишних фреймов, старых версий)
• Используются компоненты (не дублируются одинаковые блоки)
• Отступы и размеры аккуратные (используется Auto Layout)
• Иконки и изображения подготовлены для экспорта (SVG для векторных, PNG для растровых)
• Проведено короткое дизайн-ревью с разработчиком до старта вёрстки

Заключение

Понимание основ HTML и CSS — это не про то, чтобы стать фронтенд-разработчиком. Это про то, чтобы:

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

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

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

Автор статьи: Дарья Панкратова, выпускница 35 потока курса «UX/UI-дизайнер»