流程圖定義

流程圖是表示流經一個系統(tǒng)的信息流的圖形代表。

說白了就是表示先做什么后做什么，實際上就是“開始，結束，行動，狀態(tài)與判斷”的組合。

產品流程圖

產品流程圖包括業(yè)務流程、操作流程和頁面跳轉流程。

業(yè)務流程圖

作用：描述系統(tǒng)內各角色之間的業(yè)務關系和作業(yè)順序，包括使用產品各種角色中的操作，是描述整個系統(tǒng)的業(yè)務走向和業(yè)務流程，以業(yè)務處理過程為中心。

通常會由幾個「角色」來組成，他會有一種流水線般的工作線，A搞定了，傳給了B，B搞定他的部分，傳給了C，C搞定后又要將結果傳給A做。

操作流程圖

作用：描述用戶為完成某個任務而對產品的一個操作流程

比如成功下單，比如登陸注冊，比如退款等等。

頁面跳轉流程圖

作用：描述頁面之間的跳轉邏輯，主要面向表現(xiàn)層。

這里面會設計到一些邏輯上的問題，比如一個提示彈框出現(xiàn)后，如果點擊確定，下一步頁面去哪里？點擊取消呢？

例子

拿外賣點餐產品當例子：“我要訂餐”

業(yè)務流程圖

設計產品的時候常常從業(yè)務流程開始。

假象一下我們的產品是個第三方訂餐平臺，平臺上有很多餐館，用戶通過我們的平臺點餐付款，我們通知餐館做飯，送餐等等。我們首先要做的就是理清產品中有多少種角色，在腦子里想象下如果一個用戶下單，需要穿梭過多少種角色才能完成它的下單流程，然后將流程畫出。

畫業(yè)務流程通常會用到“泳道圖”這個是專門來表示多角色配合的一種流程。如下圖

角色有三，用戶，系統(tǒng)（后臺），廚房（第三方商家）。

跑一下這個短短的流程，如果「用戶」選好了今天的飯菜，提交訂單了，這時就將訂單信息推送給了「系統(tǒng)」，「系統(tǒng)」在后臺生成訂單，用戶的訂單狀態(tài)變?yōu)椤傅却犊睢埂＃ㄆ鋵嵪到y(tǒng)這部分用戶是看不到的，但是產品經理需要想清楚。）用戶會來到支付頁面，這時候做一個判斷，用戶是否為這個訂單支付了費用呢？如果是，那么「系統(tǒng)」就會受理這個訂單，將信息推送給第三方「廚房」，如果不是，那么用戶就是取消了訂單，訂單狀態(tài)變?yōu)椤赣唵问　埂?/p>

流程中總是由一個動作展開，那么思考時，我們要對每一步都帶著一個“如果……不……”會怎么樣的心態(tài)，就會發(fā)現(xiàn)很多可以做判斷的地方。如果支付不成功呢？如果廚房不接單呢？如果退款不成功呢？這樣想下去你的流程細節(jié)就會越來越完善。

總結

業(yè)務流程著眼于整個系統(tǒng)的，注重主要環(huán)節(jié)。

你不只是一個用戶，因為用戶是不必知道后臺的一些判斷細節(jié)或是操作過程的，但如果你是產品經理的話是一定要清楚的。

業(yè)務流程設計流程

設定角色→跑通流程→用“如果……不……”窮盡判斷，思考產品背后的判斷邏輯。

對于操作流程圖和頁面跳轉流程圖設計，關鍵是要模擬用戶場景，則需要考慮三個場景

• 用戶在什么時候會使用這個功能；（如何開始）
• 用戶在使用這個功能的時候希望能提供給他們什么；（如何行進）
• 用戶在結束這個功能的時候希望是怎樣的。（如何結束）

即操作流程圖：功能層面（有什么功能，如何進行），頁面邏輯層面（前置條件、（入口）怎么開始、怎么結束）

操作流程（功能層面，有什么功能，如何進行）

第一步：定義這個功能的正常流程

功能的用戶操作流程，只設計最簡單，最正常的流程行進。

以下是是“用戶下單”的操作流程。

舉個栗子，假設設計一個手機號碼的注冊功能時，用戶的人機交互正常流程應該按照如下的方式行進。

這里可看到，用戶可操作4個子功能、分別是輸入手機號碼、點擊獲取驗證碼、輸入驗證碼、確定注冊。

這樣就有了一個基本流程，這個流程只能作為一條主線，并不能直接交付開發(fā)。

第二步：模擬用戶場景

檢驗流程是否滿足用戶需求：主要的原理是行進中的流程，應該將自己代入到用戶當中，去感受這個功能是否讓用戶感到舒適，或者為了用戶的體驗，應該增加哪些功能。

在這里，我將輸入驗證碼修改成自動讀取驗證碼并輸入，這個可以方便用戶不用來回切換程序來進行輸入。

第三步：極端的模擬（對功能考慮完善）

每一個環(huán)節(jié)去考慮分支及異常事項：通過代入極端數(shù)值去驗證流程是否具備對異常情況的應對方案。

對于無數(shù)值輸入的功能，則按照是/否的形式去思考。

示例1：（是非判斷）

第一個環(huán)節(jié)：打開頁面A提示進入到注冊功能（不需用戶進行任何數(shù)值輸入，我們用是、否的方式考慮）

考慮的問題：

是：什么場景下，打開頁面A會提示并進入注冊功能？

否：什么場景下，打開頁面A不會提示并進入注冊功能？

通過這個方法，引入用戶是否已登錄的判斷。

示例2：（當涉及到數(shù)值輸入我們需要引入極端數(shù)值）

在輸入手機號碼的環(huán)節(jié)涉及到數(shù)據(jù)的交互，這個時候我們可以采取是否判斷+極端數(shù)值的辦法去考慮異常流程。

是：如果用戶輸入的是手機號，怎么辦

否：如果用戶輸入的不是手機號，怎么辦

最大數(shù)值：在輸入無限多的手機號數(shù)時，怎么辦？

最小數(shù)值：在不輸入手機號碼或只輸入1個數(shù)字的時候，怎么辦？

通過這四個問題，就可以歸納出，應該對流程做出如下限制：

用戶應在此輸入框中，只能輸入數(shù)字

用戶應在此輸入框中，必須輸入11位的數(shù)字

而上文所說的第二步及第三步，是一個反復思考的步驟。

我所建議的是，當?shù)谌叫薷耐戤?，返回第二步重新考慮，然后再一次進行第三步的修改。直至發(fā)現(xiàn)功能流程已達到改無可改的時候。

總結

相對于業(yè)務流程圖，操作流程圖更專注于某一個任務或目標，注重細節(jié)；

操作流程圖是以一個用戶的操作角度來寫，并不限于所謂的消費者用戶（后臺的操作流程也可以）；

在初畫操作流程的時候，不要早早的去過分在意細節(jié)與逆流程。（逆流程便是那些需要判斷是否的那個“否”的流程），第一次用最理想的狀態(tài)，將流程跑通，再去思考這里面會不會有那些“如果……不……”的細節(jié)。

頁面流程圖

主要討論的是入口問題：

模擬用戶場景，則需要考慮三個場景

用戶在什么時候會使用這個功能；（如何開始）

前置條件

用戶在結束這個功能的時候希望是怎樣的。（如何結束）

那還是按照剛才的功能流程，先考慮如何開始：

實際上，我們需要考慮的是，這個功能的入口是否合理（有些同學可能將功能設計得很好，但忘記了入口在哪里）

其次，我們再考慮如何結束：

在流程的完結，應該考慮功能最終體現(xiàn)給用戶是什么效果，這里以注冊來做例子，則是返回到進入前的頁面。

看下圖：

從圖中可以看出構成：

1.界面。

一個矩形代表一個界面，這個流程中用戶走過兩個界面（登錄頁和首頁），因為表達的是界面的跳轉，界面是用戶實實在在接觸到的媒介，非界面的內容，不要出現(xiàn)。

2.動作。

矩形之間也就是界面之間加上一個觸發(fā)動作，比如從界面A點擊下一步按鈕，到達界面B，“點擊下一步”就是連接這兩個界面的關鍵動作，需要標示出來，上圖例子就是“單擊提交按鈕”。

3.條件。

一個動作之后可能有多種“是/否”的結果，則在矩形之間、動作之后加上一個或多個判斷菱形。如上圖的檢驗賬號密碼是否輸入正確。

注意事項

1.堅持表達表現(xiàn)層。

不要一個流程圖里面，又有內部算法邏輯，又有界面邏輯，下圖標紅的矩形就是多余的，這個不關用戶的事情，會擾亂你的導航設計思路：

2.不要把步驟和界面本身都用矩形表示

比如下圖標紅的矩形：

3.拋棄系統(tǒng)錯誤。

什么是系統(tǒng)錯誤呢，也就是非用戶犯的錯誤，比如登錄的時候服務器當了，網(wǎng)絡連接錯誤等導致登錄失敗。除非你特別想強調系統(tǒng)錯誤后的提示界面，否則建議不要加進去流程圖里面，因為每一步操作都可能錯誤，你的流程圖會因此變得很龐大。如下圖：

4.形式可以很靈活。

a 如果一個界面可以通往多個界面，而你又真要描述出這些跳轉，那就一個矩形長出多條線路，對應標示上對應的動作就ok了。如圖：

b. 如果你想把一些警告窗口等臨時窗口表達出來，也可以自定義一些圖形，比如：

總結

業(yè)務流程與操作流程都在他之上完成，當建立起來操作流程，頁面跳轉的流程也就躍然紙上了。只是在做某些交互行為時要多加注意頁面之間的邏輯、層級關系，做到跳轉不歧義。

本文由 @Carson_ho原創(chuàng)發(fā)布于人人都是產品經理?，未經許可，禁止轉載。