用户系统 (上)/ 前端设计及多平台账户打通

2016-12-08 11:20:00

前言

用户系统是很多产品最基础的构成之一，但是越是基础越是开源设计想要完善也更难。在设计用户系统的时候，首先想到的关键词是注册和登录。但并不是有这两者就足够了，更加完善用户系统本身还需要考虑：多平台账号打通，同平台账号之间绑定与解绑，账号安全等及需要怎样的前端设计才是满足这个产品本身定位和用户操作的设计。

用户系统的实现简单来说有两种方式：1、自己构建用户系统；2、用第三方授权。第三方授权获得的用户信息有限且受制于人，而自己构建用户系统研发及用户使用成本均不如第三方授权。所以更多的是两者并存，相互补充。

在定义服务端字段或需求若有不完善和不专业的地方，希望大家多提意见，共同完善。

一、总结需求

1.用户系统基本注册／登录功能及前端页面设计

2.多平台账号打通，即在单一app注册的用户，能够使用此账号登陆系统内所有app

3.用户相对独立，对于单一app来说用户身份唯一

二、前端设计

登陆注册主流设计有三种（原型如下）

1. 账号密码优先

账号密码优先是最常见的一种登录注册设计，适用于普遍场景，鼓励用户用注册方式登录，有利于产品引导用户完善更多的资料，留存自己的用户信息。例如知乎是以账号密码登录为最优先，且会隐藏第三方授权登录。现在的账号密码登录都会以用户注册方式代替系统生成的userid作为账号。纯账号密码登录是较为早期的设计，例如早期qq和飞信。

2. 手机号快捷登陆优先

手机号快捷登陆，也叫免密登录／短信验证码登录，适用于用户不登录能够完成大部分行为，只有在某种场景下必须获得用户身份时才需要用户登录，且此时用户的想要完成的行为是被要求登录操作打断的。常见的如团购类产品，用户在应用内进行了商品的浏览、筛选、添加到购物车，当要进行最后一步付款操作时，发现未登录。这时繁琐的注册或者登录都有可能导致这笔订单甚至这个用户的流失。所以这时获取用户身份的方式一定要尽可能便捷。

3. 第三方授权登陆优先

第三方授权登陆，适用于对用户资料和权限要求不高快速解约开发成本的产品。建议在应用构建用户系统的前期可以首先接入第三方，快速的实现登录功能。但是若想建设自身关系链还是需要完善自己的用户系统。

用户资料实际也属于用户系统等设计的内容。是否要增加此项的判断原则是根据这个产品对用户资料的需求程度决定用户注册时是否要增加资料填写页，资料填写页是强制阻断性的还是可跳过的，必填的资料项有哪些，希望填的有哪些。例如是需要关系链的那么注册的时候就应该强制用户去填写资料设置必要的昵称和头像，这样的用户对于此类应用来说才属于有效用户，不然在app内用户点进资料页，全是系统自动生成的垃圾信息，对于建设关系链和留存伤害较大。

交互细节上又可以延伸用户进行注册或登录需要几个步骤？这些步骤是在一个页面上承载还是一步一个页面以多页面去承载？单一页面承载的优势是用户能够有很清楚的预期，他完成注册需要进行哪些操作，但是劣势是一个页面承载过多信息显得杂乱，操作的次序也会不明确；多页面承载的劣势是用户对完成注册的具体行为没有完整预期，更容易跳出，优势是页面整洁并且路径单一，能引导用户完全按照通畅的预设路径进行。我个人更推荐后者，因为用户预期可以用页码／步骤管理用户预期。

下面是我根据我们产品的定位和需求设计的用户登录／注册系统原型：如上所说，我设计的用户系统是需要承载多产品的，所以我设计融合账号密码登录和手机号快捷登录两种方式，以用户出发需要登录的场景去切换展现在用户面前的是哪一种。

补充一些贴心的小点：

1.申请读取本机号码权限，并帮用户填写

2.申请读写短信权限，获取到验证码后自动填写并点击下一步

3.应该前置到提醒：上次登录方式，合法的手机号，正确的图形验证码等等

三、服务端设计

很多产品，特别是没有技术背景的产品不会去接触和设计服务端需求，实际上我自己日常工作中接触服务端需求也并不多，并不是说产品要负责设计一个完善的用户系统服务端，而是要学会以服务端同事能懂的方式表达清楚自己的诉求，两边对功能的实现不会有太多的偏差，这是产品设计服务端目的所在。

简单的用户系统服务端的基本功能需求为：判断账号身份（注册/未注册），账号身份生成（新用户分配id），账号密码验证；这里要设计的并不满足于注册登录，需要考虑多平台账号打通的用户系统并且要和在打通情况下单一平台或多个平台之间，用户的多个账号之间绑定于解绑。现在先说一下多平台账号打通需要考虑哪些问题：

1.用户系统身份的创建，因为我们是多平台的系统，所以用户身份只能纳入手机号注册的用户，若第三方授权注册的也算用户系统用户，在账号绑定的那一关则会出现混乱；

2.实现多平台账号打通，要实现多平台账号打通，即所有接入多平台都能够查询到此用户身份；

3.平台间用户身份独立，要实现平台间用户身份独立，则需要在用户系统用户身份的基础上创建一个平台的用户身份；

(一) 用户系统多平台打通

名词解释

1)Appid：接入用户系统时首先分配，用于区别接入的各个app；

2)Unionid：用户手机注册时，由用户系统根据手机号创建，在用户系统作为用户唯一身份标识；

3)Appuserid：用户注册时，由app服务端根据union或者第三方授权的openid创建，在app内作为用户唯一的身份标识；

基本原则

1)手机号作为用户系统账号的注册的唯一途径，根据手机号在用户系统服务端创建并保存unionid；app服务端根据unionid创建并保存appuserid，且将unionid对应保存；

2)用户系统同一unionid可对应不同的appuserid

3)使用第三方openid授权的注册用户不计入用户系统仅存在app服务端作为单app用户，即unioid为空只生成appuserid；第三方授权包括微博微信，QQ，Facebook，Twitter

1. 主线流程图

手机号注册主流程为：

用户注册时，用户系统服务端需要验证手机号＋验证码是否为真，此手机号是否已有对应unionid；若有提示已注册，请登录；若无创建对应unionid，app服务端根据unionid创建appuserid。至此成功生成了用户系统身份及当前app用户身份。

手机号登陆主流程为：

用户登录时，用户系统服务的验证手机号＋密码是否为真，此手机号是否有对应unionid，若有，则说明此用户有用户系统身份。

还需要app服务端需要查询是否有对应的appuserid，若有说明此用户有此app身份，直接用其appuserid登录；若无则说明是用户系统内其他联合app注册用户根据unionid创建此app的用户身份，至此登录成功。

用户系统是大多数app都会有多构成，单一的用户系统也并不那么复杂，但是若要构建产品矩阵进行多平台间的用户打通，加上帐号绑定与解绑，并不是一时半会能够想清楚的需求，若大家感兴趣为会继续补充帐号绑定和账号安全产品应该关心和设计的事情。

四、两个问题

第一：为什么不完全打通，为什么每一个app要保留自己的用户资料和绑定关系。

答：取决于同一个开发者的app是否需要或者能够让用户感知到这些app都是属于同一个开发者的，很容易让用户感知到“哦，这些都是一家公司的”，那么完全打通，用户信息、绑定关系是通的用户是完全有预期的，这是可以的。并且完全打通对于开发来说可以说得上是一个一劳永逸的事情，之后的app用户系统这一块可以说没有开发量，直接接入。我们可以简单归纳一下现在主流的用户系统服务端设计：

1、app级的用户系统，根据手机号邮箱注册或第三方授权创建用户身份，用户的身份信息、账号绑定、个人资料都保存在app服务端也只对单一app有效；普遍中小app都是采用的此种。

2、公司级用户系统，根据手机号邮箱注册创建用户身份，用户的身份信息、账号绑定、个人资料都保存在统一的公司用户系统服务端，对接入的app有效，app端有读取修改权限；

3、平台级用户系统，根据手机号邮箱注册创建用户身份，用户的身份信息、账号绑定、个人资料都保存在统一的公司用户系统服务端，选择极少信息提供公开接口，接入的app只有读取权限；例如qq微博微信等第三方授权。

其他两个不展开，关于公司级用户系统可以举两个典型的例子，感兴趣的朋友可以体验一下，第一个是网易第二个是百度，大家可以回顾一下两个公司的常用app。就我而言，网易是云音乐、考拉海购、网易有钱等，百度是百度地图、百度糯米。可以再去多去下载几个体验。