UI Flow 的限制

不過可以注意到，App 產品因為尺寸，也因為有較多頁面、功能切換的效果，很建議用 UI Flow 的方式交付設計。

但 Web 設計因為 「UI Mockup 尺寸較大」 的特性，且擁有更複雜的操作行為，除了設計師外的第三人在閱讀 UI Flow 時通常不會有太好的體驗。

可以參考下圖是我們在經歷一系列流程優化前所出的 UI Flow，效果很差對吧 😭 不僅是資訊接受方，設計師也是會迷失在那麼多看起來像似的畫面之中。

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

為了解決更有效的表達流程，我們的 Web 專案採取了兩個更有效的流程圖畫法：

作法一：只用於描述「局部」功能的「局部」畫面

• 針對目標：局部功能受條件影響變化性大，讓開發不易理解和記得流程。
• 使用方式：專注於每一個功能模塊局部的操作流程。

這邊用一個需求作為舉例。
這是在畫面上其中的一個區塊。在編輯項目草稿時，使用者在 Step1 選擇不同的欄位選項（活動類型/活動模式/活動起迄日），會跨步驟的讓第二步的流程無法繼續下去，並需要出現對應錯誤訊息。而若建檔綁定 Step2 的選項後（信用卡、台幣、外幣分別為三支 API），需要將不可點選的選項 disabled、鎖定。

因為不同的錯誤（打Ｘ的）會有不同的錯誤提示文字。因此，若有兩個Ｘ，則需跳兩行錯誤 Toast（提示訊息）。下圖為最終的 UI Flow。

其實光這樣，這張流程圖的篇幅就已經很龐大了！

明天再繼續分享 Web UI Flow 的第二種畫法！