流程圖定義
流程圖是表示流經一個系統的信息流的圖形代表。
說白了就是表示先做什么后做什么，實際上就是“開始，結束，行動，狀態與判斷”的組合。
產品流程圖
產品流程圖包括業務流程、操作流程和頁面跳轉流程。
- 業務流程圖
作用：描述系統內各角色之間的業務關系和作業順序，包括使用產品各種角色中的操作，是描述整個系統的業務走向和業務流程，以業務處理過程為中心。
通常會由幾個「角色」來組成，他會有一種流水線般的工作線，A搞定了，傳給了B，B搞定他的部分，傳給了C，C搞定后又要將結果傳給A做。
操作流程圖
作用：描述用戶為完成某個任務而對產品的一個操作流程
比如成功下單，比如登陸注冊，比如退款等等。
頁面跳轉流程圖
作用：描述頁面之間的跳轉邏輯，主要面向表現層。
這里面會設計到一些邏輯上的問題，比如一個提示彈框出現后，如果點擊確定，下一步頁面去哪里？點擊取消呢？
例子
拿外賣點餐產品當例子：“我要訂餐”
業務流程圖
設計產品的時候常常從業務流程開始。
假象一下我們的產品是個第三方訂餐平臺，平臺上有很多餐館，用戶通過我們的平臺點餐付款，我們通知餐館做飯，送餐等等。我們首先要做的就是理清產品中有多少種角色，在腦子里想象下如果一個用戶下單，需要穿梭過多少種角色才能完成它的下單流程，然后將流程畫出。
畫業務流程通常會用到“泳道圖”這個是專門來表示多角色配合的一種流程。如下圖
角色有三，用戶，系統（后臺），廚房（第三方商家）。
跑一下這個短短的流程，如果「用戶」選好了今天的飯菜，提交訂單了，這時就將訂單信息推送給了「系統」，「系統」在后臺生成訂單，用戶的訂單狀態變為「等待付款」。（其實系統這部分用戶是看不到的，但是產品經理需要想清楚。）用戶會來到支付頁面，這時候做一個判斷，用戶是否為這個訂單支付了費用呢？如果是，那么「系統」就會受理這個訂單，將信息推送給第三方「廚房」，如果不是，那么用戶就是取消了訂單，訂單狀態變為「訂單失敗」。
流程中總是由一個動作展開，那么思考時，我們要對每一步都帶著一個“如果……不……”會怎么樣的心態，就會發現很多可以做判斷的地方。如果支付不成功呢？如果廚房不接單呢？如果退款不成功呢？這樣想下去你的流程細節就會越來越完善。
總結
業務流程著眼于整個系統的，注重主要環節。
你不只是一個用戶，因為用戶是不必知道后臺的一些判斷細節或是操作過程的，但如果你是產品經理的話是一定要清楚的。
業務流程設計流程
設定角色→跑通流程→用“如果……不……”窮盡判斷，思考產品背后的判斷邏輯。
對于操作流程圖和頁面跳轉流程圖設計，關鍵是要模擬用戶場景，則需要考慮三個場景
用戶在什么時候會使用這個功能；（如何開始）
用戶在使用這個功能的時候希望能提供給他們什么；（如何行進）
用戶在結束這個功能的時候希望是怎樣的。（如何結束）
即操作流程圖：功能層面（有什么功能，如何進行），頁面邏輯層面（前置條件、（入口）怎么開始、怎么結束）
操作流程（功能層面，有什么功能，如何進行）
第一步：定義這個功能的正常流程
功能的用戶操作流程，只設計最簡單，最正常的流程行進。
以下是是“用戶下單”的操作流程。
舉個栗子，假設設計一個手機號碼的注冊功能時，用戶的人機交互正常流程應該按照如下的方式行進。
這里可看到，用戶可操作4個子功能、分別是輸入手機號碼、點擊獲取驗證碼、輸入驗證碼、確定注冊。
這樣就有了一個基本流程，這個流程只能作為一條主線，并不能直接交付開發。
第二步：模擬用戶場景，檢驗流程是否滿足用戶需求：主要的原理是行進中的流程，應該將自己代入到用戶當中，去感受這個功能是否讓用戶感到舒適，或者為了用戶的體驗，應該增加哪些功能。
在這里，我將輸入驗證碼修改成自動讀取驗證碼并輸入，這個可以方便用戶不用來回切換程序來進行輸入。
第三步：極端的模擬（對功能考慮完善）
每一個環節去考慮分支及異常事項：通過代入極端數值去驗證流程是否具備對異常情況的應對方案。
對于無數值輸入的功能，則按照是/否的形式去思考。
示例1：（是非判斷）
第一個環節：打開頁面A提示進入到注冊功能（不需用戶進行任何數值輸入，我們用是、否的方式考慮）
考慮的問題：
是：什么場景下，打開頁面A會提示并進入注冊功能？
否：什么場景下，打開頁面A不會提示并進入注冊功能？
通過這個方法，引入用戶是否已登錄的判斷。
示例2：（當涉及到數值輸入我們需要引入極端數值）
在輸入手機號碼的環節涉及到數據的交互，這個時候我們可以采取是否判斷+極端數值的辦法去考慮異常流程。
是：如果用戶輸入的是手機號，怎么辦
否：如果用戶輸入的不是手機號，怎么辦
最大數值：在輸入無限多的手機號數時，怎么辦？
最小數值：在不輸入手機號碼或只輸入1個數字的時候，怎么辦？
通過這四個問題，就可以歸納出，應該對流程做出如下限制：
用戶應在此輸入框中，只能輸入數字
用戶應在此輸入框中，必須輸入11位的數字
而上文所說的第二步及第三步，是一個反復思考的步驟。
我所建議的是，當第三步修改完畢，返回第二步重新考慮，然后再一次進行第三步的修改。直至發現功能流程已達到改無可改的時候。
總結
相對于業務流程圖，操作流程圖更專注于某一個任務或目標，注重細節；
操作流程圖是以一個用戶的操作角度來寫，并不限于所謂的消費者用戶（后臺的操作流程也可以）；
在初畫操作流程的時候，不要早早的去過分在意細節與逆流程。（逆流程便是那些需要判斷是否的那個“否”的流程），第一次用最理想的狀態，將流程跑通，再去思考這里面會不會有那些“如果……不……”的細節。
頁面流程圖
主要討論的是入口問題：
模擬用戶場景，則需要考慮三個場景
用戶在什么時候會使用這個功能；（如何開始）
前置條件
用戶在結束這個功能的時候希望是怎樣的。（如何結束）
那還是按照剛才的功能流程，先考慮如何開始：
實際上，我們需要考慮的是，這個功能的入口是否合理（有些同學可能將功能設計得很好，但忘記了入口在哪里）
其次，我們再考慮如何結束：
在流程的完結，應該考慮功能最終體現給用戶是什么效果，這里以注冊來做例子，則是返回到進入前的頁面。
從圖中可以看出構成：
界面。
一個矩形代表一個界面，這個流程中用戶走過兩個界面（登錄頁和首頁），因為表達的是界面的跳轉，界面是用戶實實在在接觸到的媒介，非界面的內容，不要出現。
動作。
矩形之間也就是界面之間加上一個觸發動作，比如從界面A點擊下一步按鈕，到達界面B，“點擊下一步”就是連接這兩個界面的關鍵動作，需要標示出來，上圖例子就是“單擊提交按鈕”。
條件。
一個動作之后可能有多種“是/否”的結果，則在矩形之間、動作之后加上一個或多個判斷菱形。如上圖的檢驗賬號密碼是否輸入正確。
注意事項
堅持表達表現層。
不要一個流程圖里面，又有內部算法邏輯，又有界面邏輯，下圖標紅的矩形就是多余的，這個不關用戶的事情，會擾亂你的導航設計思路：
不要把步驟和界面本身都用矩形表示，比如下圖標紅的矩形：
拋棄系統錯誤。
什么是系統錯誤呢，也就是非用戶犯的錯誤，比如登錄的時候服務器當了，網絡連接錯誤等導致登錄失敗。除非你特別想強調系統錯誤后的提示界面，否則建議不要加進去流程圖里面，因為每一步操作都可能錯誤，你的流程圖會因此變得很龐大。如下圖：
形式可以很靈活。
a 如果一個界面可以通往多個界面，而你又真要描述出這些跳轉，那就一個矩形長出多條線路，對應標示上對應的動作就ok了。如圖：
b. 如果你想把一些警告窗口等臨時窗口表達出來，也可以自定義一些圖形，比如：
總結
業務流程與操作流程都在他之上完成，當建立起來操作流程，頁面跳轉的流程也就躍然紙上了。只是在做某些交互行為時要多加注意頁面之間的邏輯、層級關系，做到跳轉不歧義。
