Design QA: почему сверка с макетом — это не паранойя, а здравый смысл
11.08.2026
Дизайн утверждён, разработка завершена, задача переехала в колонку «Готово». Команда радуется, заказчик смотрит на результат и вроде бы доволен. А через неделю приходят первые отзывы пользователей — кнопка не нажимается на мобильном, текст вылезает за границы карточки, а шрифт почему-то другой. Звучит как досадная мелочь, но именно из таких мелочей складывается впечатление о продукте.
Design QA — это этап, на котором сверяют реализованный интерфейс с исходным макетом. Не путать с тестированием функциональности: здесь проверяют не то, «работает ли кнопка», а то, «выглядит ли она так, как задумано». Разбираемся, зачем этот этап нужен и что происходит, когда его пропускают.
Почему «готово» ещё не значит «совпало с макетом»
Между Figma и живым экраном пользователя лежит целая цепочка преобразований. Дизайнер рисует в контролируемых условиях: фиксированная ширина артборда, заданные шрифты и подготовленный контент. Вёрстщик переводит это в код, адаптирует под разные разрешения, подключает реальные данные и встраивает интерфейс в систему. На каждом шаге возможны смещения. Поэтому Design QA разумнее включать в маршрут работы заранее, а не оставлять на последнюю ночь перед релизом. В разборе от задачи до релиза видно, где именно такая проверка должна появляться в общем цикле.
Аккуратная вёрстка и подробный макет создают ощущение, что всё должно совпасть само собой. На практике полного совпадения без отдельной проверки ожидать не стоит. Отступы округляются, сетка ломается на нестандартных ширинах, фоновые изображения сплющиваются, тени выглядят иначе на тёмном фоне устройства. Эти вещи незаметны, когда смотришь на код или отдельные компоненты. Они проявляются, когда собираешь страницу целиком и открываешь на настоящем телефоне.
Что именно проверяют на Design QA
Процесс не сводится к прикладыванию линейки к скриншоту. В первую очередь смотрят на то, что влияет на восприятие и удобство.
- Типографика. Правильный ли шрифт подгрузился, совпадают ли размеры, межстрочные интервалы и насыщенность. Частая проблема — системный шрифт заменяет кастомный, если тот не успел загрузиться или путь в CSS указан неверно.
- Отступы и выравнивание. Визуальный баланс элементов. Даже разница в 4–8 пикселей между карточками создаёт ощущение небрежности.
- Адаптивность. Как интерфейс ведёт себя на ключевых разрешениях. Не съезжает ли навигация, не обрезается ли контент, корректно ли перестраивается сетка.
- Состояния элементов. Кнопки при наведении, поля при фокусе, ошибки валидации форм, пустые состояния списков. Дизайнеры рисуют эти состояния, но в верстке они регулярно забываются.
- Цвета и контраст. Фоновые заливки, границы, иконки. На разных экранах один и тот же HEX-код может выглядеть по-разному.
- Анимации и переходы. Длительность, тайминги, кривые Безье. Плавное движение в макете может превратиться в дёрганое рывкообразное перемещение в браузере.
Реальные сценарии, когда Design QA спасает
Типичный пример: после сборки страницы плашки скидок на карточках товаров начинают обрезаться на одной из мобильных ширин. Сам компонент по отдельности выглядит правильно, но в итоговом шаблоне оказывается внутри контейнера с overflow: hidden. Такой дефект легко пропустить, если проверять компоненты изолированно.
Другой типичный сценарий — кнопка на форме визуально теряется, потому что в коде остался оттенок из старой версии дизайн-системы. Макет обновлён, а реализация — нет. Даже без привязки к конкретной метрике это уже достаточная причина для проверки: пользователь может хуже замечать основное действие, а команда получает расхождение между согласованным дизайном и продуктом.
Ещё один классический пример — модальные окна и тосты. В макете они нарисованы поверх контента и выглядят отлично. В реализации они могут перекрываться фиксированными элементами, не центрироваться при скролле или не закрываться свайпом на мобильных. Это не баг в классическом понимании — функционально окно работает. Но пользовательский опыт испорчен.
Кто должен делать проверку
В небольших командах эту задачу часто перекладывают на самого дизайнера — логично, он лучше всех знает, как должно выглядеть. Но есть нюанс: дизайнер смотрит на результат через призму своего макета и склонен замечать отклонения, которые обычный пользователь не увидит. При этом он может не заметить проблемы, связанные с реализацией, потому что не думает категориями вёрстки.
Оптимально, когда проверку ведёт человек, который понимает и в дизайне, и в технической стороне. Иногда это выделенная роль — UI-тестировщик или дизайнер с техническим бэкграундом. В некоторых командах процесс делают совместным: дизайнер прогоняет по визуальной части, фронтендер — по технической корректности реализации.
Главное правило — проверка должна быть отдельным этапом с выделенным временем. Когда её делают «по остаточному принципу» между задачами, риск пропустить расхождения заметно выше.
Инструменты и подходы
Ручная сверка скриншотов остаётся простым и понятным способом первичной проверки. Инструменты визуального регрессионного тестирования вроде Percy или Chromatic особенно полезны при повторных проверках, когда уже есть эталонный снимок. На первом проходе автоматические сравнения всё равно приходится интерпретировать: часть отличий может быть связана с рендерингом шрифтов и особенностями среды.
На практике чаще всего используют простую схему: открывают страницу на реальных устройствах и нескольких разрешениях в браузере, рядом открывают макет в Figma и последовательно проходят по каждому блоку. Некоторые команды заводят чеклисты, но жёсткие шаблоны здесь работают хуже, чем внимательный взгляд — большинство критичных проблем не укладываются в заранее придуманные пункты.
Что происходит, если пропустить этап
Последствия редко бывают катастрофическими в моменте — интерфейс не разваливается на части. Проблема в накопительном эффекте. Десяток мелких несоответствий создают ощущение сырости. Пользователь может не сформулировать, что именно не так, но почувствует, что продукт выглядит недоработанным. Даже если человек не сформулирует проблему словами, интерфейс может восприниматься менее аккуратным и завершённым.
Кроме того, технический долг по визуалу имеет свойство расти. Если не фиксировать отклонения сразу, на следующем спринте верстальщик будет ориентироваться на уже реализованную версию — с её ошибками. Через пару итераций живой интерфейс всё дальше уходит от макета настолько, что дизайн-система превращается в декорацию.
Design QA — не про перфекционизм и не про то, чтобы добиться совпадения до пикселя любой ценой. Речь о том, чтобы намерение дизайнера дошло до пользователя без искажений. Даже короткая проверка перед релизом может заметно сократить число визуальных расхождений и последующих разбирательств, сохраняя замысел команды в реализации.