一份高效的流程，可以清晰地傳達產品在某個層面上的信息。該篇文章簡單介紹了產品的流程，并用實例來演示產品流程的從無到有。

上篇，針對簡單系統和復雜系統，筆者介紹了兩種不同的需求設計方法（傳送門：后臺產品設計系列：產品設計方式（二）），此篇，將在需求及產品架構確定的基礎上，介紹產品的流程設計。

流程設計，是決定產品是否可用、易用的重要因素，同時也是一個產品經理邏輯分析能力強弱的重要體現。好的流程設計，不僅讓產品功能形成閉環，也讓用戶感受到產品的簡單高效，帶來良好用戶體驗。以下將以外賣訂餐為例，詳細圖解流程設計。

一、流程介紹

1.1 定義

流程：特定主體為了滿足特定需求而進行的有順序的一系列操作過程。

例如：外賣訂餐流程，特定主體是用戶、特定需求是訂外賣。

1.2 分類

從功用角度，流程分為業務流程、功能流程、操作流程、頁面流程、數據流程五類；

從主次角度，流程可以分為核心流程、次要流程、異常流程、子流程。

這兩種劃分角度各自獨立，又相互融合，進行流程設計時都需要考慮。

業務流程：根據產品解決用戶核心問題的順序所梳理的完整的閉環流程，包括線上和線下兩部分。例如，下圖是解決用戶訂餐問題的整體流程：

梳理完整的業務流程是建立全面產品認識的必要條件，很多產品經理始終把自己定位為一個狹義的互聯網產品經理，對線下環節不夠重視。在梳理業務流程時，沒有把線下流程考慮的足夠清晰，一筆帶過，導致很多時候線上體驗做好了，線下體驗砸了口碑。

功能流程：功能流程也可看做任務流程，是產品實現某一功能的流程，或者是用戶完成某一任務的流程。如下單流程：

頁面流程：在功能流程基礎上，用戶完成某一任務所需經過的頁面，就組成了頁面流程。

操作流程：在頁面流程基礎上，用戶完成某一任務所需進行的操作順序，就是操作流程。

數據流程：用來說明業務處理過程中，信息流和數據從輸入移動到輸出的過程中所經受的變換，更多體現在數據庫層次和前后端的數據交互，一般不需要產品來做梳理。

對于另一維度的劃分，從字面意思即可理解，就不再說明。

1.3 表現形式

基礎流程圖：以圖形形式，顯示流程中前后活動（動作）順序；

跨職能流程圖：又稱泳道圖，顯示進程中各步驟之間的關系以及執行它們的職能單位、系統或功能模塊。其實就是在基礎流程圖上，將角色獨立成為一個個泳道，便于更直觀的查看流程中各環節與角色的關系和流轉情況；

1.4 六要素

1. 參與者：上篇說到，后臺產品所有的需求都是有一個明確角色的，流程中的操作也是如此。參與者就是誰在這個流程中做的操作？可以是系統，可以是某個設備，更多的指一個角色。比如用戶、商家、外賣小哥；
2. 活動（動作）：一個處理動作，具體做了什么事。比如下單、接單；
3. 次序：這些事情發生的前后順序如何，哪個任務是其他任務的前置條件。比如用戶不提交訂單，就無法生成訂單；
4. 輸入：每項活動開始取決于什么樣的輸入物或數據，比如做飯的師傅開始做菜時，需要拿到具體的點菜單。；
5. 輸出：每項活動結束后，會輸入什么樣的文檔或數據傳遞給下一方，比如師傅做好菜后，如何讓負責傳菜的人知道菜已經做好；
6. 標準化：采用一套標準化的符號表達并傳遞你的流程。

在繪制流程圖時，表示每個環節都應該能夠清楚的說明“誰在哪個階段做了什么（who、where、what）”。

1.5 流程圖基本結構

順序結構：順序結構是簡單的線性結構，各框按箭頭順序執行。

分支（選擇）結構：這種結構是對某個給定條件進行判斷，條件為真或假時分別執行不同的節點內容。

循環結構：當流程中需要反復執行某個動作時，就需要設置循環結構。它由循環體中的條件，判斷繼續執行某個動作還是退出循環。

二、流程設計

認識了流程及流程圖，下面將用實例來分步介紹流程設計。

2.1 調研現有流程

對于很多產品，用戶痛點是明確的，很早之前就有了各種解決方案。只不過互聯網的興起，提供了一種更快速、更便捷高效的方式。O2O產品就是這樣一類借助互聯網特性，解決用戶已有痛點的產品。

肚子餓了要吃飯，又懶得不想出去，這就是外賣APP所解決的痛點，當我們從最初開始設計外賣產品流程時，就應該從已有的、成熟的、經過市場檢驗的解決方案入手，進行調研。

當外賣APP沒有興起時，要想能吃到飯又不用出門，人們最有效的方式就是打call。經過調研，電話訂餐的流程如下圖：

2.2 分析環節痛點，線下流程線上化

線下流程梳理完成，會發現每個環節都存在或大或小的痛點有待解決。這個時候，就應該考慮如何利用互聯網打破信息壁壘、便捷快速的特點和技術手段來解決這些痛點，進而在線上解決方案的基礎上，設計一條全新的業務流程。例如，初步分析即可發現現有訂餐流程存在諸多問題：

結合現有流程和線上解決方案，我們就可設計一個新的業務流程，得到下面這個基本流程圖：

2.3 劃分階段和角色并拆分子流程

從上面這個基本流程圖可以看到，雖然每個環節都展現出來了，但有以下幾點問題：

1. 為了說明“誰在哪個階段做了什么”，導致每個環節描述過長；
2. 角色冗雜，無法清晰查看每個角色需要完成的工作，導致后面做用戶權限設計時容易出現混亂；
3. 部分環節深入后發現有更為詳細的流程，而這些更為詳細的流程難以體現。

所以為了讓流程圖更清晰的指導后續產品設計，需將基本流程圖按角色拆分，輸出泳道圖：

在主業務泳道圖中，我們將用戶下單流程、騎手搶單流程作為子流程進行梳理，在Visio中新增幾個sheet頁，單獨繪制子流程的泳道圖，這樣做的好處有以下幾點：

1. 避免了主業務過長，導致可讀性很差；
2. 重要的分支流程單獨梳理，方便多個產品經理協作、維護；
3. 結合上篇所說的微服務思想（劃分系統），這些子流程就可以作為某個獨立系統的主流程，指導這個獨立系統的產品設計。

以上三步完成的就是業務流程的梳理。當我們完成足夠細致的業務流程梳理時，就會發現：產品的主要功能流程都包含在了這些業務子流程中，然后再根據這些功能流程，設計出相應的頁面及操作流程即可。

#專欄作家#

Z. Fly，人人都是產品經理專欄作家。關注B端產品；擅長需求分析及對內對外溝通。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議