如何设计一款后台产品？👊

2018-04-02 本文已影响238人就是小龙虾

做了好几个后台产品，简单整理下在后台产品的设计中「套路」，此文适合于第一次做后台产品（媒体内容管理方向）的同学观看，老司机可绕道或留言批评指点～

基本框架

有计算机科学背景的同学基本上都知道数据库有这么几个基本操作：增删改查。其实后台产品也是围绕着这几个操作的变体。

以文章评论管理后台为例，运营同学的需求是希望监控所有文章的评论，删除或隐藏部分违规内容。整个过程中的设计思路如下：需要管理哪些内容？操作记录的监控？如何管理权限？

因此从后台的页面结构上来看，一共有三个页面：评论管理页、操作记录页、权限管理页。

文章的评论有一个特点，数据量多且结构相同。可以想象最终的表现形态会类似下图：

从网上随手找的图片

抽象来看，该页面一共分为四个区域，如下图所示：

页面功能区域划分

在列表信息区应当包含以下几个要素：

筛选区基本上是按照列表信息区的要素来进行筛选。如有必要的话，可以将所有的列表信息区元素作为筛选条件。

若无运营特殊需求，在评论管理后台不用设置评论的编辑和新建。

完成之后的原型如下：

操作记录虽然不常用，但是是后台中必不可缺的一部分。后台的操作会直接影响到 C 端用户的感受。如果没有记录下来每一个人在后台的操作，那么这个后台就是一个潜伏的定时炸弹。

操作记录的逻辑很简单，何人何地何事。原型如下：

权限管理有两种方式：

顾名思义，页面权限管理相对而言更加通用。当系统中涉及到多个后台，且希望将后台权限全都交由管理员控制时，页面权限管理适用性能更广。当只针对这一个后台做权限管理时，可以设置成功能权限管理。举个例子：只有管理员有删除权限，运营只有隐藏和置顶权限。

在我们完成文章评论管理后台的需求文档后，应当找运营同学评审一下，看看是否满足运营需求。以我们所完成的后台原型举例，运营同学很可能要求在列表信息中加入：评论文章标题这个信息要素，因此有利于更快定位到评论是否符合规范。

💡 一个体验糟糕，功能不全的后台，会被运营同学铭记于心，时时挂记。因此在和研发同学的正式评审之前，一定要和运营同学确认好是否满足需求。

在一切准备就绪之后，可以喊上研发同学进行正式的需求评审。此类后台产品评审较为简单，沟通清楚所要具备的功能即可。

大部分媒体后台都可以按照这个思路来设计，文章中用到的原型可直接下载使用～

💡 下载后你会发现原来这个东西也可以用来画原型？(不是 Axure，也不是 Sketch，但十分适合用来做后台原型)