账号体系的变迁及设计思路怎么写

回顾互联网历史，会发现账号体系距离2000年已经大不相同，迭代的过程既有软件的发展，也有硬件的升级。本文作者对账号体系的变迁和设计思路进行了分析，一起来看一下吧。

一、账号体系的变迁

这两天在回顾互联网历史的时候，发现账号体系距离2000年的时候发展太多，20年的时间仿佛弹指一挥间，中间迭代的过程，既有软件的发展，也有硬件的升级，真的很有趣。

1. 用完即走的时代

自由、开放、共享，是那个时代对互联网的定义，下载不需要注册，看帖、回帖不需要注册（当然那个年代的资源并不多），非常具有代表性的软件就是BBS、电驴、bittorrent，无需注册，开放即用，还记得1024吗？一年仅有几天开放注册，但是不注册也不影响你的浏览体验，“我”和互联网没有任何绑定，撸完即走，我很希望未来有机会能重新回到这个时代。

2. 注册时代的到来

也许是先驱们开始意识到用户的价值，开始有账号的概念了，没错，账号就是为了抽象用户而诞生的，在这个时代，主要通过邮箱（我本人用的是雅虎）、密保问题完成账号维护的闭环（当然也可以邮件管理员完成部分功能维护），同时代的游戏开始用密保卡或者Ukey进行账号保护（梦幻西游的将军令大家还有印象吧？）。

3. 电信验证的日常

现在来看，这种注册方式稀松平常，但是实际要这种注册方式，远并非人力所能及，需要等待市场和企业满足以下要素：

手机的普及（手机都没用怎么收验证码？用BB机好像也不是不行？）
运营商开始提供该种类的对外服务（和国企谈创新服务很痛苦）
网站的经营者能够承担此项成本（早期这项服务可不便宜）

庆幸的是，时代的潮水来翻涌的特别快：塞班没落，安卓和IOS的兴起，移动互联网飞速发展，不知不觉中，电信类的验证已成为寻常服务。

4. 实名核身的今日

这个时代，“商业化”已经替代了“自由、开放、共享”，至于到底进步还是后退，留给后人评说，但无可争议的是，账号（背后所代表的是用户）资产已经成为了互联网企业最重要的2项虚拟资产之一（另一项是技术积累），而连接虚拟（互联网账号数据）与现实（核身用户为真实的自然人）的技术，人脸核身，极大地影响了众多互联网服务。

后续我们也会提到人脸核身这项技术，是如何影响产品经理去重新设计账号体系的。

二、从0开始设计一个账号体系

1. 重新思考账号的本质

大部分前台应用可以抽象为：账号+服务的集合，拿熟悉的X音APP来举例，我登录账号，完成购买交易、视频浏览等功能。

如此看来，账号的本质是服务的对象。

如果服务的对象是企业，那么账号就代表了法人主体；如果是自然人，就是一个实实在在的自然人。

基于这点，我们开始尝试去描述一个账号需要能完成哪些操作：

实际在某些场景下，身份验证可以拿掉，但无疑，一个账号体系的通用功能，绝不会太复杂。

接下来开始设计账号创建/登录功能，而有没有“核身”的手段，对账号创建、登录的流程影响非常大（可能对现今阶段设计没啥影响，因为核身技术很成熟了，但是对比历史很有趣，就稍微啰嗦下），在这里先简单分析下实际核身技术在账号体系实际操作过程中起到了什么样的价值：

先举2个代表性的例子进行对比。

1）某行早期用K宝的在线转账流程：

2）某行现今的在线转账流程：

结论：核身技术让用户减少了大量的输入与操作。

可能文字的表达对比没那么明显，从数据侧来对比更直观点：

如果不是考虑到现在人脸核身的成功率不是100%的情况，其实连邮箱或者手机号都可以省略。

但实际设计中，采用方案2注册/登录方式的明显较少（例如交管类app、某些银行类app），按结果导向，方案2存在某些缺陷。

搞产品设计有一句老话：抛开实际场景谈设计就是耍流氓。

方案2看起来体验更好更简单（好像挺符合奥卡姆剃刀原理），但是实操中却有以下不足：

扫脸操作成本、费用成本更高：毕竟现在仍用许多超过40岁的用户对这种操作摸不到头脑（可能在大城市的白领们很难理解？但去四五线城市看看那里的叔叔阿姨就明白了）；
注册门槛高：我就看个帖子，看个短视频（以社交、内容为核心类的应用），为啥要我实名？更何况过渡收集客户信息还有可能引发投诉；
影响流量买卖的固有结算模式（按注册定价，如果换成核身注册，无疑卖方的利润空间会下降太多）。

基于以上的综合考虑，我们可以设计一个能平衡以上各个因素的方案：

该模型将账号分为三个模块：

账号信息模块，该模块只用来描述账号，和用户本人是一对多的关系，一个人可以建立多个账号；
实名信息模块，该账号用来核身，和客户是一对一的关系，一个客户有且仅有一个实名身份；
业务信息模块，该模块用来存放业务所需要的信息，举个栗子，如果是X乎看个帖子，就不需要地址信息，因为提供内容给用户不需要知道用户的家庭地址；但如果是外卖应用，那就需要地址信息了，否则不知道将外卖送到哪里。这里的信息依赖于细分业务场景。

组成账号的信息抽象完成（更细节的请基于各位产品同学的实际业务场景来填充设计），接下来设计建立账号的流程：

这个流程更人性化，让用户有需求的时候再去完善信息，避免了强行手机信息引起用户反感，并且抽象得当，可以完成任何场景下的注册/登录需求。

那我们就此完事儿了吗？稍等下，我觉得还差一点。

因为现有的服务并不都是“开放注册制”了。

因为我本人经历的关系（既做过互联网C端的服务系统，也做过金融行业B端的系统），经常不自觉的将B端与C端的系统功能进行比较，在账号的这个问题下，我发现一件很有意思的事：

针对C端用户，一般服务的目标是全人类（比如短视频），服务对象的基数太大，所以一般由用户自主注册，并对注册不设门槛，这类通过用户自己创建账号的方式，我称为“开放注册制”；
而B端的系统却不是这样，就拿最常见的EHR、OA、ERP系统为例，通常是由企业的管理员，在新员工入职，拿到工号，再到对应系统赋权、创建的；而用户收到的则是内网地址和初始的登录账号信息与密码，这种创建账号的方式，我称为“定向分发制”。

诚然，我们刚刚的设计方案，能普适“开放注册制”这种方式，但是当我们尝试套用在“定向分发制”之上，好像流程就显得稍有冗长了，因为此类场景下，用户的信息是由服务方主动创建的，在用户初次登录前，实际系统已经有了用户信息，没有再次注册的必要，只要能验证用户的身份信息，就可以给到客户对应的服务，这里拿银行金融服务举例：