上篇文章講了《頁面流程圖如何繪畫》,這篇文章講講PM畫得最多的圖形「功能流程」。下一篇講如何畫業務流程圖。
這就是我所理解的產品架構三部曲。
先梳理一下大部分PM畫功能流程的常見錯誤,方便理解其邊界。
特別容易把業務模塊也畫到功能流程圖裡面。
區分你的功能流程圖裡面有木有業務模塊並不難。唯一的判斷標準是該圖中的每個節點都應該是這個產品中真實存在的功能名稱,否則應該是混入了其他東西。
真正的難點在於如何將業務流程映射成合理的功能流程,以及功能流程如何映射成恰當的業務流程。
其次容易將頁面寫到功能流程圖裡面。比如某頁面只是某個功能的子集,你非要把它寫到功能流程圖裡面,是不合適的。
比如微信裡面,發送照片給好友是一個功能,但是涉及到的頁面「照片」、「選擇相冊」、「某一相冊詳情」以及操作「選中某一照片」,他們都不是功能,完全不應該顯示在功能流程圖裡面。
當然某些功能的命名,有可能和頁面是一樣的。
每個功能可能包含很多操作,比如微信中發送照片給好友,包含了」點擊相冊」,」滾動照片列表」,」選擇照片並發送」等操作。需要正確區分操作不是功能。
講了一些常見的錯誤畫法之後,再次定義一下功能流程的概念。
功能流程是指產品的所有功能以及相互間關係。
注意功能是相互獨立的,但是通過合理組合,可形成新功能。不太建議用一級功能二級功能,父功能子功能的叫法。
功能,使用矩形表示。
功能流向,使用有線箭頭表示。
條件,使用有線箭頭上的文字表示。
已定義流程,使用組合矩形表示。不是必須的,如果整個產品的功能太複雜,可能需要。
詳見我整理的功能流程圖資料,點擊查看。
要麼是名詞,比如購物車。可加定語,比如我的紅包。
要麼是動賓短語,比如確認訂單。
要麼是通用叫法、比如我的。
可以參考同行業的TOP5競品。
如果功能簡單,產品層面的1個功能儘量對應著Axure的1個Page。如果很複雜,請拆分到多個頁面。
詳見產品需求文檔需要遵循的命名規則。
功能是邏輯意義上的概念,用戶是感知到該產品具備哪些功能。一個功能可能是跨越多個頁面,也可能存在於某頁面裡。而頁面是物理意義上的概念,用戶可以在產品裡面看到包含哪些頁面。
另外功能本身是相互獨立的。但是通過合理組合,可形成新功能。不太建議用一級功能和二級功能,父功能和子功能的說法。
按照PM設定的用戶使用產品流程,來畫出每個節點的功能。從首次打開APP開始算起,進入首頁會有多種走向,均需分別畫出來。
請注意不要隨意把頁面名稱畫進來,除非你確定含有一個同名的功能。
比如上圖乍一看,好像這幾個都是功能,畫得好像並沒有錯。點擊對應的原型地址,方便理解下文。
可事實上,首頁只是頁面的叫法,而不是功能。另外它至少包含了發布邀約,查看邀約列表,頻道列表三個功能。
使用有向箭頭將功能之間聯繫起來。注意箭頭方向代表用戶的使用步驟。
如果你是使用Axure,請不要傻乎乎的使用默認模式拖一根線到2個功能矩形框上,而是切換到連接線模式然後滑鼠移動到矩形框連接紅點並關聯到另外一個。
很多功能是有前置條件的,請使用有向箭頭並輔以文字表示。
所謂的條件就是前後端需要判斷的邏輯。常見的條件有3種邏輯結構。
上面說的幾個常見錯誤,最好檢查一下有沒有犯。
根據上面的步驟,我大概畫了一下微信客戶端主要的功能流程圖。
完整的圖形可以點擊源地址查看。
如果你們的產品比較複雜的話,可能需要根據用戶角色、前後端不同來分別畫出對應的功能流程圖。
比如微信的功能流程圖,至少有用戶使用微信,用戶使用小程序,自媒體使用公眾號,開發者開發公眾號,開發者開發小程序等很多個。
簡單來說,你先得清楚你們的業務需要多少個產品來支持,產品間的關係是什麼,每種產品需要多少種用戶角色,相互間的關係,有多少個端。
下篇文章《如何正確的畫出業務流程圖》會細講這方面的知識。
如何正確地畫出頁面流程圖
如何用ER圖繪製業務實體模型
如何繪畫狀態機來描述業務的變化
移動PM需要梳理這些流程圖
浪子,業務型PM,浪子PRD系列51prd.com,公眾號langzisay。
本文由 @浪子 原創發布於人人都是產品經理。未經許可,禁止轉載。