便签看板之规则树复盘

俗话说的话：字不如表，表不如图。

图在设计的表现中有很多种办法比如图片数据概览或者看板的办法，是一种通过视图来表现的统称。
本日就讲规则树设计与业务的结合，希望对付读者有所启示。

一、业务情形

管理者须要自己属下部门/干系类型的每一个用例所处的节点以及状态，对上要做申报请示总结，对下要做KPI统计以及管理。

以前的路径是就须要将用例所有干系的信息筛选出来进行逐步的剖析才能知道任务到达的进度如何以及卖力人是谁，查看相对来讲比较频繁，因此信息的快速传达比较关键。

二、业务难点

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

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

三、办理方法1. 为什么选择规则树？

1周经由对20位主管进行调研创造，主管更加关注的是节点进度，至于卖力人是须要进行查看的，紧张是确认任务人。

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

甘特图：X-资源花费/资源名称/任务进度 Y-小时/天/星期日程看板：X-预约的事宜 Y-天/周/月/年

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

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

2. 分层处理

1）底层-点状背景，降落视觉疲倦

页面须要用户永劫光查看，纯色无论是选择白色还是灰色都会导致用户视觉疲倦，从而降落查看的本钱。
同时也是引用了测试常见的“点点操作”，增加了行业属性。

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

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

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

为什么收起第5级？前4级数据相对来讲比较固定会超过20，但是末了一级的用例实行层，单条的同级可能有上百条，内容量较大，页面承载量较大，页面承载压力大，刷新速率慢。
由于还有紧缩的操作，数据数量激增的话，页面的安全性就会降落。

3）收纳内容，增加安全性

将末了一级别固定到右边的详情页内容，并且以表格形式展现，可以容纳几百条测试用例信息，同时采取

4）上层-操作层

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

①鼠标的滚轮-放弃放大缩小，采取旁边滑动

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

②鼠标点击-查看缩略图，降落查算作本

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

四、用户反馈

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

五、后期展望

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

六、总结

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

专栏作家

一只鸡腿，微信公众号：B端设计一只鸡腿，大家都是产品经理专栏作家。
一个吃货的B端设计师。

本文原创发布于大家都是产品经理，未经容许，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。