">

后台产品的作用

在分析作用之前，我们可以先看下后台产品的用户是谁，主要就是两种：企业（B）与公司内部的运营人员。其实这两种用户使用后台产品的需求在我看来也只有两个：操作与查看。

我们都知道「增删改查」，其实「操作」的本质就是通过一个可视化的后台，对数据库中的任一记录的任一字段进行增删改，当然在实际中我们会设计很多限制以及权限，让很多信息不能被增删改，或者不能被某一级管理员进行增删改。我将「查看」单独从「增删改查」中拿出来是因为，除了对某一条记录的信息详情查看外，「查看」还包括将信息聚合起来成为可视化的图表，将其展示。

后台产品的展现形式

展现形式就我接触的而言，可以分为两类：

其实绝大部分需要有操作功能的后台形式都是list + operate，很好理解，后台产品是非常接近底层的产品，我们知道最底层的数据层就是一个个list，上面说到后台操作类产品的本质就是通过可视化的后台对数据库进行操作，那么后台设计使用list这种形式就非常的自然、简单且容易理解。

例如，在商品管理后台中每个商品其实就是list中的一条记录，我们可以直接通过list上显示的字段对该商品有个大概了解，点击某个商品的详情后可以对这条记录的详情进行编辑；同时可以在list中新增商品，删除商品，当然「删除」比较复杂，涉及到线上现有的产品，需要详细设计可以删除的条件。

设计上需注意的点

特别熟悉业务

这个放在第一点，非常重要，因为在设计后台时，无论是toB还是公司内部人员使用，往往这个业务的流程是相对固化的。因此在设计后台产品时，与这个后台相关的业务一定要比任何人要熟悉，熟悉每个流程每种角色可以做什么操作。

字段的校验

因为用户在使用后台时经常需要填写大量的信息，可能就会需要对字段的格式、字数等以及是否必填做校验。在设计的过程中，我建议尽可能少的校验。除了一些必需的限制，比如以手机号作为用户的唯一标识，那么手机号肯定需要必填；我们给医院科室开放的宣教文章编辑器中，一篇宣教标题的字数这种就不需要做限制。

流程复杂时，尽可能分步骤

后台产品很多功能非常复杂，需要填写大量的内容，如果我们把要填的都给堆在一起，一个是用户会觉得这个后台很繁琐不知道自己现在填的信息是什么，一个是只有最后一个提交的接口容易导致这个接口变慢。

比如我们在新建一个上门服务时，需要填写名称、描述、选择服务的标准化步骤、商品属性、服务图片、不同属性对应不同的价格、折扣后的价格，选择可服务的人、可服务的时间段等等信息。最后我们将这些分为了三个步骤，第一步服务的基础信息，第二步是关于价格的设置，第三步关于可服务的人与时间的设置，这样一来就非常的清晰。

删除需慎重

删除是一个非常敏感的操作，会牵扯到线上正在进行中的流程，要考虑到所有情况下删除所带来的所有后果。比如说我们的上门服务中有一项步骤是护士利用护士端App的评估量表对患者进行评估，如果后台开放对评估量表的删除功能，就要考虑已经下单的服务中的这个评估要怎么显示等等。我们曾经关于已发布的量表是否可以修改与删除争论了一下午。