Какие проблемы могут быть в макете формы регистрации для обсуждения с дизайнером?

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

Умеете ли вы читать макет глазами того, кто будет его реализовывать, и находить недостающее до начала вёрстки. Второе, что оценивают, это тон: вы приходите к дизайнеру с вопросами и аргументами, а не с претензиями. Следом спрашивают, как договориться, если дизайнер не согласен.

Как отвечать

Пройдитесь по тому, чего в макете чаще всего нет:

• состояния полей: фокус, ошибка, заблокированное поле, автозаполнение браузера, длинный текст. Обычно нарисованы только пустое и заполненное;
• валидация: где и когда показывается ошибка (при уходе с поля, а не на каждый символ), как выглядит ответ сервера вроде «почта уже занята»;
• подписи: плейсхолдер вместо <label> исчезает при вводе и плохо читается экранными дикторами. Подпись должна быть видимой и связанной с полем;
• пароль: требования видны до ввода, есть кнопка «показать пароль», вставка не запрещена, а поле подтверждения часто можно убрать;
• клавиатуры и автозаполнение: type="email", inputmode, правильный autocomplete (email, new-password), чтобы работали менеджеры паролей;
• лишние поля: каждое поле снижает конверсию. Спросите, что нужно именно на регистрации, а что можно запросить позже;
• мобильная версия и доступность: область касания (Apple рекомендует 44 на 44 точки), контраст, ошибка обозначена не только цветом, логичный порядок фокуса;
• отправка: состояние загрузки кнопки, защита от повторного нажатия, куда ведёт успешная регистрация и нужно ли подтверждать почту;
• юридическое: отдельное согласие на обработку персональных данных по 152-ФЗ.

Подавайте это вопросами: «как выглядит ошибка сервера?» работает лучше, чем «вы забыли ошибки».

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

Говорят только про визуал: шрифты, отступы, цвета. Интервьюер ждёт, что вы увидите недостающие состояния и сценарии.

Предлагают валидацию на каждый символ. Ошибка «некорректная почта» после первой буквы раздражает, поэтому её показывают после ухода с поля или при отправке.

Приходят к дизайнеру с готовым решением вместо проблемы. Лучше опереться на данные или стандарт (WCAG, поведение менеджеров паролей) и оставить визуальное решение за ним.