制作人人喜歡的流程圖，三步教會你繪制大廠流程圖（第二篇）繼幫大家解決了如何繪制流程圖的難題后，本篇將關心大家學習：如何繪制出研發(fā)喜愛看、運營看得懂的流程圖。

學習了上一篇“流程圖的大廠畫法”后，雖然能畫出來了。但常常發(fā)覺畫的沒問題，研發(fā)部卻不看我們的流程圖，運營看不懂我們的流程圖。這是什么緣由呢？

其次，就是總是丟三落四，想不全面被研發(fā)懟來懟去，如何做到思索全面呢？本篇解決這個問題。

這一篇是介紹“如何制作人人喜愛的流程圖”。

詳細內(nèi)容如下：

為什么你的流程圖別人不滿足？以一些例子來看研發(fā)和業(yè)務人員流程圖要看什么。流程圖的尺度如何把握？能夠依據(jù)給研發(fā)還是給業(yè)務人員，來畫出尺度得當?shù)牧鞒虉D。如何一步步畫出不丟三落四的流程圖？理順你的思路，做事不再丟三落四，表達清楚順暢。下面我們就進入正題。但假如看了下文，對流程圖的UML表達方法還不了解，則請移步第一篇《如何制作正確的流程圖？》

一、為什么你的流程圖別人不滿足？

首先看下面的兩張流程圖，以下流程圖假如給研發(fā)或業(yè)務人員看都是有問題的。

給業(yè)務人員的流程圖

給研發(fā)人員的流程圖

那為什么有問題，這里就要明白對方看流程圖的目的是什么？

業(yè)務人員：看了流程圖，好明確自己在其中做什么，或者對工作流程提出不同看法。研發(fā)人員：看了流程圖，好進行相關的研發(fā)設計。給自己：看了流程圖便于自己梳理規(guī)律，不需要給任何人看。那么我們就以例子來看問題，相關人等對流程圖都有什么疑問呢？

1.

業(yè)務人員對流程圖的不滿足

給業(yè)務人員看的流程圖

先回到我們上面兩個案例的第一個圖，假如這是一個給業(yè)務人員看的，對于業(yè)務人員只關懷自己需要做什么。此時把“生成送貨單”加入就極為不合適。

此時業(yè)務人員會一臉懷疑的說：“系統(tǒng)生成訂單？這個和我有什么關系嗎？我去送貨當然要送貨單了？”。這里發(fā)覺畫了一些多余的內(nèi)容。

另外補充一下，給業(yè)務人員的流程圖，研發(fā)也需要看，目的是為了理解整體業(yè)務，便于設計業(yè)務。

另外上面的流程圖規(guī)律上也消失了錯誤，詳細請移步系列文章《第一篇：如何制作正確流程圖》的錯誤案例三。

2.研發(fā)對流程圖的不滿足

再來看其次個圖，假如作為初學人員，畫一下給自己梳理規(guī)律明顯是合理的，這也就是我們說的第三類作用“流程圖畫給自己看”。但此時研發(fā)會一臉不耐煩的說：“來點干貨，不就是兩個頁面嗎？給個原型看看？我不關懷你思索的過程”。

這時倒不如直接給出1-2張頁面流程圖更直接。在簡化的頁面流程圖里，體現(xiàn)主要功能和下一步的按鈕等內(nèi)容。

上面兩個流程圖，一個就體現(xiàn)了給業(yè)務人員用的，一個就體現(xiàn)了給研發(fā)人員用的。那么流程圖應當怎么把握尺度呢？

二、流程圖的尺度該如何把握？

可以根據(jù)兩個尺度來畫流程圖，稱其為：給業(yè)務人員看的“人人交互模式”和給研發(fā)看的用“人機交互模式”。

下面我們分別表述。

1.給業(yè)務人員看的“人人交互模式”

對應去掉系統(tǒng)后，人和人之間的交互，此時忽視系統(tǒng)在其中做了什么。以下面的流程圖為例：

你發(fā)覺我們的表述的意思是“用戶支付訂單→只有用戶支付完訂單后，客服才能確認訂單→客服確認訂單后物流才能來收貨”。

這里體現(xiàn)了人每做一步后，另外一個人才能做另一件事情，沒有體現(xiàn)系統(tǒng)在這其中專遞信息做了什么，如“系統(tǒng)創(chuàng)建訂單→系統(tǒng)顯示訂單給客服”等中轉(zhuǎn)過程。因此我們稱其為人人交互模式的表達。

這個維度上，可以讓業(yè)務人員聚焦于自己需要做什么事情上。

從遞送發(fā)票這個環(huán)節(jié)看，我們也是這樣的規(guī)律“財務打印發(fā)票→打印完畢后物流才能寄送發(fā)票”，也體現(xiàn)了一個人人交互模式。

而這里特別的地方是：

“用戶支付完訂單”，雖然是對系統(tǒng)的操作是人機交互了，但沒有這一步就不會進行發(fā)貨；“用戶點擊確認收貨”，沒有這一步，訂單就不算完成。因此也要在流程圖里面體現(xiàn)。2.給研發(fā)看的用“人機交互模式”

留意人機交互級別的流程圖，主要涉及到人輸入什么，系統(tǒng)會反饋什么，但是有兩個原則需要留意。

1）原則一：一個頁面定義成一個操作

看下面的例子：

假設在商品詳情頁此時展現(xiàn)的是一件衣服，則可以選擇衣服數(shù)量，選擇衣服顏色和大小等操作，但流程圖的作用不是表達詳細功能的，所以忽視這些操作。

一個頁面只表達一個操作，下面的頁面的第一個操作就是“用戶點擊確定”，概括為“用戶選擇商品”。而后面的兩個頁面也可以概括成“用戶提交訂單”和“用戶支付訂單”。

另外不要寫畫成“用戶選擇商品→系統(tǒng)顯示訂單→用戶確認訂單→系統(tǒng)顯示支付界面→用戶支付訂單”，沒有錯但略顯啰嗦。

流程圖重點表達做了什么事情，是不關懷全部的功能。用流程圖表達功能也不是最佳方案。

假如這個例子想表達的是頁面的功能，建議直接畫頁面流程圖即可，這個表達對研發(fā)更簡單閱讀?；蛘哂糜美龍D來表達功能合集表示功能之間的包含關系等，都是比這個更恰當?shù)谋磉_方式。

再如下圖，有的人說是否應當將其中的細節(jié)畫出來？如：推斷是否已經(jīng)上架，推斷是否有庫存等。

結(jié)論是不應當畫。

流程圖如何表達細節(jié)？

這里也不符合一個頁面一個動作。這里的推斷是簡潔的，還是建議直接在原型邊上寫規(guī)律即可這個流程圖研發(fā)是不太看的。但再次強調(diào)作為自己梳理規(guī)律可以做。

2）原則二：和后端服務器交互的定義成一個操作

詳細看下面的流程圖：

和后端服務器交互的流程圖

此時當用戶進行登錄操作的時候，輸入完用戶名和密碼并點擊確定，此時APP需要詢問一下服務器：服務器大哥，請告知我密碼是否正確？

系統(tǒng)會回答：密碼是正確的，或者密碼是錯誤的，或者這是一個用戶名沒有注冊過。

這些涉及到和服務器的交互，明顯不問服務器就不知道，則可以在流程圖里體現(xiàn)出來。

留意此時忽視人和APP在一個頁面內(nèi)的交互。如：如輸入手機號后提示手機號格式錯誤，你會發(fā)覺就是一些簡潔的前端規(guī)律推斷，還不如在原型頁面寫備注來的簡潔和高效。

下面這兩個流程圖都屬于過度表達了。

過度表達的流程圖

過度表達的流程圖

3.

尺度的總結(jié)

給業(yè)務和研發(fā)部門呈現(xiàn)時：用人人交互模式，忽視系統(tǒng)所做的工作。給研發(fā)部門呈現(xiàn)時：一個頁面一個動作，可體現(xiàn)和后端服務器交互的動作，而忽視掉簡潔的前端交互。

了解了流程圖的尺度后，我們還要思索如何一步步畫出流程圖。其中給業(yè)務部門的流程圖是最常用的。我們下面就以給業(yè)務部門的流程圖為例進行講解。

三、如何一步步思索畫出流程圖？

這里有兩個基本原則：

打通主流程：先粗后細，再加泳道；完善細節(jié)：先加特別，再拆流程，再合并流程。我們分別表述。

1.打通主流程：先粗后細，再加泳道

1）第一步：先粗后細的思路

打通主流程意思是不考慮任何特別狀況，就考慮正常完成訂單的流程。在上篇文章中就是根據(jù)這個方式完善了主流程。

我們當時分了三步，分別是：

完成很粗的主流程；完善送貨流程細節(jié)；完成寄送發(fā)票等細節(jié)。這里就體現(xiàn)了先粗后細的原則。

完成粗的主流程：

完善送貨流程：

完善寄送發(fā)票等流程：

2）其次步：加泳道的方法

線粗后細完成后，這個過程中消失一個問題，即當有財務、物流和運營等多個角色來處理，每個角色不能很清楚地看到自己的業(yè)務怎么辦？此時可以用泳道來解決。

詳細見下圖：

加入泳道后的流程圖

此時每個角色下面所對應的就是該角色所進行的動作，特別像游泳時的“泳道”。每個泳道對應的可以是：客服、物流、財務等角色。系統(tǒng)也可以算作一個角色，但應盡可能將其看做一個人，而不要拆分成前端和后端。

2.完善細節(jié)：先加特別，再拆流程，再合并流程

這樣算會否就算完成流程圖呢？還沒有，需要進一步完善。概括一下就是：先加特別，再拆流程，再合并流程。我們一個一個來看。

1）第一步：加特別

上面的流程圖我們始終沒有考慮特別狀況。此時可以從第一個動作始終到最終一個動作逐一梳理是否會有特別的加入。

如本例中，從前往后梳理依次是：用戶付款后要求退款怎么辦？客服時候可以不發(fā)貨？用戶假如拒收貨物怎么辦？用戶假如始終不點擊收貨按鈕怎么辦？用戶假如買了以后要退貨怎么辦？假如用戶輸錯了密碼怎么辦？假如用戶不要發(fā)票怎么辦？

這里包括三類特別：不操作如何處理、反悔如何處理、錯誤操作怎么處理？

此時對于用戶不要發(fā)票，我們?nèi)绾翁幚恚?/p>

此時對于“用戶假如始終不點擊收貨按鈕”這個做法，我們就考慮加入“系統(tǒng)自動確認收貨”這個流程了。

加入自動確認收貨

2）其次步：拆流程

列出逆流程后，通常就涉及到每個逆流程的完善。但是我們發(fā)覺“用戶收貨后退貨”這個逆向流程比較簡單，包括：用戶提出退貨需求、商家同意、用戶寄送和商家退款等環(huán)節(jié)。則退貨流程就可以在其他流程圖里面再畫，這就體現(xiàn)了拆流程的特點。

再如“用戶支付訂單”會存在支付勝利、支付失敗、待支付等等流程也可以在其他流程圖里面處理。

3）第三步：合并流程

我們看訂單寄送發(fā)票的流程包括“財務打印發(fā)票，物流寄送發(fā)票”兩個步驟，可以抽象成寄送發(fā)票。

對于財務人員當然要開發(fā)票，寫不寫不影響問題的理解。在這一步重點在于，去掉本次流程圖不關懷的內(nèi)容。假如系統(tǒng)自動收貨不是你本次重點表達的內(nèi)容，也可以去掉。

通常小白還會在流程圖加入假如用戶沒有登錄去引導登錄等推斷。在開頭做練習的時候做都可以，但提交給研發(fā)則是沒有必要加入。

四、總結(jié)

本次介紹了三部分內(nèi)容，分別是：

流程圖給誰看：重點闡述了給業(yè)務人員，研發(fā)