我們是這樣藉由 UI Flow 溝通設計

昨天提到將 UI Flow 的作法用於描述局部功能的變化性，今天我們繼續來分享

方法二：專注情境，集中於 UI 的變化

• 針對目標：多個操作角色、多個操作情境/階段的非線性流程，避免展示過多流程步驟，導致閱讀困難。
• 使用方式：以情境為出發點，強調不同的狀態下可能會出現的各種 UI 變化

今天的範例是一個企業內部的案件審批系統，審批的流程相當複雜，包含：提交申請、審批意見、最終批准或退回、批准後重新退件等多個步驟，也有過期後的情境。

不同權限角色在不同的操作情境下，像是申請人瀏覽申請明細，或是審批主管瀏覽申請待審批明細都會會呈現類似，但又不同的畫面。

因此，我們將功能的重點——「審批流程紀錄」、「審批狀態 Badge」功能獨立於 UI 外標記流程，如此可以著眼在單一頁面的細節變化。

可以發現到，已經逐漸脫離「流程圖」的樣子了 😂 表單系統因為流程特別不固定，且前端的呈現會受到情境和不同權限角色的影響，其實會有很大的變化性。

UI Flow>Logic Flow>User Flow？

依據前面幾篇所說，對於前端工程師而言，為了避免資訊分散需要到處比對，是不是只要出 UI flow 就好了？

從昨天跟今天的分享可以發現，答案是否定的，UI Flow 也有其中的限制。因為流程篇幅的過大也會讓閱讀體驗下降，要產出一個 UI Flow 最好是在 UI 已經定稿不會改變後再出，不然每次設計的異動，設計師都需要再調整一次 UI Flow。

Ｑ：有沒有什麼辦法能解決這兩個問題？

1. 讓前端開發直觀的了解業務邏輯和條件如何影響設計模組的切換（UI Flow 的不足）
2. 透過流程圖能理解設計模組中，設計細節的變化（Logic Flow 的不足）

下一篇，讓我們分享經過這些跌宕起伏，團隊共同思考出的流程圖畫法，一次解決以上的問題！