Дизайн-ревью макета: пошаговая проверка перед передачей в разработку

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

Хороший самостоятельный просмотр файла перед передачей - это не формальность. Это способ поймать 80% типичных проблем за 30-40 минут, пока они ещё у вас, а не у разработчика. Статья про хендоф уже есть на блоге HireHi - она о том, как передавать файлы команде. Эта статья - про шаг раньше: что именно проверить в макете до того, как вы вообще откроете ссылку для доступа.

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

Шаг 1. Структура файла и порядок на канвасе

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

• Все нерелевантные версии и черновики вынесены на отдельную страницу или удалены.
• Артборды названы понятно: не «Frame 47», а «Главная / Desktop / Default».
• Если есть несколько брейкпоинтов - они сгруппированы вместе и расположены логично (например, слева направо по убыванию ширины).
• Слои внутри артбордов имеют читаемые имена. Вложенность не превышает разумного уровня.

Это занимает 5-10 минут, но экономит значительно больше времени при передаче.

Шаг 2. Консистентность компонентов

Это один из самых частых источников правок. Дизайнер работает над несколькими экранами, где-то случайно detach-нул компонент и изменил отступ, где-то вручную перекрасил кнопку. Разработчик реализует то, что видит - и получается непоследовательный интерфейс.

Что проверять:

• Все кнопки, инпуты, теги, карточки - это компоненты из библиотеки, а не локальные копии с ручными изменениями.
• Если компонент был намеренно изменён (override), это задокументировано и понятно, почему именно здесь исключение.
• Одинаковые элементы на разных экранах выглядят одинаково: одна высота строки, одни отступы, одна иконка для одного действия.

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

Шаг 3. Токены и стили

Даже если компоненты на месте, отдельные элементы могут использовать «не те» цвета или шрифты - например, захардкоженный hex вместо токена, или font-weight, выбранный вручную.

Что проверить в рамках quality check ui:

• Все цвета привязаны к переменным или стилям, а не заданы вручную.
• Шрифтовые стили - из библиотеки типографики, а не подобраны «на глаз».
• Тени, скругления, spacing - берутся из дизайн-системы, если она есть.
• Нет случайных значений вроде 13px, 7px, rgba(0,0,0,0.37) без смысла.

Шаг 4. Покрытие состояний

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

Минимальный набор состояний, который стоит проверить для каждого ключевого элемента:

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

Шаг 5. Длинные тексты и крайние значения

Макет выглядит идеально с названием «Иван Иванов» и коротким описанием. В реальном продукте появляется «Александра Константинопольская» и описание на три абзаца.

Что тестировать:

• Как ведёт себя заголовок карточки при тексте вдвое длиннее?
• Есть ли ограничение строк (line-clamp) и что происходит за его пределами?
• Не съезжает ли лейаут, если в таблице одна ячейка вдруг очень широкая?
• Числа: отображение нуля, однозначного числа, пятизначного, отрицательного.

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

Шаг 6. Адаптив и брейкпоинты

Проверка макета перед разработкой неполна без просмотра на реальных размерах. Даже если вы делаете только веб, браузеры открывают страницы не только на 1440px.

Что смотреть:

• Все заявленные брейкпоинты существуют в файле (обычно 375px, 768px, 1280px или 1440px - зависит от проекта).
• На мобильном ни один элемент не выходит за пределы экрана и не перекрывается.
• Касаемые зоны кнопок и ссылок на мобильном - не меньше 44x44px (рекомендация Apple HIG и Google Material).
• Переносы текста выглядят корректно на всех размерах: нет висящих предлогов или оборванных смыслов в одну букву.

Удобный приём - включить в Figma Layout Grid для каждого брейкпоинта и пройтись по экранам не с высоты птичьего полёта, а в режиме просмотра на ширине этого устройства.

Шаг 7. Доступность и контраст

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

• Контраст текста на фоне соответствует WCAG AA: 4.5:1 для обычного текста, 3:1 для крупного (18px+ или 14px+ bold).
• Информация не передаётся только через цвет: рядом есть иконка, текст или другой визуальный маркер.
• Интерактивные элементы визуально отличаются от нефункциональных.

В Figma проверить контраст можно плагином Contrast или A11y Annotation Kit.

Шаг 8. Именование и аннотации

Разработчику нужно понять не только как выглядит макет, но и как он должен работать. Визуал отвечает на вопрос «что», а аннотации - на вопрос «почему именно так» и «что происходит при взаимодействии».

Перед хендофом стоит убедиться:

• Взаимодействия, которые не очевидны из визуала, прокомментированы: «при клике открывается drawer справа», «поле валидируется onBlur, не onChange».
• Анимации описаны хотя бы кратко, если они есть: easing, длительность, триггер.
• Нестандартные технические решения отмечены: «здесь sticky header», «этот блок скроллится независимо».
• Все условия видимости элементов понятны: «кнопка появляется только для роли Admin».

Шаг 9. Прогон по сценариям

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

Сценарии для прогона:

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

После прогона обычно появляется 2-5 мест, которые при статичной проверке казались нормальными, но в движении не работают.

Типичные ошибки в макетах, которые всплывают только перед передачей

Это не абстрактный список «будьте внимательны». Это конкретные находки, которые регулярно появляются при самопроверке.

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

Используйте этот список перед каждым хендофом. Адаптируйте под проект - не все пункты актуальны для каждой задачи.

Когда такая проверка не нужна

Не каждый файл требует полного прогона по всему списку. Есть ситуации, когда достаточно сокращённой версии.

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

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

Как расставить приоритеты, если времени мало

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

Три вещи, которые стоит проверить в первую очередь, даже если больше ни на что нет времени:

• Состояния ключевых интерактивных элементов. Пропущенный disabled или отсутствующая ошибка у формы вызовут вопросы сразу же.
• Мобильный артборд. Если он вообще есть - откройте его и убедитесь, что ничего не обрезается и не перекрывается.
• Именование артбордов. Разработчику нужно понять, что актуально, а что черновик. Это правка на 3 минуты, которая экономит 15 минут объяснений.

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

Как работать с командой во время проверки

Self-review - это индивидуальный процесс, но он не должен быть полностью изолированным. Несколько приёмов, которые помогают сделать проверку эффективнее без лишних созвонов:

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

Что делать с находками: исправлять или документировать

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

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