文章为作者工作总结的几个后台产品设计套路，干货满满，希望其中的设计之道能够给你带来些启发借鉴。

我们在做后台产品的时候，经常会被复杂的业务逻辑的搞得很乱，同时有些时候也不知道接下来该如何设计。的确，后台产品一般由于实际业务的变化而使得需求差异很大，同时由于其繁琐的操作设计流程，许多时候会感觉到无从下手。

但其实，后台产品也有着自己的一些套路，这些套路可以让你在设计后台产品的时候可以有一个较为清晰的步骤目标快速的搭建起一些页面的骨骼，在设计的时候不至于无从下手。

套路一：默认页面一般为统计页面

1、为什么要设计默认页面

有时候我们在登录一些后台产品的时候，在没有权重特别高的需求页面时，默认页面一般不知道放什么。有些产品可能会默认放一些欢迎图片，有些产品甚至就是空页面，什么都没有（我现在公司的产品就是这样）。

可实际情况是，默认页面绝对是系统中很重要的一个页面，用户进入系统的最初接触的就是它，所以说如果对它不进行配置的话会很浪费，同时会让用户感觉整个系统的体验不佳。

2、默认页面的设计分析

笔者认为，默认页面要显示什么，取决于两个方面：

1. 不需要用户的操作并且没有任何前置页面即可展示的功能。
2. 用户在打开系统的时候第一时间想看到什么。

而统计页面，刚好符合这两个方面，首先统计的数据是不需要任何操作进行触发的，它取决于你整体业务及当前使用者截止到目前为止的一个情况，其次用户在打开系统的时候，其目的性就在于要完成工作任务——自己还有哪些工作没有做，以及即将要做什么工作。所以这个时候，数据的统计页面就十分应景。

3、如何设计默认页面

那么统计页面要统计什么数据呢？我认为从三个方面考虑比较得当：

• 当前角色可以看到的系统级别的数据；
• 用户自身要进行操作的数据。
• 通知类内容。

第一个方面我们在设计系统的时候，要考虑到哪些数据是需要统计的，比如电商系统中的下单率，客单价，订单总数，订单总金额、单品销售排行榜等，然后再将这些统计数据通过权限的划分分配给不同的角色。

第二个方面是用户自身的数据，主要有工作流的状态即当前用户的工作流中已经流转到该用户的一些操作，诸如合同审批，发货审批等等一系列的流程。

第三个方面通知类的内容主要有以下几类：

1. 某些关联的工作到一段时间内有了新的状态需要提醒：比如物流发货，或者财务审核通过。
2. 系统内部的一些警醒：比如仓库容量已到临界值。
3. 当前时间截点的警示：比如租户、车位、合同等等即将到期。

套路二：不同功能之间多用标签切换，慎用跳转和新增页面。

1、标签切换方式的背景

在一开始的后台产品中，大多都是基于C/S架构开发的产品。这些产品不仅安装复杂，有些甚至需要配数据库，如果没有专业人员去做这些操作，只凭业务人员很难在一开始的时候将系统配置完善。所以，最初如果说购买了某一家的后台产品，只是在产品的初始阶段，产品的提供方轻则有在线专业客服随时跟进，重则有专门的业务人员上门安装调试。

然而随着HTML5、Ajax等技术的诞生与不断地成熟，如今的后台产品大多都采用B/S的架构，并且体验方面并不比之前的C/S的体验差。然而，由于之前的做法已经深入人心，所以很多那个年代的设计习惯也就被保留了下来，标签切换就是那个时候的产物。

2、为什么不同功能之间要多用标签切换，慎用跳转和新增页面

虽说目前为止，大多的浏览器中内置的标签切换也可以完成页面之间的快速切换操作，但是系统内部的标签切换还是十分有必要的。首先，在这样大面积操作，有着大量字段的页面，点击后肯定是不能覆盖数据直接刷新页面的。同时，还必须兼备着随便切换查看之前的数据做对比分析以及多项工作需要对照同时来做的功能，这样的操作可以快速的定位到当前的操作模块，并且方便的切换。所以这个时候，页面内的标签切换就十分重要了。而对比浏览器的标签页切换，其有以下几点优势：

1. 基于一个页面操作，更像是C/S时代的系统级别的操作，整体操作内容更加规整。
2. 不同的浏览器之间可能有差异，诸如类似IE的浏览器并不是切换标签而是弹出新页面，带来了许多不便。
3. 在系统十分复杂，操作繁琐或者打开页面过多的情况下更容易也更方便定位。

套路三：记录类列表的三大布局模块：筛选、列表和新增

之前曾讨论过“记录类后台产品”的一些特点，记录类后台产品的布局一般都比较固定，分为三大块：筛选（或者叫搜索）部分。列表部分，和新增。如果有一些特殊的业务需要，会可能在这个上面新增一些其他的小的需求，但是大体上这样的布局就可以满足一般的业务。

1、筛选部分要仔细甄别筛选字段

一般来说，筛选部分主要是通过筛选时间段加上每一条记录的字段内容进行的筛选。记录的字段就包括这项业务的特有字段，比如商品列表页面有“商品分类”“商品属性”等；客户列表有“客户等级”“客户手机号”等。

在进行筛选部分的设计时，筛选的字段可以分为选择部分和填写部分。选择部分指的是某些字段的值在填写的时候就已经限定了。只需要选择筛选即可。填写部分就是一些非固定的字段。

同时，在选择填写部分的字段作为筛选条件时，最好不要超过两个，因为填写部分的筛选一般来说都比较精确，过多并没有实际意义。所以在用哪个字段做填写部分的筛选时，就应当慎重考虑。

2、新增部分要考虑交互方式

新增部分一般来说就是一个按钮，点击后有两种方式可以进行记录的新增：一是弹出新页面，二是弹窗形式。新页面的方式在填写字段较多及内容比较重要的时候使用。弹窗形式一般在字段较少，以及内容相对来说不需要十分慎重的填写时使用。

3、重中之重的列表部分设计法则

列表部分是最重要的部分，也是页面的核心部分。页面内容的增删改查，以及核心工作都在这里进行。当然，其列表中的每一条数据都是有一个个的字段值堆叠而成的，字段上大致我分为以下几个部分：

• ID：每一条数据所具备的唯一标识，一般都会加上。
• 时间：数据的产生时间，操作类型的业务字段一般会有，比如库存管理，进货单管理等。配置类的一般可以没有，比如角色配置等。
• 标识名称：确定该条记录的标识名称字段，方便在其他部分用到时进行识别。
• 状态：增删改查很重要的一个部分就是状态的变更及查看。比如“缺货中、货源充足”“已签订、未签订、签订结束”“入场店铺、未入场店铺”等等和业务相关的内容。
• 一系列的标识字段：即新增内容的时候填写的字段需要考虑显示在列表的。
• 其他字段：不是填写的，但是也必须生成的，比如某个用户填写后生成记录会有“填写人”字段。
• 工作流：涉及到工作流时，工作流的状态显示。
• 操作：操作相当于整个页面的核心内容和主要功能。一般有查看、修改、以及对应业务的操作内容。

套路四：复杂难搞的工作流也有套路

工作流可以说是大部分的后台系统中必须涉及到的内容，只要某一项工作不是一个人单独去完成的，那就必然会涉及到工作流。但是同时，工作流也是系统中比较难搞的一部分，无论是技术方面、业务方便还是逻辑方面，工作流都可谓是异常复杂，但系统做多了之后，就会发现即便很难搞的工作流，也有自己的套路。

1、标准工作流和非标准工作流

工作流如果按照概念划分可以分为标准工作流和非标准工作流。标准工作流相对来说比较简单，即某一项工作在进行的过程中，所有的流程都是规划好的。某一个角色和角色的操作都是固定的，要想完成这项工作，只需要一步步的按照流程来即可完成。

非标准工作流则有些复杂，它会涉及到与或非这样的逻辑判断，我相信对于一个产品经理来说这样的判断并不是什么难事。比如某一项工作在进行哪一步的时候审核通过是一个流程，审核不通过是另一个流程，在某一步时两种角色都可以进行操作，或者两种角色都必须进行操作才能进行下一步。这样的流程是要比标准工作流复杂一些，但是遇到一些复杂的业务是必然会涉及到的。产品经理对于流程的梳理我相信问题不会很大，唯一要仔细的就是不要遗忘流程或者角色，这时有些时候对于一些工作来说是致命的。

2、如何设计工作流

对于一些系统而言，许多的权限都是可以自定义配置的，所以对应的工作流当然也可以进行配置。那么在配置的时候，把每一层的逻辑都考虑清楚，是必然需要考虑的。我的套路一般都是先配置流程，再配置角色，配置流程的时候，如果操作者有一定的技术能力，可能让其用SQL语句进行自定义配置，如果没有的话可以用流程图的形式表现出来再往里面填加角色。如果要再小白一些，可以将每一个非标准化流程拆成一个个的标准化流程，单独去配置，虽说麻烦一些，但是对于用户来说，整体的操作逻辑则会简单很多。

套路五：生杀大权——“权限配置”

权限配置对于一个后台系统来说也十分重要，可以说权限配置就相当于用户的生杀大权，掌握着你可以做什么，不能做什么。所以设计好权限配置的模块，就显得十分重要了。

1、用户角色配置和角色权限配置

权限配置一般分为两个部分，用户角色配置和角色权限配置。有些系统可能比较简单，所以在设计的时候，初始就直接给用户附上了某些权限。在初始的时候，可能会觉得比较便捷，但是一旦用户变多，处理起来就相当的麻烦。所以在一开始设计系统的时候，就要将角色和用户分清楚。

2、如何设计权限配置

在配置权限的时候，应当配置的是角色的权限，将权限赋予角色之上，比如“采购员”“库管”等。另外有些权限的功能可能用语言表述不清楚，这时就可以将链接加上，点击可以明确的查看这个功能是做什么的。如果再严谨一些，可以将资源的路径写上，确保其唯一性。在配置用户角色的时候，用户可以赋予多个角色。这样分开来配置，会更加的合理。

以上就是我总结的一些套路。后台产品可以说博大精深，每一个系统所做出来的东西也有着千姿百态的差异。但是我们要在不同中寻求相同，找出其中的套路，以不变来应万变。

专栏作家

执迷，微信公众号：执迷有悟，人人都是产品经理专栏作家。电商O2O领域，关注数码硬件，人工智能，新闻资讯领域。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议