前面的话

 

注册/登录界面的产品设计，几乎是各大互联网公司产品面试的必答题。关于这个问题，市面上已有无数篇文章，水平层次不齐。但，唯独这篇最专业。

设计注册/登录功能是构建产品用户系统的第一步。换句话说，产品自身的定位和对用户系统的需求决定了注册/登录页面的前端交互设计方案。

那么，目前市面上有哪几种常见的注册/登录界面前端设计方案？哪一种方案更符合我的产品需求？再考虑到产品的服务端，我们又需要思考哪些问题？且看作者一一解答。

 

一、前言

 

用户系统是很多产品最基础的构成之一，但越是基础，开源设计想要完善也就越难。

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

用户系统的实现简单来说有两种方式：

1. 自己构建用户系统

2. 用第三方授权

第三方授权获得的用户信息有限且受制于人，而自己构建用户系统研发及用户使用成本均不如第三方授权。所以实际情况中，更多的是两者并存，相互补充。

首先声明一点，由于本人的工作需要从0到1设计一个用户系统，而本人又不是强技术型产品，所以在定义服务端或需求的时候，有不完善或不专业的地方，希望大家多提意见，我们共同完善。

 

 

二、总结需求

 

总的来讲，设计用户系统需要考虑的三个基本问题是：

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

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

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

 

三、前端设计

 

（1）

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

1. 账号密码优先

账号密码优先是最常见的一种登录注册设计，适用于普遍场景。鼓励用户用注册方式登录，有利于产品引导用户完善更多的资料，留存自己的用户信息。

例如，知乎是以账号密码登录为最优先，且会隐藏第三方授权登录。现在的账号密码登录都会以用户注册方式代替系统生成的userid作为账号。纯账号密码登录是较为早期的设计，例如早期qq和飞信。

2. 手机号快捷登录优先

手机号快捷登录，也叫免密登录/短信验证码登录，适用于用户不登录也能够完成大部分行为，只有在某种场景下必须获得用户身份时才需要用户登录，且此时用户想要完成的行为是被要求登录操作打断的。

常见的如团购类产品，用户在应用内进行了商品的浏览、筛选、添加到购物车，当要进行最后一步付款操作时，发现未登录。这时繁琐的注册或者登录都有可能导致这笔订单甚至这个用户的流失。所以这时获取用户身份的方式一定要尽可能便捷。

3. 第三方授权登录优先

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

 

（2）

用户资料实际也属于用户系统等设计的内容。是否要增加此项的判断原则是根据这个产品对用户资料的需求程度，决定用户注册时是否要增加资料填写页，资料填写页是强制阻断性的还是可跳过的，必填的资料项有哪些，希望填的有哪些。

如果是需要关系链的，那么注册的时候就应该强制用户去填写资料，设置必要的昵称和头像，这样的用户对于此类应用来说才属于有效用户，不然在app内用户点进资料页，全是系统自动生成的垃圾信息，对于建设关系链和留存伤害较大。

 

（3）

交互细节上又可以延伸用户进行注册或登录需要几个步骤？这些步骤是在一个页面上承载还是一步一个页面以多页面去承载？

单一页面承载的优势是用户能够有很清楚的预期，他完成注册需要进行哪些操作；劣势是一个页面承载过多信息显得杂乱，操作的次序也会不明确。

多页面承载的优势是页面整洁并且路径单一，能引导用户按照通畅的预设路径完成操作；劣势是用户对完成注册的具体行为没有完整预期，更容易跳出。我个人更推荐后者，因为用户预期可以用页码/步骤管理用户预期。

 

（4）

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

补充一些贴心的小点：

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

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

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

 

 

四、服务端设计

 

（1）

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

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

现在先说一下多平台账号打通需要考虑到的问题：

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

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

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

 

（2）

用户系统多平台打通示意图

关于上图中出现的一些名词，你可以这样理解：

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

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

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

用户系统多平台打通的基本原则：

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

• 用户系统同一unionid可对应不同的appuserid。

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

 

（3）

用户系统主线流程图

手机号注册主流程为：

用户注册时，用户系统服务端需要验证手机号＋验证码是否为真，此手机号是否已有对应unionid。

若有提示已注册，请登录；若无创建对应unionid，app服务端根据unionid创建appuserid。至此成功生成了用户系统身份及当前app用户身份。

手机号登陆主流程为：

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

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

 

（4）

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

 

本文作者王悠悠悠，互联网产品狗，静若瘫痪动若癫痫，爱好阅读和游玩，微信WY54EF，欢迎交流。