前言

這是「產品規劃系列」的第三篇文章，在前面我提到了軟體 PM 撰寫 Spec (產品規格書)時至少包含三種文件：User Story、 Functional Map、UI Flow，並說明 User Story 、Functional Map可以如何撰寫。

這篇文章我們說說第三種文件 —UI Flow，應該如何撰寫。

一、UI Flow是什麼，該怎麼寫？

UI Flow 顧名思義就是 UI (User Interface) 的流程，也可以說是流程圖總稱，用於和開發人員確認所有狀態和需要功能，是後續繪製Wireframe的重要依據。

UI Flow 是從 Flow Chart (流程圖) 演變而來，因此我們先快速了解一下 Flow Chart 應該如何繪製。

下圖是會員登入的流程圖，看起來簡單的流程實際上就包含了 4 個常用到的元素 — 起/終點、處理流程、資料產生(Input/Output)、抉擇(IF…ELSE…)。

許多人對 UI Flow 的印象是：「畫面」與「畫面」之間的流程連結，也就是當使用者點擊畫面中的某個地方時，會觸發下一個畫面的產生。

在分析上，這樣其實跳躍了一步，上方所說的流程圖叫做 Wire Flow。在繪製 Wire Flow 之前，我們可以先使用文字來表示每個畫面並繪製流程圖，也就是這邊想講的 UI Flow。

以電商網站常見的購物流程來舉例，當使用者進到電商網站後，他/她會經歷以下流程：

像這樣用文字來表示每個頁面、將每個頁面做編碼，並且透過箭頭進行連結的流程圖，就叫做 UI Flow。

你可以會問說，這些頁面是哪裡來的？還記得上一篇文章提到的 Functional Map嗎，這些頁面是先在 Functional Map 進行盤點，現在才被當作繪製 UI Flow 的基礎。

Wireframe的定義是：

產品的建構藍圖，以單純的色塊或線條來規劃版型。

有了 UI Flow，產品經理/設計師就可以一頁頁的繪製 Wireframe，大概會長的像以下的樣子：

一份好的 Wireframe 除了要有基本的元素及位置成列外，也必須對這些元素限制進行註解，方便工程師後續開發時要留意的邏輯。以下是繪製 Wireframe的小訣竅：

當 UI Flow 與 Wireframe 都完成後，就可以來繪製 Wire Flow。

這篇文章說明了「Flow Chart」、「UI Flow」、「Wire Flow」的差異，透過漸進的文件產出，最終可以得到一份完整的功能/畫面規格。

謝謝你願意讀到，到這邊「產品規劃系列」正式結束，希望同為 PM 或是產品規劃的你可以得到一些啟發，有任何想法都歡迎留言討論～

一個組織能力超強的軟體產品經理，喜歡研究軟體產品、生產力工具、時間管理方法

可提供軟體產品管理、時間管理、生產力工具的相關諮詢

歡迎講座邀約或跟我喝杯咖啡聊聊天，我的信箱是 [email protected]

無論在我們的設計過程中裡做什麼，其實都與同個目標綁在一起，那就是：「打造最好的產品和體驗。」而這需要花費大量的設計迭代和數不清的溝通，而原型製作只是其中一種方法幫助設計師更好地闡述設計，以及通過思考細節讓自己的想法更精煉。

延續上一篇所聊到關於接案前要具備的心態，這篇我們來聊一聊關於大家更在意的事情，也就是接案時實際會遇到的問題：成本、報價、合約等等事項。

在許多數據的底下，真正重要的是它背後的資訊和意義。數據究竟跟你講了什麼？有時候，我們得到了許多數據，卻不知道如何應用。其實，得到數據只是一個開頭，後續的分析更為重要。