多數人在工作的時候會使用規則樹，對階段/節點和進度很有效，下面這篇文章是筆者整理分享關于規則樹設計與業務的結合的相關內容，想了解的同學可以進來看看呀！

俗話說的話：字不如表，表不如圖。圖在設計的表現中有很多種方式比如圖片數據概覽或者看板的方式，是一種通過視圖來表現的統稱。今天就講規則樹設計與業務的結合，希望對于讀者有所啟發。

一、業務情況

管理者需要自己屬下部門/相關類型的每一個用例所處的節點以及狀態，對上要做匯報總結，對下要做KPI統計以及管理。

以前的路徑是就需要將用例所有相關的信息篩選出來進行逐步的分析才能知道任務到達的進度如何以及負責人是誰，查看相對來講比較頻繁，因此信息的快速傳達比較關鍵。

二、業務難點

現有業務場景中部門的管理者向上匯報前都要查詢和分析進度，數據概覽也就是可視化數據部分只能從某個角度「整體項目/某一類的項目等等」進行分析，無法展現具體的具體達到的任務節點以及當前節點/同屬節點的狀態，需要極長的分析時間以及成本。大概把問題分解為2個：

1. 數據操作復雜：現有業務中一個測試到計劃再到執行中的用例，往往包含著幾百條數據，每條數據的詳情又有其自己的詳情要查看，就導致了內容的左右橫跳。這只是查看還沒有算統計成本。
2. 信息呈現雜亂且層級不清：現有的表格是根據計劃/策略的優先級以及時間進行排序的，信息比較大（有的用戶要求加到一頁1000條之多）呈現上對于主管毫無規律?，F有的測試用例分別以5張表格進行區分和收納，意味著每次都查看多張以上表格才能查看到完整的進度，層級不夠明確。

三、解決措施

1. 為什么選擇規則樹？

1周經過對20位主管進行調研發現，主管更加關注的是節點進度，至于負責人是需要進行查看的，主要是確認責任人。

總結一下就是以階段/節點為支撐/主干，呈現用例的進度以及父子級的關系。在這之前想過常規的甘特圖和日程看板形式，但是分析下來如果以橫縱坐標軸將甘特圖和日程看板形式分別拆解成是：

1. 甘特圖：X-資源消耗/資源名稱/任務進度 Y-小時/天/星期
2. 日程看板：X-預約的事件 Y-天/周/月/年

從時間上講，每個策略在業務中的確能到3月到半年的強度，但是分到每一個測試用例可能才幾分鐘左右，著中時間跨度過大。從資源上講，項目中更加消耗的是人力資源，但是不是每個人都要參與到全流程，大部分人都只是做自己節點上的事情，所以并不適合。

從核心需求講，階段/節點和進度尤其關鍵，而不是人力。因此我們選擇了規則樹的呈現方式。

2. 分層處理

1）底層-點狀背景，降低視覺疲勞

頁面需要用戶長時間查看，純色無論是選擇白色還是灰色都會導致用戶視覺疲勞，從而降低查看的成本。同時也是引用了測試常見的“點點操作”，增加了行業屬性。
2）中層-固定分區，增強安全性

先將內容區分成注釋區與樹選擇內容，注釋置放在左上角呈現，內容放到底部呈現。內容再根據5個階段分成5個階段，從左到右進行呈現，展現4級，收起第5級。

再講內容分為：規則樹與詳情區域

為什么收起第5級？前4級數據相對來講比較固定會超過20，但是最后一級的用例執行層，單條的同級可能有上百條，內容量較大，頁面承載量較大，頁面承載壓力大，刷新速度慢。因為還有收縮的操作，數據數量激增的話，頁面的安全性就會降低。

3）收納內容，增加安全性

將最后一級別固定到右邊的詳情頁內容，并且以表格形式展現，可以容納幾百條測試用例信息，同時采用懶加載或者是分頁的交互方式提高頁面的數據加載速度，降低同時產生的數據朗以及收縮數據呈現的時間。

4）上層-操作層

操作分成2種：鼠標的滾輪與左鍵的點擊

①鼠標的滾輪-放棄放大縮小，采用左右滑動

滾輪的放大縮小是現在常見的交互方式，尤其是在規則樹這種交互頁面之上。產品有他自己的特殊性，一旦全局放大縮小，表頭節點的分區就會一起跟著放大與縮小，就會導致識別苦難的場景，因此在交互上做了限制將放大縮小換成左右滑動方便查看。

②鼠標點擊-查看縮略圖，降低查看成本

針對小屏幕，在內容較多的場景進行適配發現，很難一次性顯示出來，因此采用了團隊中程序員常用的工具：VIS Code(我自己日常也會一些代碼，所以我自己也會用)中查看代碼縮略圖交互方式，來降低用戶拖拽交互的成本。

四、用戶反饋

灰度上線一個月后，用戶滿意度提高7.8%。

五、后期展望

現在的交互還不夠完善，比如：放大縮小等等。因為后期還需要再完善與跟進。還有這種看板在制作的時候，最好多跟前端盡心溝通，很多時候設計師心理和觀念是好的，但是會導致開發成本過高。

六、總結

以上就是業務到設計進行的拆解分享，B端設計師核心訴求還是要滿足才是根本，希望能對讀者，謝謝觀看。有不同的觀念可以隨時溝通。