繼 工作清單：Functional Map 後，繼續來寫 UI Flow 這部份。如果你不知道什麼是 UI Flow ，請參考 初學者的 UI Flow 這篇文。
UI Flow 比較抽象，但仍包含下列幾個要點：
任務導向
Flow 通常是為了完成某件事而成立，無論是線性還是迴圈，最終都有個任務被完成或取消。產品是由很多個不同任務的 Flow 組成，Flow 和 Flow 間有可能會重疊。如何讓 Flow 簡單、通順、且合理，完全考驗設計者的邏輯能力。
差異
Flow 最重要的就是整理出完成某件事需要經過哪些操作、頁面的動線，包含所有狀態、身份、選擇、操作而產生的差異。只要頁面和操作之間有任何不同之出都盡可能寫得越詳細越好。
- 狀態
- 身份
- 選擇
- 操作
狀態
在 工作清單：Functional Map 一文中提過，狀態是最複雜也最難處理的部份，會牽涉到的部份可能不只一頁，甚至是整個任務流程。EX：編輯與瀏覽狀態、連線與離線狀態。
身份
會員系統常見，已登入和未登入的使用者會看到的頁面和操作流程肯定不同，只要有不同之處就要在 UI Flow 上標示出來。
選擇
因為使用者的選擇導致頁面跟著變化。比如取貨方式，選超商取貨付款後結帳，頁面會導去超商店面列表而不是ATM轉帳畫面。
操作
Mobile 上不同的手勢會有不同的意義，甚至 Portrait 和 Landscape 的畫面與功能也會有所不同。
頁面編號
UI Flow 上規劃幾頁、Wireframe 就該畫幾頁，建議在 Flow 上規劃的每個頁面都標上編號方便對照製作。參考 初學者的 UI Flow 。
如果你擔心漏掉某些在 Fnctional Map 上規劃好的功能，找個空白的地方寫上說明，標明這個編號的頁面要包含哪些內容、哪些功能。
Functional Map 上有什麼，UI Flow 全部都要規劃到。 可以在 Functional Map 上將已完成規劃的內容和功能一項項打勾，確保沒有遺漏，並減少 Wireframe 畫到一半發現某個功能忘記了回頭修改 UI Flow 的機率。
結論
UI Flow 在這個階段還是純文字版本，有了合乎邏輯的操作動線後才會往下個階段前進。所以不會是先畫頁面再考慮操作動線。而是「先考慮操作合理性」再來配置版面。
以前我不太會需要開一個區塊，標明頁面編號，然後寫上功能和內容，直接對照 Functional Map 就能看懂，是因為案子太小、且都我自己一個人處理，靠腦袋理解強記就行了。一旦產品複雜龐大的時候靠人腦完全不足以記得當初每一個頁面為什麼會這樣規劃，或是 Functional Map 、 UI Flow、Wireframe、Mockup 都由不同的專案成員處理時，文件越詳細、越不需要人講解就能看懂越好。
