俗话说的话：字不如表，表不如图。图在设计的表现中有很多种方式比如图片数据概览或者看板的方式，是一种通过视图来表现的统称

前言

俗话说的话：字不如表，表不如图。图在设计的表现中有很多种方式比如图片数据概览或者看板的方式，是一种通过视图来表现的统称。今天就讲规则树设计与业务的结合，希望对于读者有所启发。

业务情况

管理者需要自己属下部门/相关类型的每一个用例所处的节点以及状态，对上要做汇报总结，对下要做KPI统计以及管理。以前的路径是就需要将用例所有相关的信息筛选出来进行逐步的分析才能知道任务到达的进度如何以及负责人是谁，查看相对来讲比较频繁，因此信息的快速传达比较关键。

业务难点

现有业务场景中部门的管理者向上汇报前都要查询和分析进度，数据概览也就是可视化数据部分只能从某个角度「整体项目/某一类的项目等等」进行分析，无法展现具体的具体达到的任务节点以及当前节点/同属节点的状态，需要极长的分析时间以及成本。大概把问题分解为2个：

1. 数据操作复杂：现有业务中一个测试到计划再到执行中的用例，往往包含着几百条数据，每条数据的详情又有其自己的详情要查看，就导致了内容的左右横跳。这只是查看还没有算统计成本。
2. 信息呈现杂乱且层级不清：现有的表格是根据计划/策略的优先级以及时间进行排序的，信息比较大（有的用户要求加到一页1000条之多）呈现上对于主管毫无规律。现有的测试用例分别以5张表格进行区分和收纳，意味着每次都查看多张以上表格才能查看到完整的进度，层级不够明确。

解决措施

为什么选择规则树？

1周经过对20位主管进行调研发现，主管更加关注的是节点进度，至于负责人是需要进行查看的，主要是确认责任人。

总结一下就是以阶段/节点为支撑/主干，呈现用例的进度以及父子级的关系。在这之前想过常规的甘特图和日程看板形式，但是分析下来如果以横纵坐标轴将甘特图和日程看板形式分别拆解成是：

1. 甘特图：X-资源消耗/资源名称/任务进度   Y-小时/天/星期
2. 日程看板：X-预约的事件   Y-天/周/月/年

从时间上讲，每个策略在业务中的确能到3月到半年的强度，但是分到每一个测试用例可能才几分钟左右，着中时间跨度过大。从资源上讲，项目中更加消耗的是人力资源，但是不是每个人都要参与到全流程，大部分人都只是做自己节点上的事情，所以并不适合。

从核心需求讲，阶段/节点和进度尤其关键，而不是人力。因此我们选择了规则树的呈现方式。

分层处理

底层-点状背景，降低视觉疲劳

页面需要用户长时间查看，纯色无论是选择白色还是灰色都会导致用户视觉疲劳，从而降低查看的成本。同时也是引用了测试常见的“点点操作”，增加了行业属性。

中层-固定分区，增强安全性

先将内容区分成注释区与树选择内容，注释置放在左上角呈现，内容放到底部呈现。内容再根据5个阶段分成5个阶段，从左到右进行呈现，展现4级，收起第5级。

再讲内容分为：规则树与详情区域

为什么收起第5级？

前4级数据相对来讲比较固定会超过20，但是最后一级的用例执行层，单条的同级可能有上百条，内容量较大，页面承载量较大，页面承载压力大，刷新速度慢。因为还有收缩的操作，数据数量激增的话，页面的安全性就会降低。

收纳内容，增加安全性

将最后一级别固定到右边的详情页内容，并且以表格形式展现，可以容纳几百条测试用例信息，同时采用懒加载或者是分页的交互方式提高页面的数据加载速度，降低同时产生的数据朗以及收缩数据呈现的时间。

上层-操作层

操作分成2种：鼠标的滚轮与左键的点击

鼠标的滚轮-放弃放大缩小，采用左右滑动

滚轮的放大缩小是现在常见的交互方式，尤其是在规则树这种交互页面之上。产品有他自己的特殊性，一旦全局放大缩小，表头节点的分区就会一起跟着放大与缩小，就会导致识别苦难的场景，因此在交互上做了限制将放大缩小换成左右滑动方便查看。

鼠标点击-查看缩略图，降低查看成本

针对小屏幕，在内容较多的场景进行适配发现，很难一次性显示出来，因此采用了团队中程序员常用的工具：VIS Code(我自己日常也会一些代码，所以我自己也会用)中查看代码缩略图交互方式，来降低用户拖拽交互的成本。

用户反馈

灰度上线一个月后，用户满意度提高7.8%。

后期展望

现在的交互还不够完善，比如：放大缩小等等。因为后期还需要再完善与跟进。还有这种看板在制作的时候，最好多跟前端尽心沟通，很多时候设计师心理和观念是好的，但是会导致开发成本过高。

总结

以上就是业务到设计进行的拆解分享，B端设计师核心诉求还是要满足才是根本，希望能对读者，谢谢观看。有不同的观念可以随时沟通。

Powered by Froala Editor