流程圖中的常用圖形 流程線（FlowLine）是單箭頭線，起始于一個圖形，終止于另一個圖形，代表了流程的流轉。通常用實線表示，在多任務間跳轉或次要流程流轉時，也可以使用虛線表示。
起終點（Terminal）可以用圓型、橢圓或圓角矩形來畫，通常寫著“開始”、“結束”，或其他代表流程結束的短語，如“提交信息”等。 操作（Process）用矩形表示，指某件事發生了、做了什么操作等，如“輸入身份證號”、“查詢交易記錄”等。 條件判斷（Decision）在多情景中，需要進行條件判斷，用菱形表示。一般來說，條件判斷多為是與非（或對與錯）的結果，于是就有兩條流程線從條件判斷中流轉出，通常正面回答的流程線從下方流轉出，負面回答的流程線從右側流轉出。每條流轉出的流程先必須標明判斷結果（即是或非）。當然也會存在多種判斷結果的情況，這時候會有多條流轉出的流程線，注意標注清楚每條流程線上的適用條件。在這種情況下，要特別注意是否遺漏某些條件，所以建議將復雜的條件判斷，拆分為多個二元判斷的組合，這對于后續對外溝通、自我檢查來說也更加友好。 預定義操作（PredefinedProcess）用左右雙線的矩形表示。在一些復雜流程中，有些復雜模塊可以單獨進行詳述，此時在主流程中，就可以使用預定義操作模塊進行指代，并在其他地方進行詳述。 以上五種是流程圖中最最基礎的常用圖形，對于設計師來說，也基本夠用了。在學習完基本功后，你就可以進行自我修行了！（不負責任的作者啊喂o(+一︿一)o） 一個小練習 好了，那我們來做一個小練習——最常見的登錄功能。這，似乎看起來很簡單。于是有了以下這張流程圖： 似乎并沒有什么問題。但是（記住，通常每個“似乎”都有一個“但是”在等TA），這里的登錄要素只考慮了手機號+密碼一種方式，是否滿足需求呢？為什么沒有郵箱登錄？昵稱登錄？手機號+短信驗證碼登錄？繼續看第一步輸入手機號，是否會存在手機號格式錯誤、手機號未注冊的情況？系統是否有必要對手機號進行單獨檢驗？如果單獨檢驗，會不會有什么安全隱患？不檢驗，是否體驗友好？如何進行評估？其中的操作、判斷是由用戶來做還是系統來做？系統做的話，是前端還是后端做呢？用戶忘記了密碼怎么辦？等等等等。看似簡單的登錄流程，竟然會如此狀況百出。 這里分享幾條我畫流程圖的心得體會： 面向操作的流程圖 不同的學科、不同的人都有不同的畫流程圖偏好。有些人喜歡面向頁面的流程圖，有些人偏愛面向狀態的流程圖，而我更傾向面向操作的流程圖畫法，這樣做可以更聚焦在任務本身，排除界面元素干擾，（具體界面設計應在流程圖的基礎上進行后續的深入）。 由繁入簡 在剛開始訓練的時候，建議盡可能地將流程圖畫細，每一個操作每一次判斷都詳細畫出，能拆分的情況都進行拆分，思考盡可能地全面。 站在不同的角色角度進行思考 在畫流程圖的時候，應當多思考各項操作、判斷的操作者是誰，是系統還是用戶，并用不同顏色（或其他方式）標明。 不同情況全覆蓋 對照流程圖檢驗是否滿足所有情況。最簡單的檢驗原則就是每條路都應該走得通，都有開始和結束的點而非莫名終端，每個判斷都至少有兩條流轉出的路。 發掘新設計點 在流程圖中，可以這樣問自己，會不會有無法進行某操作的情況？在每一種發生錯誤的時候，是否有對應的設計對策？如在登錄的任務中，就發掘出了用戶忘記密碼的情況。 基于以上考慮，我們來優化下登錄功能的流程圖，假設這里的登錄方式僅允許手機號+密碼一種方式： 注意，因為涉及到“注冊”、“忘記密碼”兩種新的情況，所以在這里限于篇幅，就用虛線流轉線、預定義操作的圖形來簡述。若要具體展開，那就是一整套的登錄/注冊咯~ 關于流程圖的學習就先講到這里。 流程圖的練習是一個熟能生巧的過程，記住：站在不同角色角度多思考、勤練習多推敲、覆蓋全情況、發掘新設計點。相信在經過嚴謹的訓練之后，面對再復雜的需求也能夠游刃有余化繁為簡了。
