第一部分：什么是流程圖？
1. 定義
流程圖=流程+圖，如下圖：
流程：Flow,是指特定主體為了滿足特定需求而進行的有特定邏輯關系的一系列操作過程，流程是自然而然就存在的。但是它可以不規范，可以不固定，可以充滿問題。所以就會造成看似沒有流程。前不久，團隊每個人對接一個業務團隊去調研流程，反饋給我的流程有一些缺失。詢問時，負責人反饋給我的答復是：這一塊業務他們沒有流程。其實嚴格意義上講，業務已經開展，不可能沒有流程，只是說沒有固定的流程或者你調研的對象也講不清楚。
圖：Chart 或者 Diagram, 是將基本固化有一定規律的流程進行顯性化和書面化，從而有利于傳播與沉淀、流程重組參考。
從定義可以看出，只要有事情和任務，流程就會有，但是并不是所有的流程都適合用流程圖的方式去表現，適合用流程圖去表現的流程是一定程度固定的有規律可循的，流程中的關鍵環節不會朝令夕改的。
2. 流程圖與其他圖表的對比
工作中我們還用到或聽到很多其他類型的圖表，比如交互設計師們經常說的線框圖(Wireframes)，信息架構圖或站點地圖(Site Map)，，開發工程師們經常說的用例圖(Use Case)或E-R圖。這些不同的圖表要表達的內容有何種差異呢？簡單做個對比，如圖：
如果要串到某一個項目來說，可以理解成：
用例圖（Use Case）：表現了一個角色在系統里要完成的活動是什么，比如用戶這個角色與ATM取款機的交互過程中，用戶需要完成的活動有存錢，取錢，查詢等。而存錢這個活動再可以進一步細分為插卡，輸入密碼，輸入金額，ATM吐鈔，用戶收款，退卡等活動。用例圖可以不考慮用戶動作的前后次序，而僅僅提取一些關鍵的動賓短語，映射出系統應該滿足的功能點。常用用例圖的人是產品經理和開發工程師。
流程圖則表示用戶每一個活動的前后次序，比如用戶必須要先插入銀行卡，才能夠輸入密碼，且流程圖必須直接表現出各種異常判斷，比如當密碼錯誤時，出現什么提示，密碼輸入錯誤超過多少次時，出現什么提示和動作。常用流程圖的人是產品經理，設計師，或者任何需要講述業務如何運作的人。
信息架構圖，站點地圖(Site Map)：表現為了做一個這樣的系統，功能與內容的展現層次是什么，比如用戶一進去后，歡迎頁面的導航如何設計，是否直接出現取款，存款，查詢，或者還有別的導航？常用信息架構圖的是設計師。但是常用組織架構圖的是HR。
線框圖（Wireframe）：將具體每個界面的內容布局和權重表達出來，且標注出一些交互細節的設計，比如當密碼錯誤后，如何提示下一步動作。常用線框圖的人是設計師。
實體關系圖（E-R圖）：則是數據庫架構的工作，表示一個業務系統或場景中的實體時間的關系，比如儲戶與銀行卡的關系是歸屬1對多，通過開卡事件產生關聯。一般來講，用矩形來表示實體，橢圓標識這個實體的屬性，比如儲戶這個實體的屬性有：姓，名，手機號碼，住址等。而銀行卡的屬性有：開戶行，開戶名稱，銀行卡號等。
以上的這些圖表各自都有領域的專家，我這里就不班門弄斧了。
那么流程圖要體現出他的差異定義，要素是什么？總結出了流程圖的6大要素，希望大家能夠記住，這6個要素可以在以后的文章里不斷回顧，你也可以拿來判斷你所看到的流程圖是否專業。
參與者：誰在這個流程中？可以是系統，可以是個打印機，更多的指什么角色——一般是有某種工種的人。比如客服同時有小A和小B兩人，但是若他們的工作性質完全一樣，那么在流程圖里只需要寫一個客服角色就可以了。
活動：做了什么事，比如點餐，結帳等活動。
次序：這些事情發生的前后順序如何，哪個任務是其他任務的前置條件？比如客人不結帳，就不會產生送他優惠卡的活動。
輸入：每項活動開始取決于什么樣的輸入物或數據，比如做飯的師傅開始做菜時，需要拿到具體的點菜單。
輸出：每項活動結束后，會輸入什么樣的文檔或數據傳遞給下一方，比如師傅做好菜后，如何讓負責傳菜的人知道菜已經做好？
標準化：采用一套標準化的符號用以傳遞你的流程圖，從而使受眾更快明白。
關于流程圖的標準化，并不是強制的，事實上，我們見過很多種類的流程圖，只要能夠傳遞明白任務和次序其實
第二部分：流程圖的分類？
常見的流程圖有業務流程圖（Transaction Flow）, 頁面流程圖（Page Flow）。
在工作中，作為UED，你可能會發現PD經常談的是業務流程，而作為交互設計師，我們更多產出的是頁面流程圖。頁面流程圖和業務流程圖到底有什么關系呢？ 先有誰，其次再有誰呢？
先講個故事：假設你的夢想是開個中高檔的全國連鎖餐館，那么首先你想到的應該不是如何去選址，而是將為何要開連鎖餐館這件事情，以及你的定位，核心競爭力想清楚。是快餐，還是點餐，是連鎖還是加盟？定位于社區還是繁華商圈？是川菜還是江浙海鮮？是面向中老年還是年輕人？是家庭主題還是動漫主題？競爭對手是誰？需要什么樣的投資？可能的風險是什么？這些都想清楚了，問題都有答案了，所謂戰略層要清晰了吧。然后假設你現在分析來分析去，與主要投資方決定了一個方向：面向年輕人的時尚動漫茶餐廳，連鎖，但是先在杭州開始第一家，選址定位于年輕人約會，掃街的地域，比如風景區，著名商圈，電影院旁……那么，接下來呢？
接下來就是想辦法讓這些實現吧？那么需要做什么事情呢？選址？拉投資？搞裝修？選餐飲菜單？雇傭員工？每一步怎么去做，時間點是什么？等等的任務拆解以及計劃，就需要到戰術層了。
這些事情的執行，總是需要請人的吧？先是核心團隊分工去部署各項建設任務，當餐廳開設起來后，就需要組織穩定的運營團隊，如服務、衛生、廚房、采購、人事等等，廚房里面還得分工，白案，熱菜，冷菜等等吧？每個部門需要設置管理層以及匯報關系吧？所以你的組織結構就誕生了。
那具體每種角色是如何順暢合作完成日常穩定的以及突發的各項任務呢？比如，當顧客上門時，誰去引導客人入座，誰去點菜，怎么將點菜的訊息迅速傳遞到廚房，并分發到酒水間、冷菜間、熱菜間？并保證客人盡快能夠吃到所點的菜？你必須要考慮各種人員的協作流程，優化效率，所以業務流程就出現了。
人肉運營了一段時間，沒有借助任何點餐系統，你發現也還可以。客人點菜時，服務員手抄寫下客人的要求，因為有復印紙，所以服務員能夠將副本送入廚房，同時寫下餐桌號碼。廚房規模較小，負責分配任務的員工看下菜單，分別往冷菜處的黑板上寫下需要他們處理的，以及跑到熱菜區的黑板上寫下待處理的菜品，以及去酒水間報下品名即可。可是隨著經營的擴大，以上的人肉方式出現了很多問題，首先，手抄效率太低，顧客頻繁換菜，響應來不及，手抄出錯，導致經常報錯菜。廚房很混亂，不得不多招了幾個人專門跑堂。而一旦顧客要加菜，撤菜就更麻煩了，需要找出他們當時點的菜，再進行人工的批注和修改，同時要修改廚房后端的各個黑板……
所以你們想要開發一套智能系統，取代很多人肉工作，你們請了系統開發團隊，他們經過評估，判斷從點菜開始，一直到傳菜都可以用系統解決。手持終端，能夠快速傳遞顧客點菜需求到打印機，打印系統能夠根據顧客點菜的類型進行自動的分單打印，所以熱菜間看到自己的熱菜菜單，冷菜間看到自己的冷菜菜單，而酒水間看到酒店菜單。當他們準備完畢后，送出，傳菜員可以根據菜名與打印出來的單據進行傳菜并根據顧客的點菜小票進行核對。這套系統同時必須配備結算系統，將最終確認掉的菜單及消費價格傳遞到結算前臺，收銀員能夠快速進行操作。
這套系統最終是需要展現出來的，那么手持終端的界面如何設計？服務員能夠用更少的點擊完成一個菜的點餐嗎？結算中心的界面如何設計？
通過以上的故事，是不是更明白從戰略、戰術、業務流程圖到頁面流程圖的關系了？總結下：
- 先是有一個業務需求和業務目標，也即我們的愿景是什么？（戰略）
- 然后就誕生了我們需要分解出什么樣的任務，如何執行戰術？（戰術）
- 然后就誕生了需要架構什么部門，崗位去分工協作？（組織架構）
- 然后就誕生了不同的部門在協作完成某件任務時的業務流程？（業務流程）
- 業務流程基本穩定后，往往會考慮優化效率，所以會誕生出系統來支持流程，減少人肉環節，促進數據采集（系統愿景）
- 為了設計這個系統，PD需要思考什么功能能夠取代某個環節的人肉工作（功能需求，系統流程）
- 不管是怎么樣的功能最終都會以界面的方式呈現，設計師們會關注用戶在系統里的任務流，行為路徑，讓用戶完成任務更加高效愉悅。（頁面流程）
當然，除了業務流程，系統流程，頁面流程，還有數據流程被人關注。
我們平時工作中，還會經常聽人談到泳道圖、任務流程圖等等概念，究竟是神馬關系呢
