编辑导语：相信大家在做产品时或者日常使用产品时都会遇到账号的注册登录问题，以及找回密码、注销账号等一系列操作。那么，作为一名产品经理，该如何从用户的角度去思考怎么设计这一流程呢？
刚入行产品的小伙伴们不管你们是做什么业务的，只要业务线涉及到C端的用户，那么大概率你们第一个小试牛刀的流程图是和登录、注册、找回密码、注销账号相关的。当然啦，对于工作了3年以上的“老产品人”每次新开一个项目的时候，也是要去设计这一块常规的功能。那我们就直接切入到主题分析一下这些常见的功能吧。
首先要明确并不是所有的产品都需要注册登录。对于关系用户比较隐私数据的应用需要注册登录，例如微信、淘宝、建设银行APP、邮箱等。对于不会产生用户自身相关数据的应用不需要注册登录，例如墨迹天气、日历等。
对于需要用户注册登录的应用，从数据分析的角度分析，用户注册信息之后生成了一个账号，在后台数据库中有唯一的标识与其对应，我们称新注册用户为新增用户。
我们需要区分一下新增用户和新增设备：新增用户指的是【用户ID+1】，新增设备指的是【设备ID+1】，例如我在手机某个APP上注册了一个账号，然后又使用这个账号在另外一个手机上以及两台不同的电脑上分别登录过，那么我的注册登录操作使得这个产品的新增用户+1，新增设备+4（前提是这几个设备之前都没登录过这个产品）。
目前常见的注册（同登录）方式主要是两大类：
①系统自建用户（用户的唯一标识是手机号、用户名、邮箱、身份证号等）；
②第三方账号授权登录（微信、QQ、支付宝、微博、淘宝等）。
不同业务设计的注册流程和字段都是有一定的区别的，但是尽量本着少、快的方式引导用户注册完，收集到用户最关键的信息。很多产品可以让用户自由选择自建账号或者直接第三方登录，用户按需选择的体验是非常好的。但是极个别的产品会在用户选择了第三方注册登录之后，让用户再去绑定手机号，不然无法完成注册的流程。
从用户的角度出发，如果用户点击第三方登录形式，就是不希望有注册登录那样繁琐的流程，加注册流程只会很大程度将用户卡在门外。如果PM担心第三方帐号出问题，希望组建产品的帐号体系也是无可厚非的。可以让用户首次登录之后让用户去完善一些其他的信息才能使用产品的某些功能，或者通过积分奖励等方式来激励用户完善更多的个人信息。
对于系统自建用户常用的为手机号注册，主要涉及到的字段为【手机号、短信验证码、密码】：
①手机号：我们需要前端验证手机号是否为空，是否符合11位的手机号格式，接口去验证该手机号是否已注册；
②短信验证码：我们需要接口去验证验证码是否正确，是否失效，为了防刷我们还要限制每天和指定的时间段可以获取验证码的次数、输入错误的次数；
③密码：我们需要验证密码是否符合我们的格式以及两次输入的密码是否一致。很多注重系统安全的产品会在注册时设置人机交互验证，具体的流程详见下图：
其中在使用手机号注册登录时，可以不需要用户输入手机号直接进行【本机号码一键登录】的方式进行注册登录。
对于第三方账号授权常用的为微信授权，用户在登录页面点击“微信授权登录”，打开微信app，调起授权用户微信个人信息页面，用户点击同意则同步获取用户信息（openid、头像、昵称、地区、性别），省去用户注册步骤，直接登录成功。
但是不管是微信授权登录APP、小程序、还是手机网站，都是无法拿到用户的手机号。小程序可以单独授权进行手机号的获取，APP和手机网站必须单独获取验证码进行绑定。
对于移动应用/网站应用开发者想为用户提供微信授权登录的方式，需要在微信开放平台添加该应用。为了识别用户，每个用户针对每个应用都会产生一个安全的OpenID。
如果需要在多个应用之间做用户共通，则需前往微信开放平台，将这些应用绑定到一个开放平台账号下，绑定后，一个用户虽然对多个应用有多个不同的OpenID，但他对所有这些同一开放平台账号下的公众号和应用，只有一个UnionID。
对于需要登录的产品，需要明确在什么时候登录。一种是在启动的时候就检测用户是否有登录，若未登录则让用户登录。这种产品的用户信息贯穿到产品核心功能的各环节，所以需要将登录前置到启动环节，例如 微信、QQ、脉脉。
另一种是当需要用户的信息的时候再检测用户是否登录，未登录的情况下引导其登录。这种产品只是在某些环节需要用户的信息，所以这种情况完全可以将登录后置，例如知乎、头条、淘宝。
从沉没成本的角度来考虑，在关联到某些环节需要和用户信息绑定时再引导用户登录能一定程度上减少新增用户的折损。例如电商产品浏览商品时就让用户登录，那么用户觉得麻烦就离开了，但是如果用户精挑细选了满意的商品打算购买时再让用户登录付款，大概率用户就自然地完成了注册登录流程。例如游客可以浏览知乎的内容，但是进行评论时会弹出弹窗引导用户注册/登录。
用户在没有登录的前提下使用产品，这个时候用户的身份为游客身份。用户前期使用游客身份会产生一些数据，如果游客后期在同一个设备上注册了新账号，那么要提示用户是否将游客模式产生的数据同步到新的账号，如果用户选择【是】，那么游客模式的数据清空，数据同步到新的账号下；如果选择【否】，游客数据不被清空，也不会迁移到新的账号下面。
常见的登录方式为密码登录【手机号、密码】、短信验证码登录【手机号、短信验证码】、【第三方授权登录】，其中第三方登录已经在注册时提到，不再赘述。
①手机号：我们需要前端验证手机号是否为空，是否符合11位的手机号格式，接口去验证手机号是否存在；
②密码：我们需要验证密码是否正确，为了防刷我们还要限制指定时间段输入错误的次数；具体的流程详见下图：
①手机号：我们需要前端验证手机号是否为空，是否符合11位的手机号格式；
②短信验证码：我们需要接口去验证验证码是否正确，是否失效，为了防刷我们还要限制每天和指定的时间段可以获取验证码的次数、输入错误的次数。
注意：对于首次登录的新注册用户，登录之后需要用户去完善密码。具体的流程详见下图：
每个单独的系统都会有自己的安全体系和身份认证系统。但是随着业务应用系统越来越多，对于通过一个用户在不同的业务应用系统中会有多个帐户，而且在不同应用系统间切换，需要不停的登录注销，比较烦琐的情况。
于是很多业务线推出单点登录系统（Single Sign On，SSO），将各应用系统统一到单一登录界面，登录一次，即可实现不同应用系统间的切换，不需要重复登录注销，也可提高用户体验。这不仅仅带来了更好的用户体验，更重要的是降低了安全的风险和管理的消耗。
每个账号的密码在数据库中是加密存储的，理论上密码是无法解密的；所以如果用户忘记了密码，那么是无法找回原来的密码，只能去重新设置一个新的密码。主要涉及到的字段为【手机号、短信验证码、密码】：
①手机号：我们需要前端验证手机号是否为空，是否符合11位的手机号格式，接口去验证该手机号是否已注册；
②短信验证码：我们需要接口去验证验证码是否正确，是否失效，为了防刷我们还要限制每天和指定的时间段可以获取验证码的次数、输入错误的次数；
③密码：我们需要验证密码是否符合我们的格式以及两次输入的密码是否一致。很多注重系统安全的产品会在密码找回时设置人机交互验证，具体的流程详见下图：
我们会发现注册和找回密码的流程几乎是一样的，但有两个比较明显的区别：
①注册要保证该账号之前不存在，找回密码要保证之前账号是存在的；
②注册之后直接跳转是登录状态，找回密码之后要跳转到登录页面进行登录。
当用户不再需要使用应用提供服务时，可以主动注销账号，这样应用服务商无法再对个人信息进行收集和使用。不同平台在用户注销账号时有不同的限制，只有满足注销申请条件后，才允许用户提交注销申请。常见的限制为：
①账号处于安全状态——账号最近一段时间内没有任何异常违规的操作、没有被盗被封的风险；
②账号服务已完结&财产已结清——账号不存在没有完结的服务，没有欠款等，避免因为账号的注销造成其他用户或者平台的损失；对于未提现的资产，用户注销账号相当于选择主动放弃；
③账号和其他平台的帐号解绑——该账号已经解除了和其他应用的授权登录或者绑定关系。
账号注销之后该账号所有的个人信息和产生的用户数据全部都被清除且无法找回（即便使用相同的信息再次注册账号也无法找回）。
在前端，注销账号的头像变为默认头像，昵称变更为【账号已注销】，个人动态也被清除，与其他用户的互动依然保留；
在后台，用户注销则在用户账号旁边括号备注“用户已注销”，用户后续重新使用同一个手机号进行注册，则给该账号重新赋予一个新的ID，重新生成注册记录。
如果用户注销之后又反悔的情况，可以设置一个N天的冻结期。如果在N天之内用户登录了应用，那么注销申请自动撤销，用户可以继续正常使用账号。否则该账号将永远消失，无法通过任何方式找回。
由于业务的属性、产品本身对安全性、交互性的要求、不同类型的终端、用户的使用场景等多种因素的影响使得在设计注册、登录、找回密码、注销账号时会存在很多差异，以上分享为常见且基础的设计。好啦，此波分享到此结束，希望能帮到刚入门的一些产品朋友~
本文由 @Grace 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于 CC0 协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。