经常有新人刚进公司，看注册登录页面不爽，改!改的不止是UI/UX，而是信息架构。虽然这块功能模块页面不多，但没考虑清楚把整个账户体系搞混了，造成不可回转的大坑，运营马上提着刀杀过来。

　　账户体系基本常识

　　账户是所有机构/平台必须具备的基础配置。不专指互联网领域，例如你在屈臣氏办了会员，提供手机号就能积累积分，积分达到多少报手机就能享受优惠，说明你在屈臣氏开了户，手机号是开户账号，存在于屈臣氏的用户数据中。简单来说，账户是开户的凭证，包含账号名和密码，意味着你成为他们的用户，同时你也具备某方面的通行资格。

　　用户账号(User Account)：用户注册完成生成的通行证账号，在系统中的属性是唯一的，仅对用户个人可见，他人不可见。

　　账号名生成途径：

　　系统自动配置，例如QQ号

　　用户注册时填写的昵称/手机号为首次账号名。由于属性关系，如需更改，建议加上次数限制，而且具有覆盖性

　　用户注册之后自行设置，例如微信号，必须做同名判断

　　用户身份(user ID)：系统自行配置,一般是一串数字，根据用户注册时间排列，该ID不对用户可见，为后台管理用户的唯一标识，不可更改。

　　开放账户(open ID): 借助第三方网站url验证用户身份，当用户第三方授权登录成功，系统通过获取用户的open ID生成user ID,同时也读取用户在第三方网站的身份昵称以及头像，该昵称可作为首次的账号名。

　　open ID的获取分为静默和用户授权。

　　例子：

　　投票活动，不需用户授权登录或关注公众号，但需做投票次数限制，一个ID只能投一次等，如何限制呢?静默获取用户open ID作为身份识别再行限制，弊端是只能在QQ，微信等第三方才能获取。如用户跑到浏览器投票?赋予用户唯一码，除非清理缓存，否则也可跟踪。为何不限制IP?假如局域网内的IP是固定的，将导致你投了票，全公司都不能帮你投。

　　如何构建账户体系

　　注册登录设计进化流分析

　　早期注册页面繁琐，需收集用户的年龄性别等，则在用户注册时要求填写，操作冗长，后期弱化为只需填写账号名/昵称+密码。而对手机号收集需求没有那么强硬，个人资料页绑定即可。

　　如后期需用户绑定手机或邮箱，则新增引导活动/功能/优惠等，成本极高，周期较长。使用账号名/昵称+密码登录在场景中，容易遗忘，导致用户使用周期短，除非是高黏度产品。

　　再者，用户昵称如赋予可登录功能，输入时必须做同名判断，否则导致登录账户无法识别，一般不建议!

　　随着手机/邮箱收集需求的强化，手机/邮箱+密码+昵称注册方式逐为趋势。并不是竞品或者趋势如何，产品就怎么做，这个方式也有漏洞。例如电商，有新人领取优惠，不需验证的注册方式，遇到薅羊毛团伙就危险;但对于资讯类产品，互联网的上半场，要的就是这些用户数据，不需验证，方便刷量。

　　注册项能否去除密码设置?手机+验证码+密码(或不用密码)+昵称(或不用昵称)注册方式为目前普遍做法，细心留意，难以找到输入账号名注册的产品，并且邮箱注册也逐渐淘汰。

　　上图为“在行”“美团”“华尔街见闻”的注册页面，均有密码项。

　　手机号+验证码登录，确实对于用户较为方便。如去除密码，只留下手机+验证码，当用户手机丢失或更换，不在身边时，则登录不了。

　　微信在用户退出时做了密码设置提醒。密码设置最好的时间段是在注册时，如后期再做提醒，除非是高黏度产品，否则执行概率有点悬。如需增加密码设置或者必须使用密码登录，则不能缺少注册环节。

　　注册环节能否省略?

　　上图为“UC头条”“唱吧”“魔力盒”的登录页面。

　　不需注册，直接登录，必须具备的条件如下：

　　有一项具备唯一属性的信息作为识别用户的身份凭证

　　该信息能够被用户长期记忆并且方便使用

　　注册才能生成的信息项不作为唯一的登录条件，例如密码

　　而“UC头条”“唱吧”“魔力盒”识别用户身份的凭证是手机号/第三方的open ID。

　　手机号+验证码登录的优点

　　例子：