从 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 中等,但是再要优化,就得改变技术架构,成本会比较大,只能与业务方协商,暂时互相妥协。一般来说,随着业务的迭代,架构也是要跟着调整的,但受限于各种客观条件,有时候不得不搁置。

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

 

 posted on 2024-07-22 10:23  咖啡机(K.F.J)  阅读(637)  评论(0编辑  收藏  举报