Комментарии 13
«Манипулятивная». Пользователю дают создать в сервисе какую-либо ценность своими руками, после чего просят зарегистрироваться, чтобы получить доступ к этой ценности
Я чисто уточнить, а разве есть ситуации, когда с точки зрения пользователя такой подход к процессу регистрации воспринимается адекватно?
«Пользователь» — это очень широкое понятие. «Адекватность» — тоже. И даже «процесс регистрации». Всегда проще общаться, когда есть конкретный пример. Например, вы зашли на сайт, где можно заказать пиццу. Наполнили корзину: положили туда пиццу, напиток и десерт (создали ценность). А на шаге с оформлением заказа вас просят указать номер телефона, чтобы зарегистрировать вас в системе и подтвердить заказ. Вы адекватно воспримете такой подход к процессу регистрации?
Скорее нет, чем да.
Отвлекать пользователя на шаге оплаты от процесса оплаты - нельзя. Совсем нельзя. Это рушит работу с импульсивными покупками, для начала.
При чём здесь шаг с оплатой? В моём примере речь шла об оформлении заказа. Оплату вы могли указать в той же форме. И это могло быть, например, «наличными курьеру».
Всё-таки без картинок и контекста очень абстрактная это штука — проектирование.
Вы знаете, причём здесь оплата - это очень долгая история.
Если очень кратенько и утрированно, оформление заказа - это как бы обязательство одной стороны поставить, а второй получить и оплатить товар. Это можно было бы назвать совершением сделки - но это будет не совсем корректно. Что отдельная, долгая история.
И, знаете, не я выбрал этот пример. Выбрали Вы. Я бы предпочёл всё же увидеть Ваши аргументы прежде, чем продолжать тыкаться вслепую, выясняя, что же Вы имели в виду.
Вы считаете, что акт заказа пиццы с доставкой создаёт для пользователя ценность достаточную, чтобы он мог себе позволить отвлечься от процедуры заказа на форму регистрации. Вместо того, чтобы собственно заказать пиццу.
Почему?
Вы спросили, когда такой подход к процессу («манипулятивная регистрация») воспринимается пользователями адекватно. Я привёл пример, когда лично я воспринимаю такой подход адекватно. Заказывая пиццу в Оллисе, Ями-Ями, Достаевском, Пицца-Хате и Двух Берегах, я сталкивался с таким сценарием.
Создатели этих сервисов выбирали между двумя вариантами. 1 — не давать неавторизованным пользователям класть товары в корзину, пока они не зарегистрируются (или авторизуются). 2 — регистрировать пользователей, когда корзина уже наполнена, а значит и мотивации закончить этот процесс прибавится. Выбрали второй. Скорее всего потому что он более конверсионный и логичный. Варианта не регистрировать пользователя в системе у этих компаний не существует.
Я не считаю, «…что акт заказа пиццы с доставкой создаёт для пользователя ценность достаточную, чтобы он мог себе позволить отвлечься от процедуры заказа на форму регистрации. Вместо того, чтобы собственно заказать пиццу». Я вообще писал не об этом. А привёл распространённый пример «манипулятивной» регистрации, который сам воспринимаю адекватно.
а второй получить и оплатить товар.
Что бы выполнить эту обязанность второй стороны, как раз необходим подтвержденный номер телефона.
Кроме этого, это избавляет компанию от проблемы фейковых заказов. Например в сексшопах 5% всех заказов это фейки от всяких дурачков или школьников. Если их все возить, то разоришься.
delete please
(за что ж мобильная вьюха так меня не любит...)
/
Немалую проблему может создать регистрация по телефону. Имеет смысл её отдельно разбирать.
Очевидно, что регистрация идёт по мобильному телефону. Но клиент может ввести и городской. Надо учитывать этот вариант при инструкции и валидации.
Код региона. Не всегда он определяется по гео корректно. Поэтому надо выводить определившийся регион, но давать возможность выбирать.
По поводу языков тоже есть нюансы. Например, в Канаде наравне с английским используется и французский язык. Надо учитывать подобные связки регионов и языков.
Чек-лист по проектированию регистрации