Участвует ли дизайн в тестировании верстки, анимаций и адаптивности
Что проверяют
Если вопрос задаёте вы, интервьюер оценивает его как признак опыта: человек знает, что свёрстанный экран возвращается на проверку дизайнеру. Если спрашивают вас, смотрят, как был устроен приём работы на прошлом месте и понимаете ли вы, что проверять.
Как отвечать
Опишите дизайн-ревью как отдельный этап приёмки, рядом с код-ревью и проверкой тестировщиком. Дизайнер смотрит собранную ветку на стенде, а не скриншот: на скриншоте не видно ни поведения при изменении ширины, ни анимации, ни состояния фокуса.
Перечислите, что попадает в проверку: соответствие макету по отступам и типографике, состояния экрана (загрузка, пусто, ошибка, очень длинный текст), поведение между точками перелома, а не только на трёх ширинах из макета, тайминги и кривые анимаций, работа с клавиатуры.
Обязательно про границу разумного. Совпадение до пикселя недостижимо: разные шрифты, сглаживание, масштабирование системы. Спасают общие токены: шкала отступов, размеры шрифта, цвета, тени. Когда и макет, и код собраны из одних значений, спорить становится не о чем.
Про анимации добавьте уважение к настройке уменьшенного движения и к производительности: анимируем трансформацию и прозрачность, а не свойства, вызывающие пересчёт раскладки.
Если вопрос ваш, уточните, есть ли дизайн-система, на каком этапе подключается дизайнер и кто принимает решение в споре. Ответ «дизайнер смотрит уже после выката» говорит о процессе больше, чем вся остальная беседа.
Где спотыкаются
Воспринимают замечания как придирки и спорят про каждый отступ. Проблему решает не спор, а перевод макета и кода на общие токены.
Отдают на проверку только удачный сценарий на одном разрешении. Пустой список, ошибка загрузки и длинное имя пользователя всплывают уже у реальных людей.
Зовут дизайнера в самом конце, когда всё собрано. На этом этапе любая правка раскладки стоит дорого, и половина замечаний просто уходит в бэклог навсегда.