Как валидировать работу дизайнера

Что проверяют

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

Как отвечать

Разведите две вещи. Проверка на соответствие требованиям (верификация) это зона аналитика. Проверка, решает ли дизайн задачу пользователя (валидация), идёт через исследования и метрики, и аналитик участвует в ней вместе с продактом и UX-исследователем.

Каркас ответа:

• трассировка: каждый экран в Figma привязан к user story или use case, каждый основной и альтернативный сценарий где-то нарисован. Пробел в сценарии виден сразу;
• состояния: пустой список, загрузка, ошибка сервера, нет прав, очень длинные данные, первый вход. Чаще всего нарисован только удачный путь;
• данные и правила: поля с макета есть в API или модели данных, совпадают форматы, обязательность, длины, правила валидации и тексты ошибок;
• ограничения: роли и доступы, требования к доступности, соответствие дизайн-системе;
• процесс: дизайн-ревью с аналитиком, разработчиком и тестировщиком до передачи в разработку, замечания комментариями в макете, критерии приёмки в задаче;
• после запуска: юзабилити-тест прототипа, а в проде воронка и конверсия ключевого шага.

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

Где спотыкаются

Оценивают по вкусу: «кнопка некрасивая». Замечание аналитика должно ссылаться на требование, сценарий или данные.

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

Подключаются после того, как макет ушёл разработчикам. Тогда валидация превращается в список переделок, а не в часть процесса.