梗概
對於任何產品設計來說，構建流程都是一個繞不開的環節。其奠定了後續的產品框架，是使用者體驗的基石。本文將從定義和分類出發，結合實際案例，深入淺出地闡述流程圖的作用以及畫法。
定義
流程——顧名思義：水流的路程；事物進行中的次序或順序的佈置和安排。流程是自然而然就存在的，它可以不規範，可以不固定，可以充滿問題。
由兩個及以上的步驟，完成一個完整的行為的過程，可稱之為流程；注意是兩個及以上的步驟。
流程圖的核心就在於如何排布事物進行的次序，不同的順序可能造成截然不同的結果。
目的
產品經理畫流程圖的目的不外乎幾點：
流程圖為產品設計基石，可以保證產品的使用邏輯合理順暢
傳達需求，用流程圖來更好地表達產品邏輯
查漏補缺，檢驗是否有遺漏的分支流程
分類
流程圖以描述物件分類，包括：業務流程圖、頁面流程圖、功能流程圖、資料流程圖等。
業務流程圖（Transaction Flow Diagram, TFD）
先以宋丹丹小品中的一個腦筋急轉彎為例：把大象裝冰箱，總共分幾步？
三步：
第一步，把冰箱門開啟；
第二步，把大象裝進去；
第三步，把冰箱門關上。
這看似是一個笑話，但其實蘊含著很強的邏輯思維。首先這裡忽略了很多現實中的限制條件。比如，以大多數冰箱的容積都不可能將大象塞進去；比如是否能把大象切成塊放進去？如果把大象塞進去，它會不會又跑出來？但拋開這些限制條件，那把大象塞冰箱的極簡流程就是三步。開啟冰箱門，把大象裝進去，最後把門關上。
我們做業務流程圖，其實很多時候都需要具有把“大象塞進冰箱”的思維方式，拋開很多現有的認知侷限，將具象的行為一個個抽象出來。
結合上面的例子，再來細細品味“業務流程圖”的定義：
抽象地描述事物進行的次序和順序，不涉及具體操作與執行細節。在網際網路軟體行業通常指脫離產品設計的使用者行為流程。業務流程圖是一種系統分析人員都懂的共同語言, 用來描述系統組織結構、業務流程。
不管是否理解上述定義，下面帶著抽象思維去思考購物行為的業務流程圖應該是什麼樣的？
以上的三步組成了一個最簡的一個流程，其完全涵蓋了任何購物行為的核心。無論是網購還是在實體超市，都是以這三個行為為主體，然後進行擴充套件的。相對於大家平時看到的複雜的網購流程圖，以上的三步流程簡直簡單的令人髮指，而這恰恰是印證了大道至簡的原理。我始終堅信無論再複雜的事情都能簡化為極其簡單的事情，如果你無法將其簡化，說明只是你沒有理解其核心。
依據上面的最小流程單元，我們下面嘗試能不能將其擴充套件，嘗試套用在更細節的流程圖上面。
頁面流程圖（Page Flow Diagram）
定義：指電子產品具體所呈現的頁面跳轉流程圖。其承載了業務流程圖所包含的業務流轉資訊。
下圖以淘寶為例，展示出了網購的頁面流程。
由上圖紅框中的三個節點我們可以看出，頁面流程圖依然是包含在業務流程圖的。這恰恰符合定義中的要求，同時也印證了頁面流程圖的正確性。相較於一開始的極簡流程圖，現在的流程圖已經漸漸變得複雜了一些。我們將抽象的業務，對映在了具象的頁面上，用軟體的頁面承載起了業務需求。而以上就是由業務流程圖到頁面流程圖的轉化過程。
功能流程圖（Function Flow Diagram）
定義：指單頁面內或多頁面之間的功能操作流程，其包含在頁面流程中。
任何功能都是被包含在頁面內的，但一個頁面內往往不止一個功能，所以單單頁面流程圖可能無法完整表達所有流程，而這時就需要用功能流程圖來更加具體表達每個頁面內所包含的功能。
由上圖紅框中的四個節點我們可以看出，功能流程圖同樣也是由頁面流程圖擴充而來的。功能流程圖是在頁面流程圖的基礎上繼續深化，變得更加複雜。同時也漸漸變得像大家日常看到的流程圖一樣。
產品/運營/測試/程式設計師必備乾貨【資源下載】
資料流程圖（Data Flow Diagram）
定義：特指軟體產品中，描述資料在不同節點被處理的過程所畫的圖表。主要表達計算機程式對於業務的實現原理。使用者在功能流程圖中的每一個操作，對應都會反映在資料流程圖中。同時，資料流程圖也可以叫程式流程圖（Program Flow Diagram）。
它是一種能全面地描述資訊系統邏輯模型的主要工具。它可以利用少數幾種符號綜合的反映出資訊在系統中的流動、處理和儲存的情況。資料流程圖具有抽象性和概括性。
可能業務流程圖、頁面流程圖和功能流程圖大家都耳熟能詳，但資料流程圖恐怕瞭解的就比較少了。其實，每個流程圖中都有一個核心伴隨著不同操作在整個系統中不斷流轉。比如業務流程圖大多以人為核心，每個節點都是在傳遞人的不同行為。而頁面流程圖和功能流程圖也類似，都是以人的操作行為為核心，在不同頁面和功能間進行流轉。但資料流程圖不同，它是以資料為核心，展示整個系統中，資料是如何被處理的。
其更偏技術思維，更多的是展現後臺程式的實現原理。所以，常常是開發人員繪製此圖，而產品經理涉及較少。但隨著產品經理地不斷成長，向上提高到戰略層，而向下則會深入到實現層。理解程式的開發原理和背後的資料流轉，無疑會讓產品經理對產品設計有更加深刻的理解。
下面仍以購物流程為主題來展示資料流程圖。
相較於之前的圖表，資料流程圖增加了新的維度——程式。客戶端在展現使用者操作行為的同時，也表達了程式在使用者行為背後的動作。而往往大家說一個產品複雜的時候，可能只注意到了它的前端互動複雜，而忽視了後端邏輯的複雜。對於一個優秀的產品經理來說，不止要關注前端的使用者體驗，更要能看清事物背後的邏輯。畢竟人人都可以對使用者體驗指手畫腳，而說到程式實現，那可就體現出產品經理的專業性來了。
小結
以上幾幅圖片分別展示了一個產品的業務流程、頁面流程、功能流程和資料流程。從中可以發現，由業務到頁面，再到功能，再到資料處理，是順序擴充的。一個產品的頁面或功能，不是憑空出現的，而是依據業務層的各個節點和流程進行設計的。這就是為什麼在做產品設計時一定要先理解業務的原因。
在初步學習畫流程圖時，儘量將業務、頁面、功能和資料區分清楚，並且逐層遞進，不要把多種型別的流程圖混雜一起。這樣反而會將思想搞得混亂。
流程圖的顆粒度
所謂流程圖的顆粒度，其實就是指流程圖的細緻程度。
我在畫流程圖時也常常會猶豫糾結，這個功能點用不用描寫得更詳細？這條分支用不用標出來？這個和伺服器的互動事件用不用在流程圖體現？等等這些問題，也都是產品經理在日常畫圖時會遇到的。
依然拿購物流程為例，最簡的業務流程分為三個步驟，那如果細化一些，是否可以畫出不同的流程圖呢？
顯而易見，即便針對同一個流程，也能畫出不同的流程圖。如上圖，將挑選商品拆分為三個步驟，將結賬拆分為兩個步驟。但兩個流程圖依然表達的是一套流程。而這就是每個人對於顆粒度的把握有所不同。有很多新人總想一步到位，一次畫出完美的流程圖。但這其實是一種非常不可取的思維。任何完善的流程圖，都需要經過由簡單到複雜的過程，而不是一蹴而就。
理論上來說，流程圖的細緻程度越高，產品設計就越準確順暢。但實際情況中，過度的詳細反而是浪費時間。而對於度的把握能力，則需要經驗積累以及團隊磨合，這裡也是體現產品經理對顆粒度把握能力的地方。我們畫流程圖的最終目的是讓團隊成員理解我們的產品設計，而不是需要畫一幅非常詳細的流程圖。理想的情況應該是以最簡的形式，畫出團隊都能理解的圖表。
流程圖畫法
上面講解了流程圖的定義和分類，下面就進入具體的流程畫法講解
流程圖基本元素
以上為流程圖中最常用的幾種元素。不常用的元素就不在此展示了，大家可以在Microsoft Visio中檢視。
泳道圖
泳道圖是流程圖中的一種畫法，是將流程圖中的一些流程節點按操作角色的不同而劃分。比如剛才的資料流程圖其實就採用泳道圖的畫法展示，其中頂部為兩個不同角色——使用者和伺服器。同時在豎向的基礎上也可以新增橫向泳道，以不同頁面來給操作分類。
對於涉及到多角色比較複雜的流程圖來說，畫泳道流程圖會看起來更加清晰明瞭。
產品/運營/測試/程式設計師必備乾貨【資源下載】
流程圖的組成部分
流程圖主要由三部分組成：
主幹流程
分支流程（異常流程屬於分支流程）
子流程
下圖是將之前功能流程圖的例子作為主幹流程，然後新增了分支流程。我們在畫流程圖時應該遵循先主幹後分支的順序來描繪流程圖，因為對於大多數使用者來說，主幹流程是最常用的路徑。
主幹流程和分支流程大家都好理解，那到底什麼是子流程呢？在畫流程圖的過程中，有一些流程是會經常遇到的，比如登入流程、註冊流程、修改密碼流程。對於電商來說，可能有退貨流程、購物券使用流程等等。如果每次畫與之有關的流程圖的時候，都將其再畫一遍，那實在繁瑣。所以，子流程就是將某幾個具有邏輯關係的節點集合而成的，可以複用在各個地方。
下圖就是將登入流程變成子流程後的流程圖。
流程圖的結構
流程圖中大致包含四種結構：順序結構、條件結構（又稱選擇結構）、迴圈結構。基本上大多數流程圖都是由這三種結構組成的。
案例
上面說了那麼多理論知識和概念，那下面就開始真刀實槍地展示一個案例。本來一開始我想以電商產品作為例子，因為電商產品是需要極強邏輯思維的產品，並且比較常見。但後來發現淘寶、京東等都極為龐大和複雜，分析起來過於笨重。轉而想起共享單車是個非常不錯的教材案例。其產品極簡，但背後卻暗藏有趣的邏輯架構。尤其是市面上摩拜與ofo不同的產品解決方案，分析起來更加有對比性。
共享單車的前身
如果要追溯最早的共享單車，恐怕就是政府推出的有樁自行車。其推出目的無非就是緩解交通壓力，以及減少環境汙染。而當時受限於成本、技術以及大眾人群的普遍素質，有樁自行車的解決方案是極其不方便的。想要租一輛有樁自行車，首先要憑身份證在相關單位辦理IC卡，並繳納押金和預存費用，然後租車和還車只能在定點位置進行。先不談辦理卡片有多麻煩，租車還車有多不方便，超時扣費有多驚人，如果只單純將其用業務流程圖展示出來，應該是什麼樣的呢？
下面依然以最簡單的業務形態來展示使用有樁單車業務流程圖：
單看有樁單車的流程圖其實沒有任何意義，真正的意義在於有樁單車和目前摩拜與ofo的橫向對比，下面看一下兩家共享單車的業務流程圖：
很明顯可以看出，無論是有樁單車、摩拜單車還是ofo單車，在業務流程圖上竟然沒有太大區別。那為什麼多年之前政府主導的有樁單車平平無奇，而2016年末出現的共享單車紅極一時？那摩拜和ofo兩款截然不同的單車，區別點到底在哪裡呢？我們需要更加深入地分析每個業務節點，剖析其功能。
因為單車的使用流程不僅是在APP上，還有一部分操作在實體自行車上，這時就不能單使用頁面流程圖，而是要直接使用功能流程圖。並且這裡的功能流程圖不侷限於頁面內的功能，而是要表達使用者對單車和APP的每一步操作。
首先看ofo單車，在APP中支付押金後，接著便需要尋找自行車。而這時我們發現，雖然ofo有多種單車樣式，多種車鎖機制。但本案例著重講ofo第一代機械鎖，與第二代偽智慧鎖。
這兩種鎖其實代表了兩種不同的產品解決方案，我們先討論第一種機械鎖。（所謂機械鎖，其實類似於生活中經常見到的密碼箱。每個密碼箱有預設的固定密碼，通過撥弄錶盤輸入正確密碼，即可開鎖。並且機械鎖的密碼是固定的，不會改變）。
我們從路邊找到機械鎖單車，然後開啟APP，輸入車牌號或掃描二維碼，從APP中得到本車的機械鎖密碼，然後輸入密碼，開啟單車車鎖。此時APP中會進行倒數計時，倒數計時結束則開始正式計費。最後，騎行到目的地後，需要將車鎖關閉，並且必須在APP中點選結束騎行的按鈕，才能結算此次行程的訂單。
看完了ofo的流程，下面來對比看一下摩拜的流程。
摩拜的產品解決方案為，掃描單車的二維碼以後，摩拜單車的車鎖會自動開啟，不需要像機械鎖一樣手動操作。並且在鎖車後，摩拜單車自動會結束行程，無須在APP中點選結束。在下一次APP開啟時，才會進行賬單結算。
下圖分別為ofo機械鎖單車使用流程圖和摩拜單車使用流程圖（APP標識代表使用者在APP上的操作）
我們可以清楚地看到摩拜的流程比ofo的少了兩個節點，而這就是摩拜對比ofo第一代機械鎖的優勢。當然，ofo第一代也有其他方面是優於摩拜的，比如騎車的舒適程度。但本文主要聚焦於產品流程，所以並不在單車體驗上花費太多筆墨。
縱觀ofo機械鎖和摩拜智慧鎖的解決方案來看，ofo明顯是遜色很多的。機械鎖帶來的問題，不止是使用流程的複雜，還有很多是產品使用上的漏洞。比如，使用者鎖車後，必須手動將密碼撥亂，不然下個人將可以免費騎行。比如，使用者在騎行結束後，忘記在APP點選結束，會造成更額外扣費。等等還有很多問題，就不一一列舉了。
說句題外話，這些問題ofo也都明白。機械鎖的解決方案倘若只在封閉的校園內執行，那還差強人意。但一經投放到校外市場，那麼這種解決方案無疑會給公司帶來巨大的損失。那為什麼ofo明知問題，還要大量投放呢？原因很簡單，以摩拜擴充的速度，如果他不在當時迅速走出校園，那麼也許永遠也沒機會走出校園了。
言歸正傳。之前的討論，一直避開了一個非常重要的節點——“找車”。拋開路邊隨機看到單車不談，就拿地圖找車來說，ofo第一代機械鎖肯定是沒有GPS定位的，為什麼也能在地圖上顯示呢？
下面我們嘗試畫一下ofo對於解鎖的程式流程圖是什麼樣的。
我們從“APP掃描二維碼/輸入單車編號”此節點開始推導。我要開車牌號為XXX的單車，那麼就需要得到密碼，而所有車的密碼，都應該放在ofo的單車資料庫中。我們不論是掃描二維碼，還是輸入單車號，本質都應該是將單車編號傳輸給伺服器，告訴它我要哪輛車的密碼。伺服器查詢到此單車的密碼以後，就傳輸回APP，我們就看到了此單車的密碼。
因為節省車鎖電源的原因，伺服器此時並沒有和單車聯絡，而是靠人工輸入密碼開啟車鎖。所以ofo在使用者得到密碼後，就會開始倒數計時。倒數計時內可以取消開鎖狀態；倒數計時結束，則代表使用者預設開始騎行，計費也從此時開始。
此時如果是iPhone使用者的話，將ofoAPP最小化時，就會發現手機頂部電池電量條變成了藍色。其實，這就是ofo獲取單車行程的要點所在。既然機械鎖無法向伺服器傳輸資料的話，那不如讓使用者手機代替。以獲取手機的定位來獲取單車的騎行路線。並且在停車後，點選結束騎行時，上報位置，由此伺服器來標記此單車停放的位置。而此時上報的位置其實並沒有單車。這就是ofo地圖上有很多假標記產生的原因。
ofo採用的這種標記方法其實非常的粗糙，畢竟如果使用者強制結束應用，也就獲取不到騎行路線了。而ofo針對獲取不到騎行路線的情況，也做了處理，那就是用標記起點到終點，然後根據地圖提供的路線來顯示路程。
上圖我親測的案例。紅色箭頭是我的實際騎行的路線，綠色線是ofo自帶地圖上通過起點和終點計算的路線。
下面我們繼續分析ofo機械鎖的程式流程圖
注意上圖服務內的部分，看起來步驟非常少，也非常簡單，而真實的伺服器肯定有更多複雜的邏輯判斷。但對於產品經理畫的流程圖來說，不可能完完全全描繪程式設計中的技術細節，而且也不需要產品經理去幫技術想程式碼的實現邏輯。我們要做得是，理解程式巨集觀的實現邏輯。
比如，在掃描二維碼後，為什麼APP會顯示這輛車的密碼，而不是其他車輛的密碼呢？很簡單，伺服器內肯定儲存了所有單車的密碼，而掃描二維碼的過程就是將此單車的ID傳送給伺服器，伺服器在資料庫中找到密碼後，返回給使用者手中。
伺服器在此處理過程中，肯定還會有其他的判斷，比如此使用者賬號是否正常，有沒有被封號？此單車是否已被標記為故障車？等等。但大家發現，上面的流程圖內並沒有畫出這些邏輯判斷，是我忘記了嗎？
其實並不是。這裡又不得不提到本文的核心概念——顆粒度。
此圖想表達的是巨集觀的程式實現邏輯，是為了讓讀者更聚焦於問題核心，我們只需要著重表達主幹流程就好。如果新增更多的分支流程、異常流程，那反而會影響讀者的注意力。所以，還是老生常談的那句話：畫流程圖一定要先主幹，後分支，千萬別在一開始就盲目追求細節。
言歸正傳，ofo的第一代鎖的解決方案雖然漏洞百出，但依然用其巧妙的方式，實現了地圖上單車位置的顯示。ofo推出的第二代鎖，改進了以往機械鎖的很多問題。其中最大的效果就是車鎖的密碼不再是固定的，並且鎖車之後，不需要再點結束行程。那既然ofo的鎖已經優化了，那為什麼前文還稱他為偽智慧鎖，他和真正的智慧鎖差在哪裡呢？為什麼ofo的車鎖依然需要手動輸入密碼，而不是像摩拜一樣，車鎖直接彈開？為什麼常常在地圖上看到有車，而實際地點沒有車呢？
下面引入一個80、90後童年的回憶：將軍令。
“將軍令”（又名網易帳號保護器） 是廣州網易互動娛樂有限公司自主研發的、具有完全智慧財產權的高科技身份認證產品。它是專為保護網易通行證賬號（遊戲賬號）、直銷商帳號的密碼而出的產品，其特有的60秒密碼動態自動更新技術將盜號風險降到最低。
“將軍令”的產生伴隨著當年夢幻西遊的風靡，其創新技術確實解決了大多數盜號問題。那將軍令的實現機制到底是如何呢？簡單地說明一下：首先，開啟“將軍令”，它會生成一串數字，你在登陸游戲時，輸入這些數字，系統就會允許賬號登陸。同時，“將軍令”的數字是每隔60秒動態變化的，每次登陸時，“將軍令”的驗證碼都會不一樣。其實現原理，無非是“將軍令”和伺服器保持同一種演算法，在同一時間，他們的計算結果是一致的。
回來看ofo的偽智慧鎖，其實也是一樣的實現原理。每輛車鎖都有一個單獨的演算法儲存在伺服器，車鎖每隔一段時間就會根據演算法，變換一個密碼。而當你開啟APP，檢視此單車密碼時，伺服器使用和車鎖相同的演算法算一遍當前時間下的密碼，那此密碼一定是和車鎖當前算的是一致的。
開鎖說完了，下面聊聊關鎖。如果你騎過小黃車就會發現，小黃車的智慧鎖關閉以後，並不用手動點APP上的結束行程了。那要做到這點，一定是車鎖與伺服器進行了通訊，告訴伺服器使用者已經結束了行程，可以結算訂單了。那既然車鎖可以和伺服器通訊，為什麼ofo還要採用上面的將軍令方式來解鎖呢，為什麼不直接用伺服器通訊告訴單車自動開鎖呢？
其實，就ofo第一代偽智慧鎖“海王星"來說，並沒有做到實時和伺服器通訊。在關鎖的時候，只是車鎖單方面向伺服器傳送訊息。而同時伺服器收取到訊息後，在地圖上顯示其單車的定位。我想ofo這麼做，原因一定是因為想減少車鎖的耗電量，要知道實時通訊是非常耗電的。
產品/運營/測試/程式設計師必備乾貨【資源下載】
下圖是ofo的程式流程圖
摩拜單車的智慧鎖
上面分析了ofo的機械鎖和偽智慧鎖以後，我們再來看看摩拜單車的智慧鎖，到底智慧在哪裡。
首先通過實際體驗我們知道，摩拜單車是不需要輸入密碼的。拋開藍芽本地驗證密碼的方式，那摩拜車鎖需要和伺服器實時通訊，才能實現APP掃描之後自動開啟。
可能有些讀者不明白為什麼一定要實時通訊呢？難道在開鎖時，伺服器給車鎖傳送開啟的指令不行嘛？舉個例子，手機開飛航模式的時候，是無法接聽電話和資料上網的。手機想接聽電話和上網，就一定要每時每刻和通訊基站連在一起，這樣才能保證通訊基站想要找你的時候可以找到。如果你和通訊基站斷開，基站是無法知道你在哪裡的。但如果你想要連線基站，只需要關閉飛航模式，開啟訊號，就可以和基站重新連線起來。這就是摩拜單車需要實時連線伺服器的原因。只有這樣才能實現單車在地圖上的定位以及掃碼開鎖。其實摩拜為了實現此功能也是大費周章。因為車鎖比較耗電，傳統電池是無法支撐的，所以摩拜的車採用了機械發電的原理。只要有人騎車，就會將機械能轉化為電能，給車鎖充電。這也解釋了為什麼摩拜的車比較難騎，阻力大，車身重。
下面依據上述原理，畫出摩拜單車的程式流程圖
由上圖對比ofo的流程，可以看出摩拜採用的解決方案是將自行車與伺服器連線。讓每一個自行車都成為一個終端，實時同步在整個地圖上面。這樣既獲得了良好的用車體驗，也收集到了使用者資料。就解決方案來看摩拜是比ofo完善很多的。
單車車鎖的藍芽解決方案
大家在用摩拜或ofo時，可能經常會看到提示：用藍芽解鎖更加快捷方便。那其實現原理是什麼樣的呢？我們不妨推測一下。首先，使用者在開啟藍芽後要讓單車解鎖，那就一定要和單車連線起來，否則不可能實現解鎖。那單車的藍芽就必須是實時開啟的狀態，以供任何時候使用者進行解鎖。那這時又有一個問題，如果周圍有很多單車，那我的藍芽到底要和哪輛單車匹配呢？這時就體現出掃碼的作用了。我一定是掃碼的時候，告訴伺服器：我要解鎖XX編號的單車。那伺服器會返回給你這個單車的藍芽"口令"，你通過“口令"與附近的藍芽匹配，能匹配成功的一定是你想開的那輛自行車。因為你手機的藍芽和單車的藍芽距離非常近，藍芽匹配是非常快速的。所以，通常摩拜或ofo都會推薦大家使用藍芽解鎖，這樣的成功率更高，速度更快。就藍芽解決方案來說，ofo和摩拜其實沒有太大區別的。
至於藍芽解決方案的流程圖，就交給大家當作本文的作業。如果你想檢驗一下本文對你到底有沒有幫助，那麼你可以嘗試去畫一畫藍芽解決方案的流程圖。相信我，非常簡單的。
以上就是整個ofo與摩拜解決方案的對比，其中我也畫出了不同階段的流程圖。基本可以代表我分析案例的一些思路。最主要的還是讓大家能夠理解並應用流程圖到日常產品設計與分析中。我們在構建流程圖時，如果能按照本文的方法，由業務到程式，由簡單到複雜，那相信一定會讓你的思路更加清晰順暢。
（作者：臻龍，http://www.jianshu.com/u/d63842fef32b）
更多文章與網際網路乾貨資源下載，請關注微信公眾號【非典型運營】
