Как происходит ревью дизайна
Что проверяют
Участвуете ли вы в работе над интерфейсом до того, как макет стал задачей, и умеете ли спорить с дизайнером аргументами, а не вкусом. Следом обычно просят пример, когда вы нашли в макете проблему, или спрашивают, как вы договариваетесь, если дизайнер не согласен.
Как отвечать
Ревью дизайна для фронтенда бывает двух видов, стоит назвать оба.
До разработки вы смотрите макет в Figma, часто в Dev Mode, и проверяете:
- состояния: загрузка, пустой список, ошибка, hover, focus, disabled. Их забывают чаще всего;
- адаптив: как экран ведёт себя на ширине телефона и между брейкпоинтами, а не только на двух нарисованных размерах;
- реальные данные: длинные имена, перевод на другой язык, сто элементов вместо трёх;
- дизайн-система: собирается ли экран из готовых компонентов и токенов или нужен новый компонент, который потом придётся поддерживать;
- доступность: контраст по WCAG (для обычного текста не ниже 4.5:1), видимый фокус, работа с клавиатуры, подписи для скринридера;
- стоимость: какая анимация или эффект тяжелы в реализации или бьют по производительности и есть ли вариант дешевле.
После разработки дизайнер проверяет свёрстанный интерфейс на стенде или в Storybook. Расхождения заводятся задачами, а часть визуальных регрессий ловят скриншотными тестами в Playwright или Chromatic.
Вопрос поведенческий, поэтому опирайтесь на свой опыт: как был устроен процесс, какую проблему вы нашли в макете, чем закончился спор. Нужны свои примеры и детали. Если формального ревью в команде не было, так и скажите и расскажите, как вы сами собирали вопросы по макету до начала работы.
Где спотыкаются
Отвечают «мне присылают макеты, я верстаю». Это позиция исполнителя, а вопрос как раз про участие до вёрстки.
Спорят на уровне «мне так не нравится». Сильнее звучит аргумент через ограничение: пользователь с клавиатуры не увидит фокус, на узком экране кнопка уйдёт за край.
Проверяют только статичный экран на идеальных данных, а пустые состояния и ошибки находят уже в продакшене.