案例分析:繪制流程圖需要注意哪些事項?
流程圖應用于許多領域,在互聯網產品設計中,無論是產品經理、交互設計師,或者開發人員,都經常接觸到各種類型的流程圖。流程圖不應該考驗閱讀者的理解能力,因此如何繪制清晰簡潔的流程圖,值得深入思考。本文將結合案例,說明互聯網產品設計中,交互設計師繪制相關流程圖需要注意的事項。
一、流程圖的定義、優勢及作用、基本構成元素
1. 什么是流程圖?
ISO(國際標準化組織)對于流程圖的定義,讀起來有些晦澀難懂。通俗而言:流程圖是通過使用箭頭和不同形狀的框,將流程中的關鍵操作路徑呈現出來。
2. 流程圖的優勢及作用
流程圖是對流程路徑的一種可視化表達,易于理解,便于準確判斷步驟之間的邏輯關系。規范的繪制思路和方法,可減少上下游不必要的溝通。
流程圖對于記錄復雜的操作任務流程很有幫助,在交互稿或交互文檔中呈現流程圖,有以下作用:
- 幫助交互設計師理清需求的關鍵任務路徑。
- 便于產品上下游人員快速了解核心操作流。
- 有助于交互設計師對照復查頁面流,避免缺漏或錯誤頁面。
3. 流程圖的基本構成元素
二、互聯網產品設計中的流程圖,大致可以分為三種類型
1. 業務流程圖
表達產品業務邏輯的流轉路徑,不涉及具體操作與執行細節。通常使用“泳道圖”來呈現多角色的配合,一般產品經理使用的較多。
2. 任務流程圖
表達產品功能邏輯的流轉路徑,指完成某個具體任務的操作流程。這個相比業務流程圖,已經落實到界面設計的流程中了。通常產品經理和交互設計師使用的較多。
3. 頁面流程圖
表達頁面元素及頁面之間的邏輯跳轉關系。流程中流經的每個矩形框均對應一個頁面,通常交互設計師使用的較多。
我把頁面流程圖細分為兩種:
(1)流程圖路徑的每個矩形框均對應一個頁面
下圖1以Keep首頁尋找訓練課程的流程舉例說明:
(2)將流程圖和原型圖結合的方式呈現,通常是呈現判斷邏輯及相關頁面
這種方式的優點:對頁面邏輯判斷更加直觀。缺點是:針對一些判斷比較復雜的功能頁面,反而不利于呈現。
下圖2以PC端“驗證郵箱”舉例說明:
三、交互設計師繪制任務流程圖,需要注意的事項
(1)在繪制流程圖時,需要將業務、功能和頁面三者的描述區分清楚,避免不同類型的流程圖混雜在一起
下圖1是正常的郵箱注冊任務流程圖,但下圖2的流程中紅色框選路徑,混入了有關業務的數據庫匹配校驗,以及具體的跳轉頁面名稱,這些不是用戶操作時關心的事情,屬于多余的步驟。
(2)繪制流程圖一般遵循從上往下,從左往右的結構,從整體的主流程到局部的分支流程
比如畫流程圖時,先把正常的流程梳理清楚(主流程),再考慮判斷標識中的逆流程(分支流程)。
下圖以印象筆記的手機號注冊流程舉例說明:左側為主流程,右側為分支流程。
(3)流程圖的路徑走向需要有始有終,形成閉環。不能存在某個步驟中斷找不到解決辦法的情況
下圖在郵箱注冊流程中,紅色框選部分判斷“郵箱是否有效”時,沒有說明郵箱無效時該如何解決,這里的流程是缺失的。
(4)靈活使用子流程
某些子流程可能被頻繁復用,如果每次都把子流程展現出來,一方面增加繪制時間成本,另一方面使流程圖變得冗余,降低了可閱讀性。因此被頻繁復用的子流程可以繪制后存入“流程圖庫”中,這樣再次使用該子流程時,只需要用子流程標識說明即可。
“流程圖庫”是指某個產品中經常需要被復用的基礎流程圖的集合。依據不同的產品建立不同的流程圖庫,也便于多位交互設計師協同工作。
如下圖,某后臺用戶需要修改更換手機號,但是在修改手機號之前需要該用戶輸入賬號的密碼,出于安全性考慮需要二次確認用戶身份。圖中藍色框選區域是“手機驗證碼校驗”的子流程。
(5)流程圖的結構大致分為:順序結構、條件結構和循環結構
至于結構更復雜的流程圖基本也是由這幾種結構組合而成。
下圖以keep健身應用查找訓練課程的流程為例說明:
順序結構:一般指主流程。
條件結構:牽扯到邏輯判斷。經常遇到需要處理的是“是或否”的選擇。
循環結構:條件本身的滿足狀態處于可激活狀態,通過重復某一要素可滿足該狀態。常見形式是形成小范圍的閉環,比如:上面提到的輸入賬號密碼錯誤的情況。
(6)按照模塊繪制
往往一個大的需求中包含多個任務流程圖,這種情況可以按照不同的任務繪制。比如一個App包含“登錄注冊、購買支付、身份驗證等功能”,其中每個功能都對應一個或多個任務流程圖。
(7)流程圖中的連接線避免出現交叉,否則會降低可閱讀性
總結
以上內容簡單介紹了互聯網產品設計中常用流程圖的基本概念,著重介紹了與交互設計師工作相關的流程圖類型,以及繪制任務流程圖需要注意的事項。
目的是幫助交互設計師繪制出清晰簡潔的流程圖,也便于產品上下游工作人員快速理解需求的核心任務路徑。
需要注意的是,以上提及的內容是普遍適用的規則,希望大家能根據實際項目的具體情況靈活使用。規范只是給你提供一個指引避免方向錯誤,切記不要被規范約束而無法因地制宜。
參考文獻:
作者:Viksea,微信公眾號:Viksea(ID:viksea-ux)
本文由 @Viksea 原創發布于人人都是產品經理。未經許可,禁止轉載
M
作者注意到沒有,開頭說完流程圖分為業務,功能,頁面三類,后面又引入了一個任務流程圖的概念,不知是筆誤還是,給理解文章造成了一定的不便
是我看錯了,抱歉
業務流程圖,任務流程圖,理解應該是一個是業務角色節點,一個是功能任務節點
很不錯?。?/p>
菱形判斷框本身帶有“判斷屬性”,里面還要加“是否”兩個字么
我習慣用是否陳述
為了所有人都看得懂,加上吧。無非就是捋一下語句
不用
大佬,我就不知道業務流程和功能流程到底怎么區分啊,每次都只畫一個流程圖??
個人理解:
業務流程圖只需要畫出每個角色在流程的點中起到什么作用,通常在和需求方初步溝通的時候用來判斷大體方向是否有偏差,功能流程就比較復雜,要畫出各種細節,主要是用來和內部人員溝通,也要畫出開發時的一些基礎邏輯。舉個例子:比如請假審批的業務流程就是用戶登錄->發起申請->上級審批,上級通過拒絕就好了。功能流程圖則需要畫出用戶“登錄判斷”“輸入資料”等詳細流程
不知道+1同問,謝謝大佬
業務流程圖我也沒有深入思考過,具體可以參考泳道圖。任務流程圖就是展現功能性的邏輯。最好不要把兩者混淆在一個流程圖中,不然自己畫的時候也混亂。
冰樞,我想請問下(我知道怎么回復您…只能回復層主了…):業務流程是否就是直接默認為所有步驟都是成功狀態,一直到最后結束,比如登錄直接默認登錄成功,提交資料也是直接默認成功,然后進入下一步。而功能流程則需要繪制出出邏輯判斷的情況。不知道我理解的對嗎?
建議去看那篇-有ofo例子的流程圖介紹文,