前言

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

【產品規劃系列(一)】軟體 PM 撰寫規格書的三大工具之一，User Story

【產品規劃系列(二)】軟體 PM 撰寫規格書的三大工具之二，Functional Map

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

 

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

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

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

Flow Chart (流程圖)

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

 

二、開始繪製 UI Flow

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

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

UI Flow

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

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

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

Wireframe (線框圖)

Wireframe的定義是：

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

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

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

• 簡單俐落
• 單一色系
• 單一字型
• 統一字級
• 不用插圖
• 簡單圖標
• 頁面註解
• 頁面編號
• 連結去向
• 過場特效 (Optional)
• 狀態變化 (Optional)
• 介面互動 (Optional)

Wire Flow

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

 

三、總結

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

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

 

 

原文出處：【產品規劃系列(三)】軟體 PM 撰寫規格書的三大工具之三，UI Flow

第一篇：【產品規劃系列(一)】軟體 PM 撰寫規格書的三大工具之一，User Story

第二篇：【產品規劃系列(二)】軟體 PM 撰寫規格書的三大工具之二，Functional Map