В проектировании сложно давать универсальные советы. Сколько задач, контекстов и целевых аудиторий — столько и решений. Поэтому вместо чек-листа с рекомендациями предлагаю вашему вниманию чек-лист с вопросами. Сегодня на повестке вопросы, которыми я задаюсь при проектировании форм регистрации пользователей (которые сами по себе могут оказаться вершинами айсберга). Для новичков контент полезный. Для продвинутых — интересный (проверьте, сколько пунктов учитываете в работе вы сами). А для профессионалов — повод показать автору, что он упустил что-то важное, и утереть ему нос. Поехали.

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

    • Предварительная регистрация. Всё закрыто до создания аккаунта

    • «На лету». В процессе использования сервиса. Многие функции доступны без регистрации

    • «Манипулятивная». Пользователю дают создать в сервисе какую-либо ценность своими руками, после чего просят зарегистрироваться, чтобы получить доступ к этой ценности

  • Будет ли регистрация отличаться для разных языков или регионов?

  • Будет ли регистрация отличаться для разных пользовательских ролей?

  • Нужна ли для регистрации страница с отдельным адресом или всё будет происходить в модальных окнах?

  • Каким способом регистрируем пользователя?

    • Закрытая по приглашениям

    • С помощью адреса электронной почты

    • По номеру телефона

    • Через соцсети

      • Какие конкретно? Нужно ли показывать разные для разных регионов и языков? Не забыли ли добавить примечание, что при такой регистрации пользователь всё равно соглашается с определёнными документами?

    • С помощью логина в свободной форме

    • Руками администратора через админку

  • Будет ли необходимость в двухфакторной защите? Будет ли она опциональной? Какого толка?

  • Какие данные собираем? Зачем? Как проверяем эти данные на достоверность? Как помогаем пользователю ввести данные правильно с первого раза?

    • Что делаем в сценариях, когда пользователь всё-таки ввёл свои данные неверно (например, ввёл адрес электронной почты с опечаткой или вообще чужой)?

    • Какие данные собираем в момент регистрации, а какие позже? На что это может повлиять?

  • Не забыли ли о данных для маркетологов?

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

  • С какими документами пользователь должен согласиться? Как с ними можно ознакомиться? На каких они языках? Нужен ли контроль того, что пользователь действительно ознакомился с документами? Можно ли ставить галочку за пользователя? Обезличенная ли формулировка в этих соглашениях? Должен ли пользователь отдельно соглашаться на подписку на рассылку? Какая это будет конкретно рассылка? На каком языке и как его определить? Как от неё отписаться?

  • Нужна ли защита от ботов? Какая? Смогут ли ей воспользоваться люди с ограниченными возможностями?

  • Какие могут возникнуть ошибки? Где и как о них сообщать?

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

    • Виды верификаций: автоматические, полуавтоматические, вручную. По емейлу, по открытым юридическим данным, по скану документов, по тестовому платежу и т.д.

  • Помешает ли регистрация целевому действию? Не окажется ли пользователь далеко от своей цели после всех процедур? Нужно ли ему авторизоваться после регистрации или это произойдёт автоматически?

  • В случае сложной формы регистрации может ли пользователю понадобиться помощь оператора?

  • Какое письмо получит пользователь после регистрации? Какое там будет послание? Какое целевое действие? Будет ли там сообщение для тех, кто получил его по ошибке?

  • Сможет ли пользователь зарегистрироваться, если он удалял свой аккаунт в прошлом? Будут ли при этом какие-то особенности? Например, будет ли ему снова доступен триал? Какая информация в его личном кабинете будет восстановлена? Насколько это законно?

  • Сможет ли пользователь зарегистрироваться, если его аккаунт был забанен и он его удалил?

Вот и весь чек-лист! Он у меня есть в гугл.доке, если вам так будет удобнее. У меня в Проекторате был выставлен на продажу видеокурс по этому чек-листу. Я там каждый пункт разжёвывал и показывал живые примеры. Но спроса на него не было, поэтому я снял его с продажи, равно как и все остальные свои видеокурсы. Можете смотреть бесплатно, вот он:

Если захотите меня отблагодарить, то достаточно будет подписаться на паблик Проектората Вконтакте или канал в Телеграме. Возможно, скоро буду делать набор в четвёртый поток курса по проектированию интерфейсов (как писать функциональные требования, как делать интерактивные прототипы, как описывать их в функциональных спецификациях, вот это всё). А может и не буду. От спроса будет зависеть. Сейчас эти курсов — как грязи. Если заинтересуетесь, — стучитесь в личку. Не уверен, что дал в этой статье достаточно пользы, чтобы претендовать на рекламу.

Если не нашли в чек-листе чего-то важного — пишите об этом в комментах. Добавим в доку, принесём ещё больше пользы.

Комментарии (12)


  1. DrinkFromTheCup
    11.06.2022 13:48
    -1

    «Манипулятивная». Пользователю дают создать в сервисе какую-либо ценность своими руками, после чего просят зарегистрироваться, чтобы получить доступ к этой ценности

    Я чисто уточнить, а разве есть ситуации, когда с точки зрения пользователя такой подход к процессу регистрации воспринимается адекватно?


    1. Ekamelev Автор
      11.06.2022 15:20
      +2

      «Пользователь» — это очень широкое понятие. «Адекватность» — тоже. И даже «процесс регистрации». Всегда проще общаться, когда есть конкретный пример. Например, вы зашли на сайт, где можно заказать пиццу. Наполнили корзину: положили туда пиццу, напиток и десерт (создали ценность). А на шаге с оформлением заказа вас просят указать номер телефона, чтобы зарегистрировать вас в системе и подтвердить заказ. Вы адекватно воспримете такой подход к процессу регистрации?


      1. DrinkFromTheCup
        11.06.2022 15:25

        Скорее нет, чем да.

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


        1. Ekamelev Автор
          11.06.2022 15:30

          При чём здесь шаг с оплатой? В моём примере речь шла об оформлении заказа. Оплату вы могли указать в той же форме. И это могло быть, например, «наличными курьеру».

          Всё-таки без картинок и контекста очень абстрактная это штука — проектирование.


          1. DrinkFromTheCup
            11.06.2022 15:55

            Вы знаете, причём здесь оплата - это очень долгая история.

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

            И, знаете, не я выбрал этот пример. Выбрали Вы. Я бы предпочёл всё же увидеть Ваши аргументы прежде, чем продолжать тыкаться вслепую, выясняя, что же Вы имели в виду.

            Вы считаете, что акт заказа пиццы с доставкой создаёт для пользователя ценность достаточную, чтобы он мог себе позволить отвлечься от процедуры заказа на форму регистрации. Вместо того, чтобы собственно заказать пиццу.

            Почему?


            1. Ekamelev Автор
              11.06.2022 23:54
              +2

              Вы спросили, когда такой подход к процессу («манипулятивная регистрация») воспринимается пользователями адекватно. Я привёл пример, когда лично я воспринимаю такой подход адекватно. Заказывая пиццу в Оллисе, Ями-Ями, Достаевском, Пицца-Хате и Двух Берегах, я сталкивался с таким сценарием.

              Создатели этих сервисов выбирали между двумя вариантами. 1 — не давать неавторизованным пользователям класть товары в корзину, пока они не зарегистрируются (или авторизуются). 2 — регистрировать пользователей, когда корзина уже наполнена, а значит и мотивации закончить этот процесс прибавится. Выбрали второй. Скорее всего потому что он более конверсионный и логичный. Варианта не регистрировать пользователя в системе у этих компаний не существует.

              Я не считаю, «…что акт заказа пиццы с доставкой создаёт для пользователя ценность достаточную, чтобы он мог себе позволить отвлечься от процедуры заказа на форму регистрации. Вместо того, чтобы собственно заказать пиццу». Я вообще писал не об этом. А привёл распространённый пример «манипулятивной» регистрации, который сам воспринимаю адекватно.


              1. DrinkFromTheCup
                12.06.2022 11:49

                То, что этим подходом пользуются, не означает, что он работает, как ожидается. Есть подозрение, что статистика по брошенным корзинам у них не самая радующая глаз.

                Впрочем, я уже смирился с тем, что на стыке торговли и IT творится какой-то первородный хаос. Переубеждать тут бесполезно, наверное.


            1. arctic-hare
              12.06.2022 12:39

              а второй получить и оплатить товар.

              Что бы выполнить эту обязанность второй стороны, как раз необходим подтвержденный номер телефона.

              Кроме этого, это избавляет компанию от проблемы фейковых заказов. Например в сексшопах 5% всех заказов это фейки от всяких дурачков или школьников. Если их все возить, то разоришься.


  1. DrinkFromTheCup
    11.06.2022 15:53

    delete please

    (за что ж мобильная вьюха так меня не любит...)


  1. splank
    12.06.2022 00:12

    /


  1. Mike-M
    13.06.2022 00:36

    Тестировщикам тоже полезно будет, спасибо!


    1. Ekamelev Автор
      13.06.2022 00:49

      Пожалуйста! Полезно будет любому, кто участвует в контроле работы проектировщиков. Многие пункты из чек-листа зачастую ложатся на плечи аналитиков, а не UX/UI дизайнеров. Проектировщики Проектората стараются охватывать все эти направления сразу.