作为一名产品经理，必须得“上得了厅堂，下得了厨房”，前后台的规划设计都得能熟练驾驭。
不过“上厅堂”易“下厨房”难，甚至不少产品人在对待后台的设计时，都难免有畏难或不愿意之感，特别是新人，总结一下大致是三个原因：
① 后台见的少用的少，缺乏感性直观的认识，又难以借鉴；
② 受关注和重视程度弱于前台，且后台用户少，所以不如前台有成就感；
③ 后台功能由前台而定，离“改变世界” “用户体验”等情怀远，而且难度还大。
但是作为一名产品经理，不能熟练设计后台，那专业技能树是有缺陷的。
并且，后台极为重要。
后台是运营、市场等工作落地的重要工具，后台掉链子，再好的产品也得趴窝。
那怎么做呢？
首先，需要明确后台也是产品，在设计前要搞清楚几个问题：
用户是谁：运营、市场等公司内部人员，有的平台会包含B端用户；
产品需求：简单来说——前台有什么，后台就要管什么；
使用场景：PC操作；
产品目标：逻辑清晰无遗漏、操作高效、提示充分。
明确了上述几个问题，我们在产品规划设计以及实施过程中才会有权衡取舍的信息基础。比如浏览器兼容方面，因为后台用户是特定人群，所以可以建议其使用某一浏览器，这样可以把大量调整兼容性的时间节省下来放到更重要的事情上。
后台产品设计的步骤
第1步——清楚业务，捋清逻辑
掌握清楚产品前台的业务和需求是开始做后台设计的前提，在这个前提下，可以使用泳道图来梳理后台逻辑。泳道图又称为“跨部门流程图”，不过在梳理后台逻辑时，我自己觉得更贴切的说法应该是：
跨角色多状态流程图
以B2B2C电商为例，其第三方店铺的订单逻辑梳理后大致如下：
这个流程里涉及到的角色有：用户、店铺、平台；订单的状态有：待付款、代发货、待收货、待评价、已完成以及退款/退货。
在跨角色多状态流程图梳理完成后，可以很直观地看到各个角色在各个状态下的操作项有哪些，前置后置条件是什么，这样在设计后台时不同状态下不同角色对订单的操作项就明确了。例如：在退款/退货状态下，用户的操作项会有——申请退货、等待店铺同意、退还货品、向平台申诉，第三方店铺后台的订单管理操作项里需要有——审核退货申请、确认收货，而平台管理员操作项里有——审核用户申诉。
第2步——划分管理模块
把产品业务逻辑按照后台需要梳理完毕后，接下来要开始划分管理模块。
划分时方案不一定唯一，但归类要清晰有逻辑依据，便于后续使用时快速定位所想要的管理操作，划分后要多次检查，确保对前台的管理需要没有遗漏。
在一二级模块划分完毕后，后台的框架基本就确立了。
第3步——细化每个页面
接下来要开始“填充血肉”，在模块划分的基础上，对每一个子模块进行细化。谋定而后动，重点思考整理清楚各模块有哪些状态、哪些页面、页面上有哪些字段、操作项是哪些。
以上三个步骤完成之后，最难的部分已经拿下了，对于后台“老司机”来说，即使不画原型也能看到后台的样子了，不过对于新人，这可能有点困难，那差的地方其实就是一些后台的基础知识，或者说是后台的一些套路和规范。不管前台怎么变，从PC到微站到App...后台的这些东西变化很小。
后台常见的结构布局模式
布局模式1：两级菜单类（最常用）
对于大多数产品来说，两级菜单的后台基本就能满足需求，而且相较三级菜单模式，它操作起来也更加高效，所以掌握这一布局模式具有很强“性价比”，下面我们针对它解构一下，加深理解和记忆。
主要组成区域：LOGO/名称区、管理员操作区、菜单区、导航区、TAB区、页面操作按钮区、筛选查询导出功能区、列表展示区、列表内容操作按钮区、页面内容批量操作按钮区、页码区。具体布局位置如下：
有时候，遇到较复杂的后台，比如电商类后台；或者在原有系统里新增了一块很独立且稍微复杂的业务时，需要采用三级菜单的布局模式，三级菜单的布局根据菜单位置的不同又可以分为两种，如下：
布局模式2：三级菜单类型一
布局模式3：三级菜单类型二
模式2和模式3同属三级菜单类型，两者的优缺点正好相对：前者的优点是菜单区不占用主内容区位置，但操作流和视觉流不顺畅，后者正好反过来。使用时可根据项目情况来进行选择。
后台权限分配逻辑
后台的使用，出于部门职责、信息安全等考虑，需要进行权限划分，不同的角色拥有不同的查看和操作权限。但是，在设计后台时，很难一开始就考虑清楚所有的角色以及其对应的的权限。
比如：我们提前设定运营这个角色拥有订单管理、会员管理、新闻管理三大块的所有权限，但实际使用时一定会有考虑不到的情况，比如来了个运营新人，只想让她管理新闻版块，又来个新人，只想让她看到会员信息而不让进行会员封号等操作...这种权限的需求是千变万化的，所以后台权限一定要做成可配置的。
那么权限配置到底配置的是什么呢？
我所理解的到了落地层面主要是三个东西：
① 配置菜单——不同角色看到不同的菜单；
② 配置信息——即使拥有同一菜单，其展示的信息也可以不同；
③ 配置操作按钮——即使同一菜单下展示信息相同，其操作项也可以不同；
在后台设计时，页面表现大致如下：
系统权限
即将系统所有权限都列出来，如图所示：
系统角色
指拥有不同系统权限的的角色，在创建时要勾选系统权限。
系统用户
其实质是被赋予了不同角色属性的可登录后台的账号，其登录后便只拥有其系统角色对应的系统权限。
总结一下其中的逻辑和流程：
这块的操作和逻辑很容易把人绕晕，不过，权限配置的权限一般只有超级管理员有。
后台产品设计实用心得
交互方面
· 减少路径，能两步到达绝不三步；
· 添加或编辑简单信息时，尽量使用弹框，不跳出当前页；
· 弹框里不要再弹框（js处理较麻烦）；
· 列表中某项信息过长时需要进行折叠，点击后直接展开全部内容，不要进新页面或弹框；
· 敏感操作一定需要再次确认，例如删除、发布等；
擅用Axure母版
后台设计时类似元素较多，所以将常用元素制作为母版，可以大大提高原型制作效率。
后台产品设计的注意事项
设计前一定要和技术小范围沟通
后台的技术和逻辑属性很强，当后台方案梳理完成后，一定要先和负责后台开发的技术人员确认其中的逻辑有没有矛盾点、遗漏点，确认规划的功能、路径、权限控制是否合理是否有更好方式。
标示清楚必填项和选填项
不标示清楚的结果就是技术人员自己琢磨或者再特地花时间来问，会付出比标示多得多的时间成本。
规则提示要充分，宁可重复
规则标识清楚，可以指引运营或其他人员知道最正确的方式，有助于产品发挥最佳状态，最大程度还原规划设计想法。
还有，有些逻辑性规则如果不提示清楚，使用人员根本不知道，只能猜或者试错，影响正常使用。而且逻辑性复杂的规则时间长了之后自己也会模糊或忘记，最好就是“趁热打铁”，在规划时以最精炼准确的语言提示在页面上。
后台也需要迭代，或者说更需要迭代
在代码实现过程中，后台的效果和体验往往会因为时间、资源等因素被打折扣。
“实现功能就行，体验先不管了”
“都自己人用，体验差点没事”
......
而当产品上线了，大家的目光和心思就更加聚焦到前台，很多“先不管”的问题慢慢变成了“永远不管”，所以后台产品是更需要去重视去迭代的。
总结：
对于产品经理来说，掌握后台产品设计重要且必要，捋清逻辑流程、划分管理模块、细化字段状态操作项，然后按照后台布局模式和规范将内容填充到各个区域，设计出一份后台就是这样“简单”。但是要设计好并保证最后执行到位，就不那么容易了，这需要我们不断在实践中去总结去提升，共勉！
以上，仅个人想法记录和分享[2017-08-06]或不足或有感，敬请指正和交流。
作者：夏周越，一只靠谱细致热爱产品工作的汪，文章首发个人公众号：沐先生的产品笔记，欢迎勾搭。
