Недавно жена подарила мне кофемашину De'Longhi — я давно о ней мечтал. Кофе по нажатию кнопки оказался выше всяких ожиданий. Но начать статью про UX я хочу не с восторгов, а с того, что случилось дальше.
После распаковки я скачал приложение из App Store, но войти не смог — сначала требовалась регистрация, причём только на сайте. Зарегистрировался — вошёл, но подключить кофемашину не получилось. При первичном подключении устройство предложило отсканировать QR-код, который привёл к другому приложению. В нём, как вы уже догадались, тоже можно было только войти. И тут я получил ошибку, которую, пожалуй, не видел даже в студенческих проектах: «Ваш пароль превышает допустимую длину».
Пароль сгенерировал Google: три группы по шесть символов, разделённые дефисами — всего 20. Это на два больше, чем допускает приложение De'Longhi. Про задержки интерфейса и прочие проблемы производительности поговорим в другой раз. Сейчас — только про формы и всё, что с ними связано.
Подобные истории с логином и регистрацией нередки. Многие из нас живут не в одной стране и сталкивались с невозможностью регистрации без местной SIM-карты, с запретом кириллицы в полях и другими искусственными ограничениями. Креатива в запретах хватает. Иногда зарегистрироваться удаётся только через DevTools, снимая disabled с полей.
Исследования Baymard Institute показывают: заметная доля пользователей уходит из-за слишком сложных форм; каждое лишнее поле бьёт по конверсии. Чем строже фронтенд-валидация — тем выше шанс потерять реального человека.
Слишком строгие пароли. «Пароль должен содержать заглавную букву, цифру, спецсимвол и быть длиной от 8 до 18 символов». — Почему плохо: исключаете людей без английской раскладки, усложняете ввод, искусственно режете длину. — Лучше так: минимум 8 символов, верхнего лимита нет (или ≥64); разрешайте любые символы и юникод; не навязывайте «состав пароля»; проверяйте на попадание в списки утечек.
«Умная» валидация email. Самописные регулярки на 200+ символов. — Почему плохо: блокируете валидные адреса и краевые случаи. — Лучше так: простая проверка на базовые ошибки на клиенте + корректная проверка на сервере. Не пытайтесь реализовать весь RFC регекcом.
Телефоны только в «правильном» формате. «+7 (XXX) XXX-XX-XX» и ничего больше.
— Почему плохо: люди не знают коды стран/городов и пишут как привыкли.
— Лучше так: принимайте +, цифры, пробелы, скобки и дефисы; нормализуйте до E.164 на сервере; минимум ограничений по длине (обычно 7–15 цифр).
Причин много: от университетских заданий до расплывчатых требований «провалидировать email», что на практике почти нереализуемо целиком на клиенте. Регулярные выражения для email сложны и непредсказуемы и часто блокируют валидный ввод.
Что встречается на практике:
user@example.comanna.smirnova@gmail.com (в Gmail точки игнорируются при доставке, в других сервисах — нет)andron13+shop@gmail.comuser@mail.google.coma@b.couser@example.photographyпочта@пример.рф и punycode почта@xn--e1afmkfd.xn--p1ai"john..doe"@example.com, john\.doe@example.comuser@[192.168.1.1]На практике многие системы ограничивают длину адреса примерно до 254 символов (локальная часть обычно ≤64, домен ≤255). Попытки жёстко валидировать все случаи на клиенте приводят к отказам.
Вывод: на фронте — только базовая проверка (обязательность, наличие @, грубые опечатки, отсутствие пробелов вне кавычек). Всё сложное — на сервер.
Вместо «Неверный формат email» — «Проверьте, есть ли @ в адресе».
Вместо «Пароль не соответствует требованиям» — «Добавьте ещё 3 символа».
Показывайте, что сделать, а не что запрещено. Давайте примеры правильного ввода рядом с полем. Для корректно заполненных полей — галочка или другой позитивный индикатор.
Для паролей достаточно минимальной длины от 8 символов, а верхний предел не ограничивайте искусственно. Не требуйте обязательных заглавных/цифр/символов.
Для телефонов принимайте гибкий ввод; нормализуйте и валидируйте на сервере, а не заставляйте пользователя подгонять формат.
Лучше пропустить небольшой процент некорректных данных, чем отвергнуть значимую долю настоящих пользователей. Строгая серверная валидация всё равно поймает критичные ошибки; фронтенд — про дружелюбие.
@ в адрес» лучше, чем «Неверный формат».aria-describedby и динамически объявляйте их с aria-live="polite".Проект для глобальной компании. Регистрация блокировала пользователей из Китая: форма не принимала иероглифы в имени. Решение — убрать ограничения на набор символов, оставить только проверку длины.
Аналогично с адресами: в Японии может не быть названия улицы, где-то нет индексов, где-то дома обозначают не числами. Делайте поля гибкими или опциональными.
Требовался «корректный» номер для SMS. 30% пользователей не проходили из-за строгой валидации российских форматов — часто указывали рабочие номера в другом виде.
После упрощения до «любые цифры 10–15» и серверной нормализации конверсия выросла с 12% до 19%. Недоставленных SMS больше не стало.
Магазин терял клиентов из-за форм адреса под российский формат. Исследование показало, что нужно поддерживать разные шаблоны для стран.
Решение — гибкая форма с минимумом обязательных полей: страна, город, адресная строка. Остальное — опционально и зависит от выбранной страны.
Вместо велосипеда на регулярках используйте проверенные решения.
Как выбирать библиотеку:
type="email", type="tel" — показывают подходящую клавиатуру.autocomplete помогает браузеру и менеджерам паролей.aria-describedby.@» вместо «Неверный формат»).blur, а не на каждый символ.type для мобильных и autocomplete.label.aria-describedby).aria-live.Помните: цель валидации — помочь пользователю, а не продемонстрировать наш уровень в регулярных выражениях. Каждое дополнительное ограничение — это потенциально потерянный пользователь. Лучше пропустить небольшой процент некорректных данных, чем отпугнуть значимую долю реальных людей. Строгую проверку оставьте серверу, а фронтенд сделайте дружелюбным.
И да, подключить кофемашину всё-таки удалось — после сокращения пароля. Кофе остался божественным, но осадок от первого опыта с приложением бренда — тоже. Не повторяйте этих ошибок в своих продуктах.