當一般流程圖的畫法不適用

前面幾篇提到，Logic Flow 有一些限制，像是無法面對複雜的程式邏輯，不具影響順序因素，所以比較適合線性、重複步驟，或是逐步進行任務的流程。

而 UI Flow 在描述 Web 流程和篇幅不會有太好的閱讀體驗。

我們的確也曾透過 Logic Flow 描述功能邏輯和條件。不過除非對業務需求極致了解，不然現在的我回頭看真的是覺得頭很痛😫 （感謝當時的工程師沒說什麼，甚至是覺得其實還不錯，真的是覺得不行 😂…）

在我們團隊中，大部分的專案類型集中於表單後台 Web 專案中。
表單系統的前台畫面上看似簡單，但因為：

1. 無固定使用流程
2. 切換不同欄位會有不同功能模組
3. 表單批准後再修改會需要限制欄位調整條件（Disabled，或選項限制）

同時，隨著專案功能越來越多，100+ 個欄位和 800+ 個檢核也讓功能 SPEC、流程更難交付和表現。不同欄位之間的互動和依賴關係，讓表單系統需要具備高度的靈活性和動態響應能力。如何將這些條件關係撰寫為設計規格則是一個大考驗 😭