后台设计的五个要素:辅助设计、表单设计、搜索栏设计、页面设计、导航栏设计的应用情景以及作用。

在进入正文之前，请容我多嘴一句，写这个的初衷也是为自己的以往做个总结吧!陆陆续续往里边增加和删减了不少的内容，留下相对直观的内容。

不知道你们对于一个好用的后台是什么样的概念?是高内聚、低耦合、高易用性、简洁大方的界面、良好的反馈机制、高拓展性、人性化的交互设计?这些可能都是吧!

这篇文章主要的目的是:写一些后台设计方面比较行之有效的经验之谈。当然也看了一些别人的文章，不然也没法相对规范的归纳以往的经验，然后就是对自己以往走过的坑有个总结，同时后来者有个警示，当然里边有些我说的可能不适用一些后台系统，请慢喷。

同时，对以往因为个人经验不足造成的种种事故的公司，深感抱歉，哈哈!(略略略，然而内心并无愧疚之心!这个虚伪的产品!)

一、辅助设计1. 辅助文字

辅助文字一般都是显示于界面的外部来提示、引导用户的下一步操作，与正文相比不是很明显，存在感相对弱化，不至于过于吸引用户的注意力，但又会放在相对明显、关键的地方。

情景:在以下几个地方比较常见关键输入框旁边、标题的介绍、统计图表的属性名称等场景。

下面上效果:

作用:上面可以用到辅助文字的地方，即弱化存在感、同时也能正确的提示和引导用户。

2. 帮助文字

帮助文字相对于辅助文字的纯在感又会被再弱化一个档次，往往是因为内容过多或者用户关注频次低而被放置于相对不显眼的地方。

情景:在那些地方用到的帮助文字比较多呢?没错，就是问题文档、客服咨询的场景运用的比较多。

作用:帮助文字往往是因为包括内容过多，为了不主动分散用户的注意力，往往都是需要触发，不然会因为页面繁杂、主次不分影响用户的感知、干扰用户的判断。

3. 输入框设计

后台的输入框的设计并没有太多讲究，能正确引导用户输入正确的内容即可，主要分两步:引导到正确的输入位置、输入正确的内容。

情景:多用于登录、注册、搜索栏、用户信息输入、订单信息输入等场景，我就不一一列举了。

作用:是为了给予用户良好的反馈，减少用户输入的失误率。

4. 限制条件提示

情景:限制条件提示多数的运用于输入的场景，比如要求的输入的文字或者上传图片文件的字数、大小、格式等等。

作用:通过限制的条件提前让用户了解到输入的前置条件，降低操作的失误率和提升操作的效率。

5. 可视化反馈

可视化反馈在后台的设计中的重要性是毋庸置疑的，反馈的形式也多种多样。当然，作为产品的自己也要区分什么场景需要用到反馈，什么情况不需要用到，并不是反馈越多越好。那么，在什么情况下使用反馈比较好呢?

–关键节点和重要信息录入。

情景:

可视化反馈的运用场景我就列举几个，比如:寄快递的时候收件人的姓名、电话和的地址信息是不是很重要?那么，这一块就很有必要给到他们正确、错误的输入反馈，这就是重要信息输入的反馈机制。

还有关键节点的反馈我再举例一个，比如:你购物付款的时候，往往支付完的时候会提示你支付成功或支付失败，当关键页面、业务或者操作流程从一个进入下一个节点的时候，好的反馈机制会给予用户良好的体验。当然这个节点关键与否需要判定的条件过多，我就过多讲诉了。

下面，给大家几个比较直观的图:

二、表单设计1. 只读模式

只读模式的表单主要是作为信息展示作用，操作的功能并不多或者没有，不会直接表单列表进行操作，比如:发票列表、操作日志等操作性较低的信息列表都会以只读模式显示。

作用:只读模式的表单最重要的就是易读性和易操作性。

2. 可用模式

可用模式的表单可操作的空间很大，根据业务、需求的区别一般在这几个区域对表单进行编辑:顶部搜索栏区域、列表顶部区域、列表内容区域、列表列的末尾。

那么，每个区域的操作放置有什么讲究呢?

也不是乱放的，顶部搜索栏区域和底部操作区域一般用于放置可以对列表内多项行进行操作的功能，如批量删除、批量审核、批量发货、批量核销等等功能;尾部操作区域只对单行信息进行操作;表内操作区域是单行内的单个信息字段进行操作，如姓名编辑、电话编辑等等;列表顶部区域只对列表的单列信息进行操作，如排序、筛选等等。

三、搜索栏设计

搜索栏需要根据搜索栏的搜索的条件的多少进行排版，一般有以下几种布局方式:显式布局、隐式布局、半隐式布局。

这里的“隐”是指需要触发才能看到搜索条件的意思。

相比于隐式布局和显示布局，半隐式布局会将触发频次相对少的条件隐藏，显示出触发频次高的操作功能。

下面是几种布局的显示形式:

多数的列表以显式和半隐式布局为主，隐式布局多数用于规则性的条件筛选才会使用，因为规则性的条件筛选涉及到的操作和逻辑相对比较多，为提高列表的易读性所以采用隐式设计。

四、 页面布局1. 多列式布局

主要使用信息的模块化和分组展示的形式，来提高信息的易读性和复用性。

在客户详情模块区分出了三个比较明显的区域，个人基础信息、个人信用、个人证件，增加整个页面的易读性，同时对于模块化的信息的方式更利于系统的扩展、调用和复用。

2. 单列布局

单列布局的方式多用于弹窗或者信息量较少的界面，信息之间同质性高，如个人信息中的姓名、电话、地址、身份证号等与个人相关性比较高的信息，往往会以单列页面的形式整合到个人信息中，单列布局信息页面的特点之一就是信息的同质性高。

3. 拟物型布局

拟物型布局的特点就是从形态上能加深用户对于信息和场景的理解，比如:个人信息广泛运用于各种场景，如果单单以个人信息的形态展示，可能用户不会很直观的了解该信息的用途，但若是信息的布局以车票、门禁卡、银行卡的信息形态来展示，就相当直观。

4. 步骤向导型布局

当页面信息较多、臃肿，且流程化倾向严重，那么采用步骤向导型布局的方式去设计是比较合理的，能有效的降低输入的压力、降低信息信息重复输入风险。

步骤向导型布局多用于注册、引导使用、多重关键信息的录入情景，多重信息因为信息的重要性和信息比较多，采用步骤的方式可以分段录入信息，不至于使用户输入的时候产生太大厌烦感。同时，因为意外情况导致录入失败时，分段录入的方式可以保存部分信息。

五、导航栏设计 导航栏设计一般有这几种顶部导航栏、侧边栏、动态侧边栏、多级结构，不过也有混合设计的方式，适用分类较多的布局。顶部导航栏于页面顶部。

侧边栏多于页面左侧展示:

动态侧边栏当鼠标移入时展开，鼠标移出时收起。

多级结构:

最后，在废话几句吧!写的不是很好，口语化比较严重，还有表达方面也不是很好，总之，后续会慢慢改进了!

用户系统是很多产品最基础的构成之一，但是越是基础越是开源设计想要完善也更难。在设计用户系统的时候，首先想到的关键词是注册和登录。

但并不是有这两者就足够了，更加完善用户系统本身还需要考虑：多平台账号打通，同平台账号之间绑定与解绑，账号安全等及需要怎样的前端设计才是满足这个产品本身定位和用户操作的设计。

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

1、自己构建用户系统；

2、用第三方授权。

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

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

一、总结需求

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