Регистрация — место, где теряется больше всего людей. Каждое лишнее поле, непонятное требование к паролю и отсутствие объяснения, зачем всё это нужно, стоит части пользователей. Разбираем форму по шагам: когда регистрация вообще нужна, что спрашивать сразу, как проверять данные, что показывать после и как найти собственные потери.
Нужна ли регистрация вообще
Первый вопрос, который мы задаём на проектировании: что ломается, если человек не зарегистрируется. Часто выясняется, что ничего. Магазину для оформления заказа достаточно контактов и адреса доставки, а учётную запись можно создать автоматически по почте после оплаты и предложить задать пароль в письме.
- Гостевой заказ. Оформление без пароля — самый простой способ убрать барьер перед оплатой. Данные при этом собираются те же.
- Отложенная регистрация. Аккаунт предлагается после первого успешного действия, когда ценность уже видна.
- Обязательная регистрация. Оправдана там, где без учётной записи нет смысла: личный кабинет, подписка, доступ к документам, сохранение истории.
Если регистрация обязательна, рядом с формой стоит одной строкой объяснить, что человек получит внутри. «Создайте аккаунт» — не причина, «сохраним историю заказов и адреса доставки» — причина.
Какие данные спрашивать сразу и какие потом
На старте нужен минимум: почта или телефон и способ входа. Имя, компания, должность, отрасль, сфера интересов — всё это можно спросить позже, когда человек уже пользуется сервисом. Каждое поле в форме должно отвечать на вопрос «что сломается, если его убрать».
Полезный приём — разделить данные на три группы: нужны для входа, нужны для первой операции, нужны для отчётности. В форму регистрации попадает только первая группа. Вторая запрашивается в момент, когда она действительно нужна: адрес — при оформлении доставки, реквизиты — при выставлении счёта. Третья собирается в профиле и не блокирует работу.
Что чаще всего мешает
| Проблема | Что делать |
|---|---|
| Много полей | Оставить необходимое для входа, остальное перенести в профиль или в момент операции |
| Скрытые требования к паролю | Показать правила до ввода и подсвечивать выполнение по мере набора |
| Повтор пароля | Заменить кнопкой «показать пароль» |
| Ошибка появляется только после отправки | Проверять поле при выходе из него, а не при каждом нажатии клавиши |
| Непонятно, зачем данные | Короткое пояснение рядом с полем, а не в подсказке при наведении |
| Капча на входе | Показывать только при подозрительном поведении, а не всем подряд |
| Автозаполнение не срабатывает | Проставить корректные типы полей и атрибуты автозаполнения |
| Кнопка неактивна без объяснения | Оставить кнопку активной и показать, какое поле мешает отправке |
| Форма сбрасывается при ошибке | Сохранять введённое, подсвечивать только проблемное поле |
| Неясно, отправлено письмо или нет | Показать состояние отправки и обратный отсчёт до повторной попытки |
Пароль и вход по коду
Требования к паролю разумно свести к длине и проверке по списку скомпрометированных сочетаний. Правила вида «одна заглавная, одна цифра и один спецсимвол» люди обходят предсказуемым образом, а запомнить такой пароль сложнее. Правила показываем до ввода и отмечаем выполнение прямо по ходу набора.
Вход по одноразовому коду на почту или телефон убирает пароль совсем. У него свои условия: код должен быть коротким, поле — принимать вставку из буфера целиком, а повторная отправка — становиться доступной через понятный интервал с видимым таймером. Если код приходит в СМС, поле должно позволять автоподстановку.
Вход через сторонние сервисы упрощает первый шаг, но добавляет зависимость и вопросы к обработке данных. Если такой способ есть, оставьте рядом и обычный вход по почте: часть людей не станет связывать рабочий аккаунт со сторонним сервисом. И обязательно покажите на форме входа, каким способом человек регистрировался в прошлый раз, — иначе он создаст второй аккаунт на ту же почту и потеряет свою историю.
Проверка полей и тексты ошибок
Проверяем в момент выхода из поля: человек дописал почту, перевёл фокус — и сразу видит результат. Проверка на каждом символе показывает ошибку раньше, чем ввод закончен, и только мешает. Сообщение остаётся рядом с полем, пока проблема не исправлена, а не исчезает при первом нажатии клавиши.
«Неверные данные» бесполезно. Работает конкретика: «Такой почты у нас нет — проверьте адрес или зарегистрируйтесь». В тексте ошибки должно быть три вещи: что не так, где именно и что сделать. Отдельный случай — уже занятая почта: правильный ответ здесь предлагает вход и восстановление пароля, а не просто сообщает об отказе.
Мобильные особенности
- Тип поля задаёт клавиатуру: для почты — с собакой, для телефона — цифровая, для кода — числовая.
- Автозаполнение из менеджера паролей не должно ломаться нестандартными полями и разбивкой кода на отдельные ячейки.
- Поле не должно оставаться под всплывающей клавиатурой — страница прокручивается к активному полю.
- Кнопка отправки — во всю ширину и в нижней зоне экрана, куда достаёт большой палец.
- Маска телефона не должна мешать вставке номера из буфера в другом формате.
- Ссылка на политику обработки данных открывается отдельно и не уводит с заполненной формы.
Подтверждение и согласие на обработку данных
Если нужна проверка почты или телефона, предупредите об этом до отправки формы и напишите, что делать, если письмо не пришло: проверить папку со спамом, запросить повторно, написать в поддержку. Плохой вариант — оставить человека на странице «Мы отправили вам письмо» без выхода.
Чекбокс согласия на обработку персональных данных не должен быть отмечен заранее: согласие даёт человек, а не форма. Рядом — ссылка на политику. Без отметки отправка не проходит, и об этом сообщается так же явно, как о любой другой незаполненной обязательной части формы.
Первый экран после регистрации и замер воронки
После регистрации человек должен сразу оказаться внутри и увидеть, что делать дальше, а не на пустой странице с надписью «Добро пожаловать». Хороший первый экран показывает одно ближайшее действие: заполнить профиль, создать первый проект, вернуться к заказу, ради которого всё и начиналось.
Чтобы понимать свои потери, разметьте шаги отдельными событиями: открыли форму, начали заполнять, отправили, подтвердили почту, выполнили первое действие. Самый большой провал между соседними шагами и есть место, которое нужно упрощать в первую очередь. Полезно отдельно считать ошибки проверки по полям — поле, на котором ошибаются чаще всего, обычно сформулировано неудачно.
Если форма собирает меньше, чем должна, мы разберём её по шагам и перестроим сценарий: проектирование интерфейсов. Начинаем с разбора текущей воронки и данных аналитики.
