盘点【注册、登录】产品设计路上爬过的坑

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

zhucesheji

作为最基础的常备功能, 注册/登录往往是产品第一个版本中最容易被忽视的环节,越是看似容易,陷阱越多;介绍相关产品思路的文章很多,讲交互的多,结合运营的少;本文更多的是记录那些坑坑洼洼,希望对大家有帮助。

1.0非常基础

1.1因「私有化」而存在

不是所有的产品都需要注册/登录,除非[私有内容/私有操作]具有足够的吸引力。

  • 注册:用户告诉系统Who is Tom;系统记录Tom和口令;
  • 登录:用户告诉系统I am Tom;系统辨别Tom和口令;

1.2Passport产品线及近亲

通常把注册、登录、找回密码、修改密码、账户关联这几件事归为Passport产品线;它的近亲是Profile产品线,包含用户资料、个人设置等。

1.3登录是高频,其他是低频

注册、找回密码、修改密码都是低频操作,但都属于迫切程度比较高,也最容易引发挫败感,导致用户投诉及放弃使用产品。

1.4术语:查重、校验、验证、匹配

  • 查重,“查询是否有重复存在”的简称,比如:排除以手机为主键的重复注册;
  • 校验,检查数据是否符合格式,比如:输入的时候为一个手机号码;
  • 验证,确认真实性,比如手机和邮箱真的是用户本人使用,指纹、人脸识别;
  • 匹配,用户提交的数据是否与存储中的数据一致。

1.5术语:Spam与Anti-Spam

Spam指使用脚本、机器人进行恶意批量提交或遍历破解的行为; Anti-Spam指防止Spam的系统措施。

1.6术语:单点登录OOS

也就是所谓的通行证,注册/登录一次,可在所有的子产品(跨域)中通用一个Passport和相同的Profile信息。

2.0注册主键选择

主键是数据库设计中的一个概念,为了保证唯一性,新增用户时必须进行[主键查重]。

2.1以用户名为主键注册

Anti-Spam:非常弱(批量Spam账户)。 扩展性:高,随时可切换为以其他数据为主键。 使用场景:私有内容/私有操作较少的情况,比如仅提供了回复、投票、点赞等[轻操作]; 产品雏形期,进行测试的新产品(开发比较容易)。

便利设计:

注册和登录可合并在同一个界面(不考虑找回密码时);

注册时可顺便把用户名当作昵称搜集。

注意事项:

为了让用户找回密码,必须设置密保问题,找回密代价很高(把自己用户名给忘记了)。

2.2以邮件地址为主键注册

Anti-Spam:中等(自从QQ邮箱出来,被遍历攻击的事儿也是不少啊)。 扩展性:中,可以随时切换为手机主键。 使用场景: 邮箱容易记忆,适长期频繁使用的产品;适合在web端需要依赖Newsletter进行营销的产品;非实名用户系统,邮件主键的代价最小,转化率较好。

便利设计:

To B产品使用企业邮箱注册,自动关联企业主账户。

注意事项:

邮箱是隐私,掩码显示,如果包含社交功能,注册时可能需要采集昵称;

进入各大邮件运营商的白名单,是一件头疼的事儿,搞不好就直接进垃圾邮件了。

2.3以手机为主键注册

Anti-Spam:弱(各种遍历、各种骚扰,需要采取措施)。

扩展性:低,几乎不可逆(用户也不答应)。

使用场景:带有支付功能的电商、消费类产品;实名用户系统,需要用户的绝对信任,初期转化率低,最好从邮件主键过度;只有移动版本的产品。

便利设计:

根据手机号自动匹配地区城市、电信运营商(也有一部分用户是携号转网的#_#)。

注意事项:

手机是绝对隐私,能不显示就不显示,显示必须掩码,如果包含社交功能,注册时可能需要采集昵称;国外手机号几乎不可以,短信通道需要至少双备,如果验证短信中包含一些根本想不到的敏感词,会很惨;用户更换手机,运营商回收旧号码卖给新用户,都会大量存在,请一定给出解决方案。

2.4由第三方账户创建(并登录)

Anti-Spam:高(等于是把验证权交给别人了)。 扩展性:高,可以在第三方验证后再创建自有账户。

使用场景:几乎适合各种类型的用户自主注册账户。

便利设计:可以根据第三方授权拿来一大堆Profile里边的信息(除了密码)。

注意事项:把鸡蛋放在了别人的篮子里,一定要心甘情愿;登录之后再创建自有账户,会存在一定的转化率损失;去第三方申请授权,要有耐心,而且通常在产品初期拿不到太多的Profile数据。

2.5社会卡证类主键(身份证、信用卡)注册

Anti-Spam:高,因为规律性比较差,但也不排除社会工程hack手段。 扩展性:都到了这步了,算是个终极。。 使用场景:特殊场合和人群,需要展示特殊的功能;实名用户系统,需要用户的绝对信任;必须关联在线支付/移动支付才能使用的产品;通常都不会包含社交功能。

便利设计:

直接关联到用户真实身份和征信。

注意事项:

通常验证都是通过第三方信用组织进行,比如提交信用卡关联的身份信息,由支付机构或银行匹配之后发送一个验证短信/邮件/二维码;同样是把鸡蛋放在别人的篮子里(通常是亲爹的篮子)。

2.6其他主键

用汽车牌照做主键,真的可以有;不是不可以,但是尽量还是别摸着石头过河;注册主键在真实社会里一定是具有非重复且个人专有的特点。

2.7多主键复合注册

当然可以啦,注册时没必要提示用户哪个是主键,反正登录的时候会提示。

2.8切换主键时注意事项

其切换主键之前,一定要对数据进行筛查,情况可能是这样的,用户使用邮件主键生成了一个用户,当系统切换手机为主键时,用户会因迷惑而创建另外一个新账户,此时可能涉及到用户数据合并的问题。如果这些没有想清楚,就不要随便更换主键。

3.0个人注册(To C)

3.1查重错误,不要在注册环节随便给出

填写一个手机号码,异步查询是否可以注册,虽给用户带来了方便,但也给骇客提供了可乘之机:写一个脚本就能遍历出来哪些号段多少个号码注册过产品! 请在验证码正确之后给出结果,或者单独跳转URL给出查重类错误

3.2前端校验和后端校验都要进行

跨域攻击是最简单的手段咯,注册这么大的事儿,一定要进行前后校验(登录之后,可以根据系统压力再进行简化,登录之前,还是谨慎为妙)。

3.3以邮箱和手机注册主键,第一步只做一件事:验证主键

没有验证过的邮箱和手机会弄脏用户数据,脏库是无法切换登录主键的! 注册的第一步,只做一件事情就好了,不要让用户填写其他信息(填写密码也不行)。

3.4分步注册,暂存数据,只有在用户提交密码那一刻,才创建正式数据

如果第一步是校验主键,那么应该暂存数据,只有在主键验证完毕,下一步用户填写密码并提交之后,再创建正式数据。(这个坑是这样的:用户第一步提交邮箱,但是验证邮件没收到,此时可能用户会再次启动注册,如果前面已录入正式数据,可能会显示这个“这个Email已经注册过了”)。

3.5有必要重复确认密码么?

没必要!设置这个的初衷无非是避免用户注册时输错密码,输错=忘记密码,就去找回密码咯。

3.6只采集必要数据,填写项目越少越好

在注册环节,标注[必填]是个爆弱的设计,如果是选填,就别让用户在注册环节提交。

3.7包含社交的产品一定要让设置头像成为必填

注册之后,需要很大的运营代价才会让用户上传头像,因此这一步骤最好是前置。

3.8昵称需要查重么?

需要!避免李逵和李鬼;尽量杜绝录入火星文和特殊字符(视情况额定)。

3.9验证码何时出现?

参考后面 章节7.3

3.10让用户发送密码短信到特定号码进行手机注册,这很矬

谁会用?有多少用户愿意自己付出短信成本?除非特别紧急的情况下。

3.11同意《用户使用协议》

让用户勾选阅读并遵守《用户使用协议》,不如把注册按钮改为“同意用户协议,提交注册”

3.12邀请码注册要走单独流程

输入邀请码或点击邀请邮件中加密连接进行注册,可关联邀请者ID,需要的单独设计注册界面。

3.13注册与登录合并设计(快速注册)

以用户名和手机为注册主键的时候,可以这样设计;但以邮箱注册的时候,用户需要跳出到邮件系统,快速注册就没意义了;快速注册以后自动进入登录状态。

3.14注册结束后,必须让用户再登录一次(快速注册除外)

这不仅仅是个仪式感,而且是安全的需要,增加自动脚本Spam账户的难度。

3.15注册应该避免设计成light box(快速注册除外)

注册复杂程度不一,并且会经常迭代改善产品,因此校验代码和各种逻辑判断非常多,如果做成light box效果,可能会拖累很多界面的加载速度,也会让维护和测试变得麻烦。

3.16注册后的(首次登录后)欢迎与提醒,设立URL暂存池

注册完成有结果提示和简单的欢迎,然后就需要让用户进行跳转; 记录用户点击注册之前的界面URL,在用户跑完注册/登录流程之后,回到那个URL(“从哪里来,就回到哪”); 如果无法判断用户注册登录前的URL,那么跳转到一个最核心的私有内容界面; 用户可以选择回到Profile管理;

4.0企业商家注册/入驻(To B)

4.1商家注册(申请)建立在个人账户基础上

先完成个人账户注册,再创建商家;在注册商家的同时,创建一个个人账户;以上两种方法都可以。因为商家账户的管理者通常是员工,如果该员工离职,企业会要求进行管理权转移,把商家挂在个人账户下面,灵活度最高。

4.2在注册之前分流角色,而不是注册过程中

企业商家用户通常按行业分类,比如卖方需要提供代理证明,而买方需要填写收货地址;此时最好设置为两个入口,而不要在注册的过程中进行条件分支。

4.3审核期过度界面

通常企业商家注册都需要一个运营审核过程,此时,用户可登录个人账户使用一些基本功能,请把审核进度明示给用户,同时给予企业商户功能的演示介绍。

4.4企业子账户应该是邀请的,而不是随便填写的

不要让企业商户管理员直接填写子账户的用户名和密码,建议企业子账户以email为主键,走邀请的流程,让其他员工自己验证邮件、填写验证手机和密码,这样做责权清晰,安全性最高。

4.5企业管理员不能直接修改子账户密码

企业管理员触发一个验证邮件给子账户,子账户可以自行通过加密连接修改密码;必要时,管理员可以冻结那个强制要求修改密码的子账户的权限。

5.0登录

5.1登录主键提示

在主键input当中,允许用户填写不同的主键,虽然校验比较麻烦,但是用户便利了。

5.2注意登录错误信息抛出方法

单独抛出“该用户不存在”或者“密码不正确”可能会是不科学的,因为很可能方便了别有用心的人,比较安全做法是“用户名不存在或密码不匹配”。

5.2记住用户和记住密码是两种不同的功能

一种是保存“主键”,另外一种是保存“主键+口令”。记住用户名,就一定要有切换用户的功能;保存口令,要看产品的使用频率,使用频率越高保存周期越短(在便利和安全之间的平衡),保存周期最好不要超过3个月(甚至可以设置3个月强制更换密码)

5.3验证码何时出现?

参考后面 章节7.3

5.4防止重复登录

这个经常被忽略,同客户端,后来登录的踢掉前面的session;允许web、手机app、HDapp同时登录,但每个终端智能保持一个session哦

5.5尽量设计成light box或类似效果,登录之后“从哪里来,就回到哪”

注册、登录前暂存URL,还是一个很重要的登录彩蛋。

5.6二维码登录

如果有移动app,通过App扫二维码可以直接登录web版本。

5.7长期未登录、陌生移动设备登录,加一个判断,通知到邮件

长期未登录,突然在异地登录,在陌生的移动设备上首次登录都属于异常的情况,此时要增加用户判断的环节,并发送通知到邮件。(手机号码可以换,邮件地址不会随便换吧)

6.0找回密码/修改密码

6.1密码的安全

除了足够的位数要求、大小写和特殊字符要求,可以通过判断要求用户不允许把密码修改为曾经用过的密码(开发量略大),不能使用常见密码、纯数字密码、生日密码等。指纹、虹膜、手势……密码的种类会越来越多的。

6.2按问题找回密码,或创造问题找回密码

直接输入邮箱和手机就能找回密码,不是一个好设计,应该还是要进一步判定身份;设置找回密码问题是通常的设计;可以尝试“下面多用户哪些是你曾经的联系人”、“请输入你曾经用过的密码”“下面哪些宝贝你曾经购买过”等等;为了防止Spam,设置一个验证码也可以。

6.3按邮箱找回密码

发送一个密码找回函,用户通过加密连接修改密码,密函有效期尽量短一些; 如果用户说“邮箱密码忘记了,或者邮箱不用了”,那就无法修改密码,人工服务也不行!

6.4按照手机找回密码

手机发送要防遍历Spam,手机验证码有效期越短越好,10~20分钟就可以。 要提供“这个手机号码已不再使用”的解决方案,仅以手机为主键,且手机丢失、号码不再使用的情况,要求进行验证。

比如“下面多用户哪些是你曾经的联系人”、“请输入你曾经用过的密码”“下面哪些宝贝你曾经购买过”等等,然后再进行解绑和重新绑定;必要时加入身份证信息上传功能;实在不行了,再转人工服务;手机丢了怎么办?手机不是有屏保密码么?不设屏保密码,那责任在谁?

6.5找回密码/修改密码之后,必须让用户再登录一次

依然是一个安全问题,也是给Spam脚本增加难度。

6.6找回密码/修改密码与提醒

用手机找回密码,就不要发手机提醒了,发个邮件是可以的; 用邮件找回密码,不需要特殊的提醒; 只用问题就找回密码,发个邮件比较好;

邮箱本身有密码,手机本身可能无密码(易被滥用),因此,用邮箱找回密码安全级别较高。

6.7人工密码服务

必须通过系统内保存的邮件发送相关的身份证明,不能随便找个邮箱或者qq就发送了; 不是修改密码,而是人工发送一条密码找回函到注册时的主键邮箱; 人工解绑、绑定手机的这个功能,不推荐,道德风险比较大; 呼叫中心成本比较高,现在流行用微信做人工服务;

7.0验证邮件、验证短信和验证码

7.1要控制邮件发送的频率

虽然用户可能不反感,但是邮箱提供商可能直接认为是垃圾邮件地址了; 可以努力通过技术手段或者购买服务,进入各大邮件运营商的白名单;

7.2手机短信这个坑啊

如果大量依赖手机主键,短信运营商至少要找两家,进行双备份;要有[熔断]机制,在某一时间段内,不允许连续发送短信到某个手机(防止Spam)。曾经遇到过恶意的将验证码连续发送到某个手机(当然不是黑客自己的号码),用户直接投诉,整个短信通道被运营商封杀,直接跪了;多次没收到短信,要给予时间间隔,此间不允许发送,要求客户耐心等待;短信内容要提前发送测试,总有一些敏感词,臣妾想不到啊;

7.3验证码何时出现

Anti-Spam的验证码降低了用户感受,因此,推荐在初次使用时不出现验证码,在1~3次错误之后,出现验证码;尽量让验证码新奇好玩一些,减轻用户反感。

8.0Passport产品经理须知

8.1需要专职的产品人员和运营人员负责Passport?

如果是电商、线上交易类的,几乎必须专人负责了;如果包含支付环节,又木有专人负责,最好直接使用成熟的登录/注册设计,不要标新立异;如果整个产品只有一个人操办,那么恭喜了,这个文档也许有些帮助。

8.2注册转化率那点事儿

要看追求何种目标,如果是以注册量为KPI,注册过程越简单越好,在注册之前尽量给与更多的利益展示;

8.3注册统计

通过促销活动注册的用户,要单独进行渠道统计,虽然理论上这些几乎都不会成为持久的DAU,但总是需要知道各种渠道的效果对比

8.4与运营团队配合解决问题

本文罗列的问题,仅能算作一些基础,实际运营过程中,用户在注册/登录问题是千奇百怪的,大家还是要有个心理准备。

为1%的用户创建100%的功能,得不偿失,但产品经理总是要给出一些答案。

本文实乃一家之言,难免有疏漏,敬请海涵

 

本文由@鸿津  公众号:Hozin (hozin-com)授权发布于人人都是产品经理 ,未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 5

登录后参与评论
  1. :grin:

    回复
  2. 大赞,写的太好了,许多是还没考虑的。多谢前辈指点~

    回复
  3. 本来想自己研究一下的,发现前辈总结的够完善了,直接学习了。

    回复
  4. 感谢 很有帮助

    回复
  5. 赞!讲得很细,好多问题在我实际设计中都遇到过。

    回复
加载中