听说，你们家后台难看又难用？

最近有幸参加到一款产品后台的设计中，就在朋友圈中发了一条关于后台产品的动态，不曾想引发了一堆小伙伴们吐槽。主要槽点大致有这么几点，自家后台难看又难用，完全不考虑用户的操作习惯，流程不够优化，并且还一堆bug…

结合之前在网上看到的一些东西，细细琢磨了一下，网上关于后台产品的文章相比于其他的类别而言，文章真的是少的可怜。便有了自己写一篇的想法，本文主要包含以下几个部分：为什么网上后台产品设计的知识那么少、 后台与前台的区别有哪些、我参与的后台产品的设计思路。

虽然说后台产品更加注重功能的实现，轻用户体验一点，并且后台的用户量也相对较少，然而这并不代表着后台产品不重要。

一个好的后台产品能够大幅的提升员工的工作效率，从而较少很多的隐形成本。所以，后台产品的设计也是很重要的，接下来就简单的分享一下自己在参与后台产品设计时的一些思考。

下图为一般经历的流程：

做事先问目的，即Why，为什么要做这个产品，是为了解决什么问题？通过产品想实现什么目标？是为了能够提升组织效率，还是只是为了能够有个统计报表的东西，还是为了能够对前台产品进行配置？另外需要能够界定系统的边界，有哪些需要在这个系统中完成的，哪些不需要涉及。

在后台中需不需要体现组织架构？上级能不能对下级进行操作，能不能越级操作？下级的操作需不需要上级来进行审批？

使用这个系统的用户都有哪些？具体的用户角色类型都有哪些？对于超级管理员、管理员、其他角色等这些不同的角色，各自的权限具体有哪些？上级管理员能不能对下级进行权限的收放？

对于不同的角色，各自的需求是什么？可以通过一个需求池来进行收集，比如可以记录需求的编号、需求的来源、需求的描述、需求的类型、需求的优先级、变更记录等。

常见的流程图一类是业务流程图，一类是页面流程图，此处说的是业务流程图。通常情况下一般用流程图和泳道图来进行梳理，如果仅仅只是一个维度的，一般用流程图梳理即可，而如果说涉及到两个维度的，一般则需要用泳道图来进行梳理。

后台产品的导航一般有三种，分别是横向导航、纵向导航以及横向+纵向导航。

横向导航一般用户后台产品功能较少，且导航的层级结构较少的情况下。

优点是学习成本低，能够简单明了的看到所有的操作；

缺点则是扩展性相对较差，不适合复杂的后台产品。

纵向导航在后台产品中使用的较多，一般还会细分为树结构、直接展示二级菜单的以及鼠标移入显示二级菜单三种。

优点是扩展性较好，能够增加较多的功能模块和子级菜单；

缺点则是每次操作都需要展开二级菜单栏，增加了用户的心理认知负担和操作成本。

多用于比较复杂的后台产品。

优点嘛，貌似是能够根据实际需要把后台产品弄的非常复杂；

缺点嘛，太复杂很难找到自己要找的东西算不算？

一般在进行功能结构梳理的时候，我都会默默地打开Mindjet，先把功能完整梳理一遍，具体梳理标准参加麦肯锡“MECE原则”，即相互独立、完全穷尽。另外在梳理的时候，就可以进行版本规划的考虑了，是在这个版本做合适，还是说放到下一个版本的迭代里面。

我一般是在绘制原型的时候就直接在原型上标注了，将比较简单的功能描述、规则说明、触发条件、异常流程、全局说明都直接标注在原型上，如果说流程比较复杂，则会绘制一个流程图来说明。

线框图绘制好之后，评审完没有问题过后就能够拿着线框图去找设计产出设计稿了，一般在绘制线框图的时候，为了不影响设计人员的设计，我一般倾向于多使用灰色、白色和占位符。

开发测试时，需要能够根据之前定好的时间点，定期主动的去和开发测试沟通交流，如果说遇到需求的变更，则需要尽早的通知到相关的干系人。