Как проверить верстку сайта по макету Figma

Коротко: Чтобы проверить верстку по макету Figma, используйте комплексный подход: ручную сверку отступов и шрифтов (pixel perfect), тестирование интерактивных прототипов на соответствие логике переходов, использование встроенных AI-линтеров для проверки консистентности стилей и автоматизированные регрессионные тесты. Также критически важно проводить аудит доступности по ГОСТ Р 52872-2019, проверяя контрастность и работу интерфейса с клавиатуры.

Кстати, в AmSales мы делаем разработку сайтов и приложений и ИИ-интеграцию и анализ звонков под ключ. Если нужна помощь - напишите нам.

Методы визуальной сверки макета и верстки

Визуальная сверка - это базовый этап контроля качества, на котором проверяется, насколько итоговый код соответствует тому, что нарисовал дизайнер. В 2026 году этот процесс стал более структурированным, но он все еще требует внимательности. Основная задача - убедиться, что макет не просто "похож", а математически точен. Если дизайнер заложил отступ между заголовком и кнопкой в 48 пикселей, а верстальщик сделал 40 или 50, это уже нарушение визуальной иерархии.

Существует два основных подхода к этой задаче. Первый - это ручная проверка. Специалист открывает макет в Figma и одновременно открывает сайт в браузере. Используются инструменты разработчика (DevTools) для измерения расстояний и параметров шрифтов. Второй подход - это автоматизированный pixel perfect проверка сайта. Это когда на экран накладывается полупрозрачный слой с макетом поверх работающего сайта. Если элементы "дрожат" или не совпадают при масштабировании, значит, в верстке есть ошибки в сетке или адаптивности.

Инструментарий для ручной проверки

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

• Типографику: межстрочное расстояние (line-height), межбуквенное (letter-spacing) и насыщенность шрифта.
• Сетки: соблюдение колонок и отступов (padding/margin).
• Иконки: их размер и выравнивание относительно текста.

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

Использование AI-линтера Figma для контроля консистстности

В 2026 году процесс передачи макета в разработку (handoff) значительно изменился благодаря внедрению интеллектуальных инструментов. Теперь перед тем, как разработчик возьмет задачу в работу, дизайнер может прогнать макет через встроенный AI-линтер Figma. Это критически важный этап, который позволяет избежать ситуации, когда верстальщик получает "грязный" дизайн, состоящий из хаоса разрозненных элементов.

AI-линтер работает как корректор в текстовом редакторе, только для дизайна. Он анализирует структуру слоев и соответствие заданным правилам. Если дизайнер вместо использования готового компонента или системного токена создал новый объект с теми же параметрами, линтер подсветит это как ошибку. Это предотвращает появление в коде "hardcode-значений" - когда в CSS прописаны произвольные цвета или размеры вместо переменных, которые должен использовать разработчик.

Что именно проверяет линтер?

Основной фокус направлен на соблюдение дизайн-системы. Линтер проверяет:

1. Использование только утвержденных стилей цвета и типографики.
2. Наличие всех необходимых свойств у компонентов (например, все ли состояния кнопок описаны).
3. Логику именования слоев (если это настроено в правилах команды).
4. Отсутствие "мусорных" элементов, которые не несут смысловой нагрузки.

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

Проверка прототипов и логики переходов в Figma

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

В 2026 году стандартным методом тестирования является использование режима Present (Play) в Figma. Проверяющий должен пройти по всем сценариям (user flows), которые были заложены дизайнером. Если в макете предусмотрено появление выпадающего меню при клике, а в верстке оно появляется с задержкой или не там, где нужно - это баг логики, который должен быть зафиксирован.

Сценарии для тестирования переходов

При проверке прототипов важно смотреть не только на "счастливый путь" (когда всё работает идеально), но и на краевые случаи. Например:

• Как выглядит переход между страницами при медленном интернете?
• Закрывается ли модальное окно при клике на область вне его?
• Сохраняется ли состояние элементов (например, выбранная вкладка) при переходе назад?

Технический аудит доступности по стандарту ГОСТ

Доступность интерфейса (Accessibility) - это не "дополнительная опция", а базовое требование для качественного продукта. В России ориентиром для таких проверок служит ГОСТ Р 52872-2019. Хотя этот стандарт носит добровольный характер, его требования являются золотым стандартом для создания удобных сервисов. Если ваш сайт не доступен для людей с ограниченными возможностями, вы теряете огромный сегмент аудитории и рискуете репутацией.

Технический аудит доступности включает в себя проверку того, как сайт взаимодействует с вспомогательными технологиями, такими как скринридеры (программы чтения экрана). Это проверка структуры документа: правильно ли расставлены заголовки (H1-H6), есть ли у изображений осмысленные alt-тексты, и не "заперт" ли пользователь в модальном окне, если он использует только клавиатуру.

Ключевые аспекты аудита по ГОСТ

Проверка должна охватывать несколько уровней:

1. Структурная целостность: логическая последовательность элементов при навигации.
2. Управление с клавиатуры: возможность совершить любое действие без использования мыши.
3. Семантика: использование правильных HTML-тегогов (main, nav, section, article) вместо бесконечных div.

Контроль контрастности и параметров доступности интерфейса

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

Согласно современным стандартам, которые перекликаются с WCAG, коэффициент контрастности текста должен быть не ниже 4.5:1 для обычного текста и не ниже 3:1 для крупного заголовка. Это критическое значение, которое гарантирует читаемость. Если интерфейс "слепнет" при переключении на темную тему - это серьезная ошибка проектирования.

Чек-лист для проверки контрастности и фокуса

При проведении аудита интерфейса обращайте внимание на следующие параметры:

• Контрастность текста и фона: использование специальных плагинов для проверки соотношения цветов.
• Видимый фокус: когда пользователь перемещается по сайту кнопкой Tab, он должен четко видеть, какой элемент сейчас активен (рамка фокуса).
• Отсутствие "ловушек" клавиатуры: пользователь не должен заходить в элемент (например, календарь), из которого невозможно выйти, используя только клавиатуру.
• Размер интерактивных элементов: кнопки и ссылки должны быть достаточно крупными, чтобы по ним было легко попасть пальцем на сенсорном экране.

Типичные ошибки при передаче дизайна в разработку

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

Чаще всего ошибки случаются на этапе подготовки макета к handoff. Дизайнеры часто забывают подготовить состояния элементов (hover, active, disabled, error) или не учитывают, как контент будет вести себя при длинных заголовках или нехватке места. В итоге верстка "разваливается", когда на сайт приходит реальный текст вместо "Lorem Ipsum".

Разбор основных проблем

Давайте разберем типичные примеры:

1. Игнорирование адаптивности: дизайнер отрисовал только Desktop и Mobile, забыв про планшетную версию или промежуточные состояния.
2. Сложные эффекты: использование градиентов, теней или размытий, которые крайне тяжело или невозможно реализовать стандартными средствами CSS без потери производительности.
3. Отсутствие сетки: когда элементы расставлены "на глаз", и верстальщик не понимает, какой модуль сетки использовать для выравнивания.
4. Проблемы с иконками: использование растровых картинок вместо векторных (SVG), что приводит к потере качества при масштабировании.

Автоматизация визуальных регрессионных тестов сайта

Когда сайт становится большим, проверять его вручную становится невозможно. Любое мелкое изменение в CSS-файле может неожиданно "сломать" верстку на странице, о которой вы даже не подозревали. Чтобы не тратить сотни часов на ручную проверку после каждого обновления, используются визуальные регрессионные тесты. Это автоматизированный способ контроля качества веб-разработки.

Суть метода заключается в создании "эталонного снимка" (baseline) страницы в идеальном состоянии. Затем, после внесения изменений в код, система автоматически делает новый снимок и сравнивает его с эталоном. Если на новом снимке есть отличия (даже если это сдвиг кнопки на 2 пикселя), система выдает уведомление о несоответствии. Это позволяет находить ошибки до того, как их увидит пользователь.

Как внедрить автоматизацию

Процесс внедрения обычно выглядит следующим образом:

• Выбор инструмента (например, Percy, Applitools или open-source решения на базе Playwright/Cypress).
• Настройка сценариев: нужно определить, какие страницы и состояния элементов нужно тестировать.
• Интеграция в CI/CD: тесты должны запускаться автоматически при каждом коммите или Pull Request.
• Процесс аппрува: если тест нашел различие, разработчик или дизайнер должен посмотреть на него и подтвердить: это баг или это намеренное изменение дизайна.

Что запомнить:

• Используйте AI-линтеры в Figma для проверки консистентности макета перед передачей в разработку.
• Проверяйте доступность интерфейса на соответствие ГОСТ Р 52872-2019, уделяя внимание контрастности и навигации с клавиатуры.
• Не забывайте тестировать не только статичную картинку, но и логику переходов в интерактивных прототипах.
• Для крупных проектов внедряйте автоматические визуальные регрессионные тесты, чтобы избежать случайных поломок верстки.