除少数工具类的应用，注册登录模块可以说是产品中最基本的模块了。对于这个人人都知道的功能，我还是直奔主题吧。

目的

我一向主张分析任何的功能，都先从目的（动机）入手，那么我们先来说目的吧。

1.与用户产生连接。

此种连接，可以说是双向的连接，不过更多情况下，是应用对用户的虚拟或者真实身份信息的留存。例如，当你有时候需要下载一个冷门网站的一个很冷门的文件时，很有可能发现这个网站要求你必须注册成为会员后方可下载。不过即使你因此注册了，下次你还会来这个网站么？还记得你在这个网站有账号么？没关系，对于这个网站来说，它拥有了一部分它想要的信息，也许是你的邮箱，也许是手机号。

说一句题外话，现在大部分应用要求注册用户填写手机号并非完全出自“与用户连接”的目的，还有一部分原因是国家监管要求。

2.用户行为信息或其他信息留存。

行为信息或其他信息存储在用户记录里，除去便于分析用户行为描绘用户画像外，对用户来说，也便于跨平台或切换账户。

譬如Chrome的收藏或记住密码可以跟着你的账户，实现手机端和电脑端同步。还有在视频网站看了一半的视频，换个浏览器照样紧跟视频进度，不耽误一点时间。
譬如在亚马逊官网绑定了信用卡，你可以在app上直接输入支付密码就可以使用，毋需再次绑卡。

3.便于监管和审核UGC。

UGC，User Generated Content，用户产生内容。可以自由上传内容的地方总是难免要有审核。审核的严格程度和规则自然是各家都不相同，但是这些内容都是依附在用户账号下这点，大家都十分一致。

4.便于用户后续消费、隐私等行为

前面我们已经说了在亚马逊绑卡后可以直接输入支付密码消费，其实这种行为也就是“后续消费”。这种后续消费行为是通过用户录入额外信息来实现的。这种额外信息需要依附于原始的用户信息上。额外信息不仅包括银行卡等信息，也包括个人真实身份信息等等。

当然现在用户消费有时也不需要录入什么额外信息，一个二维码就可以搞定了。除了街头卖煎饼的店铺，线上应用也会将二维码消费与用户记录挂钩，不然你的视频会员就白买了-。-

应用端

如果你的应用不涉及以上几个目的，或者是部分功能涉及到以上目的，那么你可以考虑下游客模式。

在对需求分析时的第一步——目的——已经完成后，接下来讨论的是应用端。应用端决定着流程设计的策略。
应用端的不同，使用场景不同，用户习惯也不尽相同，在注册登录这个初始步骤，区分这些还是有些重要的。

Web

Web页面中，由于页面大，可以实现多内容且便于阅读的呈现，可以将注册登录所有录入信息项在一页中展示。便于快速完成任务，以及让用户明确知道任务进度。

App

App的页面小，不适合展示过多的信息，更需要聚焦当前小任务。如现在有很多App将录入手机号、发送验证码、设置密码等小任务拆解在不同的页面里。这样拆解的好处除了聚焦当前任务外，还有分散任务项过多造成的压力——毕竟当前页面只有一个任务嘛。

H5

和Web、App最大的不同是，H5没有单独的注册登录功能。H5中的注册登录大多是事件流里的主流程外的行为，是系统的辨识行为。
这种非主流程外的行为夹杂在主流程时，最主要的考量就是尽量轻量化。以感受上不打断原流程为宜。
除了轻量化外，还应尽量将注册登录后置，尽可能使用户接近完成主流程，减少损耗。

对接系统

确定了产品注册登录的目的和投放的应用端后，下面可以开始关注实际设计中对接的系统了。
没有一个功能是孤立的，大部分的功能都需要与其他系统进行交互。注册登录里，最常交互的后台系统就是用户中心和消息中心了。

用户中心

用户中心规定并存储了用户的必录项、非必录项和其他记录。用户的必录项是注册里必须要呈现的基本信息。

在确认必录项的内容时，务必确认账户与必录项的关系：一个账户（CustomID）是否对应着一个必录项目？通常情况下账户与必录项是一一对应关系。
如很多应用注册时只要求填写手机号和设置密码，可以判断，手机号+密码即为必录项。
注册登录时尽量只要求用户填写必录项，以简化该功能。

非必录项与必录项的对应关系也很重要。如第三方账号绑定、手势密码等非必录项是直接影响登录流程的。

考虑非必录项时可以从以下几个问题入手：

• 一个账户是否可以对应着多个第三方账号？也就是一个账户下至多可以绑定几个微信号、微博号、QQ号，等等。当然可以绑定第三方账号时，也必须提供解绑功能。
• 一个第三方账号是否可以对应多个账户？
• 一个账户是否可以对应多个手势密码或者生物特征密码（如指纹、声纹、FaceID）？

通常情况下，用户中心留存的用户其它身份信息（如实名认证信息）或者其他信息不会直接影响注册登录流程，当然也建议不要影响注册登录，毕竟注册登录是用户以用户的身份来到应用的第一步。

消息中心

消息中心与注册登录相关的只有用户账户验证时可能触发的短信邮件等的发送。
需确认单个用户规定时间内收到的短信/ 邮件是否有限制。

风险控制

在梳理完对接的系统的规则后，基本该收集的信息也已经收集的差不多了，接下来需要为这些信息建立一些安全规则。

注册登录阶段的风险控制基本关注在两点：账户真实性和短信通道的限制。

账户真实性

账户真实性包括了初始阶段录入的账户信息真实性，如手机号真实性、邮箱真实性等；也包括账户验证时的真实性，如密码真实性。

目前很多金融应用或电商平台，会至少两次验证账户。第一次是登录，第二次是当发生交易相关的行为时，验证交易密码。有验证就有成功和失败。安全规则就是用来规范失败的情况的。设定几次密码输入失败即进入账户锁定或账户冷冻，是一个不错的通用办法。

短信通道限制

为防止短信通道被恶意程序攻击占用，很多应用都会有CAPTCHA（Completely Automated Public Turing test to tell Computers and Humans Apart，区分人与机器人的验证方式）。在注册登录阶段需要考虑的是CAPTCHA的使用情境。如当用户频繁唤起发送短信的操作时，是否出现CAPTCHA等等。

不同的CAPTCHA有不同的性格，目前市面上常见的有图形验证码、滑块、选择指定的图形等，具体选择哪种CAPTCHA嘛，本文不再赘述，有时间的话还是另开一篇来介绍好了。

在以上的系统分析后，我们已经可以得到比较全面的注册登录的限制条件和规则了。这些内容将会在下一步的流程设计中真正发挥功效。本篇文章使命完成，就此搁笔。