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

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

基本框架

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

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

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

1. 评论管理

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


从网上随手找的图片

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


页面功能区域划分

列表信息区

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

  • 评论 ID
  • 评论内容
  • 评论时间
  • 评论用户昵称
  • 评论用户 ID
  • 评论文章 ID
  • 状态:正常/隐藏/删除

列表筛选区

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

操作区

  • 置顶
  • 删除/取消删除
  • 隐藏/取消隐藏

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

完成之后的原型如下:


2. 操作记录

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

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


3. 权限管理

权限管理有两种方式:

  • 页面权限管理
  • 功能权限管理

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

需求评审

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

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

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

原型模板

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

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

还有 4% 的精彩内容

推荐阅读更多精彩内容