在优护家（互联网+基础医疗行业 创业公司）的近四个月的产品实习过程中，前前后后设计了7个后台产品，最近复盘了一下设计的过程，将一些自己踩过的坑总结下来。
后台产品的作用
在分析作用之前，我们可以先看下后台产品的用户是谁，主要就是两种：企业（B）与公司内部的运营人员。其实这两种用户使用后台产品的需求在我看来也只有两个：操作与查看。
我们都知道「增删改查」，其实「操作」的本质就是通过一个可视化的后台，对数据库中的任一记录的任一字段进行增删改，当然在实际中我们会设计很多限制以及权限，让很多信息不能被增删改，或者不能被某一级管理员进行增删改。我将「查看」单独从「增删改查」中拿出来是因为，除了对某一条记录的信息详情查看外，「查看」还包括将信息聚合起来成为可视化的图表，将其展示。
后台产品的展现形式
展现形式就我接触的而言，可以分为两类：
- list + operate（表单+操作）
- Dashboard（仪表盘，可视化数据图表）
其实绝大部分需要有操作功能的后台形式都是list + operate，很好理解，后台产品是非常接近底层的产品，我们知道最底层的数据层就是一个个list，上面说到后台操作类产品的本质就是通过可视化的后台对数据库进行操作，那么后台设计使用list这种形式就非常的自然、简单且容易理解。
例如，在商品管理后台中每个商品其实就是list中的一条记录，我们可以直接通过list上显示的字段对该商品有个大概了解，点击某个商品的详情后可以对这条记录的详情进行编辑；同时可以在list中新增商品，删除商品，当然「删除」比较复杂，涉及到线上现有的产品，需要详细设计可以删除的条件。
设计上需注意的点
（其实也就是我踩过的坑...）
特别熟悉业务
这个放在第一点，非常重要，因为在设计后台时，无论是toB还是公司内部人员使用，往往这个业务的流程是相对固化的。这里引用一段优护家COO赵帅的文章的一段（原文：谈To B产品路径逻辑：To B产品的核心本质到底是什么？）：
假如我们想为某家医院做一套患者随访（随访是指医院对出院患者的持续病情追踪手段）的工具，我们会怎么思考这个问题呢？当我们深入去和医院来沟通这些需求时，我们会发现，一个随访大概有如下步骤：
选中一个患者——选中需要进行的随访模板——选择随访的日期——指派随访的护士——护士执行随访并填写随访记录——护士关闭完成随访。
整个过程至少六步。
我们会发现，这个过程是固定的，一个也省不了，无论是医院A还是医院B，一个随访都至少需要以上的六步，我们无论怎么去优化也是不可能去节省产品路径的。
此时，我们与ToC的产品进行对比会发现，ToC的产品路径是站在用户的即时性需求角度来考虑的，也就是用户当下的体验，而ToB的产品路径一般是站在计划性需求的角度来考虑的，无论是一次随访、一次采购、一次财务报销，它都是一次计划。不会有哪个用户会提前计划自己去和谁聊微信，也不会去提前计划自己去骑行某台单车（预约单车可不算计划），ToC的产品需要在路径上尽可能短，从而满足即时性需求，而ToB的产品路径是由计划好的业务本身决定的，少一步业务就走不下去了，不能因为省麻烦就在随访中不填写随访记录，也不能因为省事就把报销系统中的发票一环省掉。
因此在设计后台产品时，与这个后台相关的业务一定要比任何人要熟悉，熟悉每个流程每种角色可以做什么操作。
字段的校验
因为用户在使用后台时经常需要填写大量的信息，可能就会需要对字段的格式、字数等以及是否必填做校验。在设计的过程中，我建议尽可能少的校验。除了一些必需的限制，比如以手机号作为用户的唯一标识，那么手机号肯定需要必填；我们给医院科室开放的宣教文章编辑器中，一篇宣教标题的字数这种就不需要做限制。
流程复杂时，尽可能分步骤
后台产品很多功能非常复杂，需要填写大量的内容，如果我们把要填的都给堆在一起，一个是用户会觉得这个后台很繁琐不知道自己现在填的信息是什么，一个是只有最后一个提交的接口容易导致这个接口变慢。
比如我们在新建一个护士上门服务时，需要填写名称、描述、选择服务的标准化步骤、商品属性、服务图片、不同属性对应不同的价格、折扣后的价格，选择可服务的护士、可服务的时间段等等信息。最后我们将这些分为了三个步骤，第一步服务的基础信息，第二步是关于价格的设置，第三步关于可服务的人与时间的设置，这样一来就非常的清晰。
删除需慎重
删除是一个非常敏感的操作，会牵扯到线上正在进行中的流程，要考虑到所有情况下删除所带来的所有后果。比如说我们的上门服务中有一项步骤是护士利用护士端App的评估量表对患者进行评估，如果后台开放对评估量表的删除功能，就要考虑已经下单的服务中的这个评估要怎么显示等等。我们曾经关于已发布的量表是否可以修改与删除争论了一下午。
以上是我实习期间关于后台产品设计的一些总结，不足之处还请各位看官指出。
