UI Flow 和 Functional Map 算是最多人容易搞混的兩種圖表吧，Functional Map 主要目的在「將抽象的需求轉變成能被實現的功能」；而 UI Flow 則是「 妥善安排功能與資訊在頁面之間的操作動線 」。兩者很明顯目的不同，所以沒有什麼重工或是很麻煩之類的藉口可以逃避不做。
客戶說：「我要一個能尋找離自己最近的美食餐廳APP，剩下的看你的專業。」
很多客戶只會丟類似這樣一句話出來，再多問什麼問題就只會回答「我不知道」、「看你的專業」、「先出一版讓我看看」。即使如此還是得幫懶得動腦筋的客戶想怎麼做啊…關鍵字有兩個：離自己最近、餐聽，聽起來客戶像是要張地圖或列表、顯示餐聽資訊等等，最好再加點「貼心的設想」讓客戶覺得有在幫他規劃而非敷衍了事，比如說是電話訂位、路徑規劃、幫餐廳分個類等等。
整理後的 Functional Map 會長這樣：
UI Flow 要包含上述所有的功能，我會在畫 UI Flow 時、幻想未來的成品大概長什麼樣子，先在腦海裡把大概的版面都排一排。如果功能複雜架構龐大，我會先定義出 UI Flow 最重要的幾個畫面，在旁邊畫亂撇級的 wireframe 確認其他功能要如何配置比較合理。
設計是解決問題的方法
設計是種科學，介面設計更是邏輯＋科學，不能像藝術家思考一樣隨心所欲，問「為什麼這樣做」時說出「因為我喜歡」這種不科學的答案會被打槍、馬上被人發現其實你根本沒有動腦筋思考前因後果和為什麼、以及是隻菜鳥。起碼要是「因為功能 xxx 和 xxx 有關聯，將類似功能歸類在一起可以加強使用者對這個操作區塊的認知」或是「把最主要和常用的功能放到首頁能加快使用者的操作速度」這種有憑有據的說詞，也比較不會被反駁。
如果一開始不知道 UI Flow 要怎麼開始，就表示 Functional Map 裡提到相關的功能或資訊歸類做得不夠好。一份好的 Functional Map 會清楚讓閱者知道哪些資訊要放在一起、哪些功能在某些模式下才會出現。
根據 Functional Map ，我會把 UI Flow 製作成這樣，可以看到 UI Flow 上不會有餐廳名稱、電話、地址之類的資訊，排序也和 Functional Map 不一樣。
我把 UI Flow 當成是 Wireframe 的目錄，UI Flow 上有幾頁、Wireframe 就該有幾頁。所以打上編號，從 1.0、2.0 開始，必須從 1.0 這個頁面點進去的下一層就會是 1.1，以此類推 1.1.1、1.2.5.2 之類。可以看到圖上有 2.1a 帶個英文字母尾巴的頁面，是我個人習慣的作法，代表這一頁會是在不離開 2.1 的情況下出現新的操作視窗，比如 Popover 或 Modal window 等。好處是可以把「突發狀況」也考慮進去，讓 App 更完整。（參考各種狀態與突發狀況 ）
有趣的是、UI Flow 可能會長得和 Functional Map 相去不遠，看起來就很像是同一份文件，事實上最大的差異在於 UI Flow 在呈現操作動線、頁面和頁面間的層級關係，至於頁面裡面要放什麼內容就要看 Functional Map 了。所以在畫 Wireframe 記得要把這兩份文件都打開，邊畫邊確認是不是所有提到的功能、資訊都有設計到無遺漏。（我自己是會在做好的頁面和已規劃到的功能、資訊上打個勾，像 Todo List 這樣。）
UI Flow 會隨著 Wireframe 而變動是件很正常的事。雖說不應該隨著 Wireframe 更改 UI Flow，如果是做功能很多、或是購物網站這種大型 App，Wireframe 畫一畫突然發現漏了什麼、回過頭去改 UI Flow 也是很正常的事。 UI Flow 和 Functional Map 、Wireframe 記得要做版本控管啊！
至於有的 UI Designer 喜歡做圖片版的 UI Flow，那也是在 Wireframe 畫完後才有辦法做得出來的 超～大～張～圖 ，到那個時候才來設計 UI Flow 就太晚了，很容易出現不合理的動線，我討厭那種大圖，原因見 什麼是 Wireframe ? 。
可以想成是老師發了一張全白的紙下來給大家自由發揮寫作文，你總不會把整篇文章都寫好了才開始畫格線吧？當然是先拿筆和尺把格線畫出來、再往格子裡填上字才會工整漂亮。請照著 Functional Map » UI Flow » Wireframe 的順序，最終結果才不會出現難以挽救的大洞，整個專案成員一起掉坑 （還是屎坑） 。
