从 0 开始搭建一套后台管理系统，成本巨大，所以都会选择一套成熟的组件库，基于此，再堆叠业务逻辑。我们公司的组件库基于 Ant Design。Ant Design 包含一套完整的后台解决方案，不仅提供了 75 个组件，还开源了整套设计方案，配色、字体、图标、布局等，还分享了众多的用户体验案例。官方基于 Ant Design 中的组件，还提供了一套开箱即用的中台前端/设计解决方案：Ant Design Pro，更贴近于页面研发，缩短开发时间。本文的很多优化思想，都来源于这两套开源库，不过也增加了很多自己的理解。

一、站在巨人的肩膀上

　　在将系统呈现给用户之前，有必要用专业的眼光来为系统做一次初步的优化。下图是基于上述 2 个库整理的一张思维导图，包含了一个管理后台常用的几个部分，完善这几部分，可以让用户在使用系统时有较好的体验，像图表可视化之类较为特殊的模块并没有列出。

1）基础结构

　　管理后台的全局结构比较固定，包括侧边顶部的 Logo、侧边菜单、顶部菜单、面包屑导航。

　　侧边菜单可以隐藏，若要有更好的体验，还可以将宽度变为可自定义，例如左右拖动修改宽度。后台用户的页面权限也会集中到侧边栏，有权限的展示，无权限的隐藏。

　　在顶部菜单中，不仅仅可以用于导航（修改资料、登出等），还可以增加快捷的检索按钮，例如输入用户 ID，得到一个弹框，展示用户详情，包括基础资料、订单、操作记录、相册、设备等，将这些信息聚合在一起，便于查询。

　　当一个页面中有比较多的内容时，可以用标签页来分离，一个标签对应一个子页面。

　　回到顶部，在比较长的页面中比较实用，这个按钮也应该是管理系统不可获取的一个组成部分。

2）反馈

　　当用户和系统需要交互时，就得为用户在各个阶段提供必要、积极、即时的反馈。但同时要避免过度反馈，以免给用户带来不必要的打扰，对于能够及时看到效果的简单操作，可以省略反馈提示，下面是一组反馈示例。

　　常见的结果反馈可以分为两种：顶部全局提示和对话框提示（上图所示）。顶部全局提示就是 Toast，比较轻度，过几秒后会自动隐藏。而对话框提示就比较重，会终止用户操作，用于传递非常重要的信息。

　　表单的操作过程中可通过不同的校验规则给用户提供表单校验提示（上图所示），让他们及时的纠正错误。在表单中，对于比较复杂的字段，可以用气泡卡片的方式提供补充说明（下图所示）。

　　交互的操作过程中尽可能将状态反馈给用户，即时的响应会给用户增加信赖感。在操作需要较长时间才能完成时，显示该操作的当前进度和状态。若加载时间较长，应提供取消操作。

　　当目标元素的操作需要用户进一步的确认时，可以通过气泡确认框在目标元素附近弹出浮层提示，以此来询问用户，常见于数据列表操作一列中的按钮。

3）数据列表

　　数据列表在整个管理系统中占比非常重，其结构也比较固定，最上边是数据过滤（即查询条件），然后是数据统计（可选项），再有是数据列表（即表格区域），其中还包含列表工具栏（新建、刷新、排序等功能），后面是分页栏（图中没有画出），最后是批量操作。

　　在 Ant Design Pro 中有专门的组件实现查询条件，内置查询和重置两个按钮，当条件比较多时，还能自动隐藏。在下图中，就能看到列表工具栏（贴在表格上边），提供的是批量导入、导出数据、创建应用等，这些按钮都可自定义。由于列表的字段较多，还提供了左右滚动，并且第一列和最后一列固定。批量操作是固定在页面底部的，并且会显示选中的数量。

　　在列表的加载过程中，可以提供骨架屏过渡，加载完成后，显示数据。当没有数据时，要提供空状态占位，而不是空白一片。

　　数据加载完成后，在悬停时，可以为当前那一行增加底色辨识。

　　文字链的点击范围受到文字长短影响，可以设置整个单元格为热区，以便用户触发。

　　分页器可以让用户清楚的知道自己所要浏览的内容有多少、已经浏览了多少、还剩余多少。当信息条目较多的时候，可以允许用户自定义每页的行数，以提高用户查看和检索信息的效率和灵活性，常与表格、卡片搭配使用。下图展示了分页器的各个部分，以及常用的功能。

　　上述是比较常见的数据列表，还有几类比较特殊的数据列表。第一种是行内可编辑的表格，点击操作列的编辑后，只读的列变为可操作的控件，比较快捷的编辑方式，适合字段较少的列表。图中最下面的添加一行数据，是一种的特殊的复制按钮。

　　第二种是可拖动排序的表格，将鼠标左键按住第一行的 icon，然后就能拖动这一行了。

　　第三种是卡片列表，展现形式与常规列表较为不同。在卡片中，可以根据业务侧重元素，例如提供放大图像的功能。

4）表单

　　表单也是后台系统中不可分割的一部分，现在很多时候不是单独的页面，而是数据列表的一部分。例如点击列表中的某个字段出现浮层表单，浮层的形式可分两种：弹框（Modal）和抽屉（Drawer），弹框适合字段较少的表单，如下所示。

　　由于抽屉提供的空间比较多，因此能包含更多的字段，如下所示。

　　除了浮层表单之外，对于较为复杂的表单，可以使用分步表单。将用户需要填写和确认的信息按照线性流程组织，利用步骤条告知用户完整的流程和进度，常常在最后提交前让用户再次确认信息，并在流程结束后给与明确的结果反馈。

　　登录表单是一种比较特殊的表单，独立于系统的基础布局结构。一般都会简单点，只提供用户名和密码登录，省略短信登录。

　　常用的表单控件包括输入框、单选框、多选框、下拉框等，这类都比较简单，复杂的有上传、数据联动和复制等。文件上传可以用比较简单的展现形式，如下所示。

　　而图像上传因为需要预览，所以得提供一块预览区域，常见的就是将按钮区域放大。

　　还有一种拖动上传，为了更好的体验，在上传的过程中，还需要实时更新进度条。

5）按钮

　　按钮虽然是一个小元素，但是它遍布整个系统，哪都有它。对于按钮，目前也有了一套成熟的设计规范，主要体现在样式和交互两方面。在下图中，1 是次按钮，2 是主按钮，3 是文字按钮，4 是图标按钮，5 是在按钮中添加图标。

　　主按钮是主色填充，表示高强调，其余按钮的强调级别依次降低。

　　红色用于警示用户该操作存在风险，通常删除按钮会被赋予红色。

　　在移动到按钮位置时，需要有个聚焦效果，例如高亮。在点击按钮时，需要有个过渡效果，例如增加阴影，确认点击成功。在通信时，可以有个加载效果。

6）其它

　　响应式是为了让后台可以支持移动设备的访问，在没有电脑的户外情况下，也能浏览后台，操作管理。

　　暗黑模式是一种体验优化，比较适合夜晚办公，也比较符合程序员的审美。在公司内部上线后，很快得到了业务方的肯定，还督促产品完善客户端的夜间模式。

　　异常页面也是后台系统不可缺少的一部分，权限不足提示 403，页面不存在提示 404，服务器错误提示 500 等。通过异常页，可以解释发生了什么异常，为用户提供相应的建议或操作，避免用户感到迷失和困惑。

二、紧贴业务

　　虽然开源库已经扫清了许多的体验障碍，但是在实际业务中，还是会出现各类问题，集中体现在流程、功能、性能等方面。例如流程过于繁琐，需要简化；功能太少，需要补充；页面太卡，难以操作等。不过在优化体验之前，需要保证业务进度不受影响，换句话说，就是要有空闲的人力资源去做体验优化这个工作。

1）解放生产力

　　解放生产力就是为了让更多的人能参与到优化的工作中。我们团队之前在开发管理后台时，会先找一张类似的，然后复制一份，修改文件名称，在此基础上做改动。既然能复制，那就说明有很多共通之处，在整理 200 多张页面后发现，几种常规的布局大概占总页面数的 80% 以上，只有很小一部分的页面需要专门定制，那么接下来就是抽象出常规布局中所包含的组件。

　　模板组件呼之欲出，经过一周多时间的调试，在组内开始推广。在开发这套组件的时候，预留了许多回调，可根据不同场景做自定义的逻辑。在模板组件上线后，就将页面的开发从3天降低至1天以内，有些简单页面两三个小时就能布局完成。后续在浏览 Ant Design Pro 的组件库时，发现我的模板组件与这些组件类似，但是功能更为的丰富完善，能够适应更多复杂的场景。

　　这是一次非常典型的降本提效的经历，除此之外，我们还在研发各类工具，让各种业务走可视化的配置，不用再单独研发。例如一个将榜单活动配置化的工具，就是将常用的活动做成可视化配置的形式，目的是减少开发和测试人力，将 2 天的研发时间压缩至 2 小时。这个配置协调了 UI 组、产品组、测试组、前端组、数据组一起，制订出了相关规范，已成功运营了几十场活动。

　　给我们组自己减负，也是一个目标，那么也需要开发许多趁手的工具。例如设计BFF 平台，在研发完成后的一段时间才开始推广，我们组比较慢热，有段时间，新的业务接口基本都会走此平台，线上已有 70 多个接口在稳定运行着。

　　为了提升管理后台的开发效率，先后研发了后台页面可视化编辑器（即低代码）第一版和第二版，第一版组员接受度并不理想，第二版已经上线了 2 个菜单。不过，在使用体验上并不理想，后续还需要迭代完善，才能真正使用。
当然，解放生产力和体验优化大部分情况下是并行进行的，在进行一段时间后，获取的收益将会非常高。

2）发现问题

　　接下来谈谈发现问题，像流程、功能、性能等问题都是在深度使用后台系统后，才能遇到，因此想要发现这类问题，需要与相关人员交流。有条件的话，可以进行一对一的交流，提前通知后，让他们准备下。因为是给他们解决实际问题，所以一般情况下，他们都会积极配合。当时一下子收到了几十个问题反馈，经过整理后，修复比较容易实现的问题，诸如换个字体颜色、加个筛选条件、增加一列等。果断上线后，效果非常好，对你来说是一个小改动，但对业务方来说，却是实打实的提升工作幸福感。

　　另外一个发现问题的方法是发放满意度问卷，相比上一个方法，受众面更广，成本更低。毕竟一对一是要抽出双方时间的，不能频繁使用。但相对来说，一对一耳闻目染的效果肯定是最好的。如果收到的是高质量的问卷，那么收获也是满满的。

　　问卷的题目形式包括单选和问答，不要包含太多的专业术语，通俗描述，答案也不一定要用标准的五级量表（非常满意、满意、一般、不满意、非常不满意），可以更具象地去描述答案，方便用户选择。例如：

• 对XX页面不太满意的原因是什么？
  • 开发人员误解了需求
  • 项目延期
  • BUG太多不能用
  • 其他

　　当选择其他时，可以提供文本框，输入具体原因。

　　除了在这类正式场景中获取问题之外，在日常时刻，其实也可以发掘，例如听到有人在抱怨 XX 功能太难用时，就可以去搭话了、某人在群聊中提到某功能有异常时等等。

　　有些体验问题也可以自己去发掘，例如某个数据列表中的字段由于太多，导致位置变形了，那么你可以主动去增加左右滚动条。筛选条件太少，就增加几个。日常也可以去观察其他开源管理系统的功能，考虑是否可以增加到自己的系统中，提升体验，响应式和暗黑模式就是在浏览其他系统时得到的灵感。

3）解决问题

　　解决问题的核心本质就是资源成本是否能负担的起。某些比较重要的体验问题，尤其是需要多端协调的，可以将其加到版本迭代中，这样既能引起重视，也能安排一个固定时间分出资源来解决。

　　不过大部分时候，体验优化上不了台面，提不上日程，优先级比其他需求要低很多。但好在管理后台大部分是由我们全栈管理着，优化工作可以由我们自己承担，不需要找人协作，可控性比较大。可以将那些优化见缝插针，逐个击破。

　　有些优化难以彻底解决，只能在已有条件下做到最好。例如后台有个审核内容的功能，可以一次性提交 200 条记录，在提交后，服务端会串行的做一系列的逻辑处理，那么不可避免的就会让接口响应会变慢。虽然在接口中，已经做了数据库表的索引，以及尽可能的与数据库少交互，包括一次性从数据库中读取多条记录，将数据缓存到 Redis 中等，但是再要优化，就得改变技术架构，成本会比较大，只能与业务方协商，暂时互相妥协。一般来说，随着业务的迭代，架构也是要跟着调整的，但受限于各种客观条件，有时候不得不搁置。

　　各个公司的业务都会有所不同，遇到的业务优化问题也会大相径庭，并没有银弹，得根据实际情况分析，在现有资源的前提下，找到最优解（占用的资源最少，得到的效果大家都能认可），这是一个平衡的过程，需要多多尝试。