В проектировании сложно давать универсальные советы. Сколько задач, контекстов и целевых аудиторий — столько и решений. Поэтому вместо чек-листа с рекомендациями предлагаю вашему вниманию чек-лист с вопросами. Сегодня на повестке вопросы, которыми я задаюсь при проектировании форм регистрации пользователей (которые сами по себе могут оказаться вершинами айсберга). Для новичков контент полезный. Для продвинутых — интересный (проверьте, сколько пунктов учитываете в работе вы сами). А для профессионалов — повод показать автору, что он упустил что-то важное, и утереть ему нос. Поехали.
-
Нужна ли она (регистрация)? Можно ли воспользоваться функциями сервиса без регистрации? Какой она будет?
Предварительная регистрация. Всё закрыто до создания аккаунта
«На лету». В процессе использования сервиса. Многие функции доступны без регистрации
«Манипулятивная». Пользователю дают создать в сервисе какую-либо ценность своими руками, после чего просят зарегистрироваться, чтобы получить доступ к этой ценности
Будет ли регистрация отличаться для разных языков или регионов?
Будет ли регистрация отличаться для разных пользовательских ролей?
Нужна ли для регистрации страница с отдельным адресом или всё будет происходить в модальных окнах?
-
Каким способом регистрируем пользователя?
Закрытая по приглашениям
С помощью адреса электронной почты
По номеру телефона
-
Через соцсети
Какие конкретно? Нужно ли показывать разные для разных регионов и языков? Не забыли ли добавить примечание, что при такой регистрации пользователь всё равно соглашается с определёнными документами?
С помощью логина в свободной форме
Руками администратора через админку
Будет ли необходимость в двухфакторной защите? Будет ли она опциональной? Какого толка?
-
Какие данные собираем? Зачем? Как проверяем эти данные на достоверность? Как помогаем пользователю ввести данные правильно с первого раза?
Что делаем в сценариях, когда пользователь всё-таки ввёл свои данные неверно (например, ввёл адрес электронной почты с опечаткой или вообще чужой)?
Какие данные собираем в момент регистрации, а какие позже? На что это может повлиять?
-
Не забыли ли о данных для маркетологов?
UTM, способ регистрации, дата и время, был ли аккаунт уже зарегистрирован до этого, какой язык интерфейса у пользователя, согласился ли он на рассылку, в какую группу рассылки попал?
С какими документами пользователь должен согласиться? Как с ними можно ознакомиться? На каких они языках? Нужен ли контроль того, что пользователь действительно ознакомился с документами? Можно ли ставить галочку за пользователя? Обезличенная ли формулировка в этих соглашениях? Должен ли пользователь отдельно соглашаться на подписку на рассылку? Какая это будет конкретно рассылка? На каком языке и как его определить? Как от неё отписаться?
Нужна ли защита от ботов? Какая? Смогут ли ей воспользоваться люди с ограниченными возможностями?
Какие могут возникнуть ошибки? Где и как о них сообщать?
-
Нужна ли верификация аккаунта при регистрации? Как она будет организована? Будут ли набор функций в системе отличаться для верифицированных и неверифицированных пользователей?
Виды верификаций: автоматические, полуавтоматические, вручную. По емейлу, по открытым юридическим данным, по скану документов, по тестовому платежу и т.д.
Помешает ли регистрация целевому действию? Не окажется ли пользователь далеко от своей цели после всех процедур? Нужно ли ему авторизоваться после регистрации или это произойдёт автоматически?
В случае сложной формы регистрации может ли пользователю понадобиться помощь оператора?
Какое письмо получит пользователь после регистрации? Какое там будет послание? Какое целевое действие? Будет ли там сообщение для тех, кто получил его по ошибке?
Сможет ли пользователь зарегистрироваться, если он удалял свой аккаунт в прошлом? Будут ли при этом какие-то особенности? Например, будет ли ему снова доступен триал? Какая информация в его личном кабинете будет восстановлена? Насколько это законно?
Сможет ли пользователь зарегистрироваться, если его аккаунт был забанен и он его удалил?
Вот и весь чек-лист! Он у меня есть в гугл.доке, если вам так будет удобнее. У меня в Проекторате был выставлен на продажу видеокурс по этому чек-листу. Я там каждый пункт разжёвывал и показывал живые примеры. Но спроса на него не было, поэтому я снял его с продажи, равно как и все остальные свои видеокурсы. Можете смотреть бесплатно, вот он:
Если захотите меня отблагодарить, то достаточно будет подписаться на паблик Проектората Вконтакте или канал в Телеграме. Возможно, скоро буду делать набор в четвёртый поток курса по проектированию интерфейсов (как писать функциональные требования, как делать интерактивные прототипы, как описывать их в функциональных спецификациях, вот это всё). А может и не буду. От спроса будет зависеть. Сейчас эти курсов — как грязи. Если заинтересуетесь, — стучитесь в личку. Не уверен, что дал в этой статье достаточно пользы, чтобы претендовать на рекламу.
Если не нашли в чек-листе чего-то важного — пишите об этом в комментах. Добавим в доку, принесём ещё больше пользы.
Комментарии (12)
Mike-M
13.06.2022 00:36Тестировщикам тоже полезно будет, спасибо!
Ekamelev Автор
13.06.2022 00:49Пожалуйста! Полезно будет любому, кто участвует в контроле работы проектировщиков. Многие пункты из чек-листа зачастую ложатся на плечи аналитиков, а не UX/UI дизайнеров. Проектировщики Проектората стараются охватывать все эти направления сразу.
DrinkFromTheCup
Я чисто уточнить, а разве есть ситуации, когда с точки зрения пользователя такой подход к процессу регистрации воспринимается адекватно?
Ekamelev Автор
«Пользователь» — это очень широкое понятие. «Адекватность» — тоже. И даже «процесс регистрации». Всегда проще общаться, когда есть конкретный пример. Например, вы зашли на сайт, где можно заказать пиццу. Наполнили корзину: положили туда пиццу, напиток и десерт (создали ценность). А на шаге с оформлением заказа вас просят указать номер телефона, чтобы зарегистрировать вас в системе и подтвердить заказ. Вы адекватно воспримете такой подход к процессу регистрации?
DrinkFromTheCup
Скорее нет, чем да.
Отвлекать пользователя на шаге оплаты от процесса оплаты - нельзя. Совсем нельзя. Это рушит работу с импульсивными покупками, для начала.
Ekamelev Автор
При чём здесь шаг с оплатой? В моём примере речь шла об оформлении заказа. Оплату вы могли указать в той же форме. И это могло быть, например, «наличными курьеру».
Всё-таки без картинок и контекста очень абстрактная это штука — проектирование.
DrinkFromTheCup
Вы знаете, причём здесь оплата - это очень долгая история.
Если очень кратенько и утрированно, оформление заказа - это как бы обязательство одной стороны поставить, а второй получить и оплатить товар. Это можно было бы назвать совершением сделки - но это будет не совсем корректно. Что отдельная, долгая история.
И, знаете, не я выбрал этот пример. Выбрали Вы. Я бы предпочёл всё же увидеть Ваши аргументы прежде, чем продолжать тыкаться вслепую, выясняя, что же Вы имели в виду.
Вы считаете, что акт заказа пиццы с доставкой создаёт для пользователя ценность достаточную, чтобы он мог себе позволить отвлечься от процедуры заказа на форму регистрации. Вместо того, чтобы собственно заказать пиццу.
Почему?
Ekamelev Автор
Вы спросили, когда такой подход к процессу («манипулятивная регистрация») воспринимается пользователями адекватно. Я привёл пример, когда лично я воспринимаю такой подход адекватно. Заказывая пиццу в Оллисе, Ями-Ями, Достаевском, Пицца-Хате и Двух Берегах, я сталкивался с таким сценарием.
Создатели этих сервисов выбирали между двумя вариантами. 1 — не давать неавторизованным пользователям класть товары в корзину, пока они не зарегистрируются (или авторизуются). 2 — регистрировать пользователей, когда корзина уже наполнена, а значит и мотивации закончить этот процесс прибавится. Выбрали второй. Скорее всего потому что он более конверсионный и логичный. Варианта не регистрировать пользователя в системе у этих компаний не существует.
Я не считаю, «…что акт заказа пиццы с доставкой создаёт для пользователя ценность достаточную, чтобы он мог себе позволить отвлечься от процедуры заказа на форму регистрации. Вместо того, чтобы собственно заказать пиццу». Я вообще писал не об этом. А привёл распространённый пример «манипулятивной» регистрации, который сам воспринимаю адекватно.
DrinkFromTheCup
То, что этим подходом пользуются, не означает, что он работает, как ожидается. Есть подозрение, что статистика по брошенным корзинам у них не самая радующая глаз.
Впрочем, я уже смирился с тем, что на стыке торговли и IT творится какой-то первородный хаос. Переубеждать тут бесполезно, наверное.
arctic-hare
а второй получить и оплатить товар.
Что бы выполнить эту обязанность второй стороны, как раз необходим подтвержденный номер телефона.
Кроме этого, это избавляет компанию от проблемы фейковых заказов. Например в сексшопах 5% всех заказов это фейки от всяких дурачков или школьников. Если их все возить, то разоришься.