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

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

（4）

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

补充一些贴心的小点：

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

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

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

　　三、服务端设计

（1）

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

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

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

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

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

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

（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，若有，则说明此用户有用户系统身份。