流程圖是產品經理傳達需求的常用做法，三大類：業務流程、頁面流程、功能流程。分別對應着戰略、戰術、執行三大層次。
業務流程
體現Boss對整個產品的戰略思想。產品經理根據老板的傳達以及自身對產品的理解，梳理出整個產品核心業務的走向，生成業務流程圖。
頁面流程
體現PD對核心業務的高度理解。把核心業務的每一個節點抽象成一張張頁面圖，用頁面跳轉體現節點關系，生成頁面流程圖。
功能流程
體現每個功能模塊的操作路徑。每個核心功能都應該獨立化。先用解耦的思想來最小化每個核心功能，然后用流程梳理清楚每一個操作。額，大部分功能模塊都是和商城購物相關的。具體如下：
1.訂單狀態流轉
2.優惠券領取
3. h5活動制作
4. 項目開發
5. PD到UI配合
總結
按照這樣的思路來梳理產品的整體脈絡，會慢慢從表象的視覺層到抽象的結構層，不僅PD自己對產品越來越理解深刻，同時研發RD也會更容易理解需求。
一、如何正確畫出功能結構圖？
對於PM來說，梳理完產品的整體架構，簡單的功能用線框圖即可，復雜的功能應該怎么辦呢？
這時候，初級PM的做法是一個頁面一個頁面往下畫，一個控件一個控件的摳細節。然后畫到一半有問題，再一個頁面一個頁面往回修改。
（以前趟過的坑）
從時間來看，反復修改十幾遍，浪費時間和精力。
從溝通來看，技術會因為一次性做這么復雜的功能，懟你們。
從結果來看，大家看到的是一個細節很完美整體復雜混亂的功能。
為什么需要功能結構圖
碰到上述情況的時候，首先你應該整體分析一下這個功能，畫出詳情的內部結構，然后和前端工程師過一遍需求。讓大家清楚這個功能由及部分組成。每部分是什么，以及各有什么作用。
最后根據公司的需求，是做完這些功能重要，還是某個時間點上線重要。來綜合考慮是做完整個功能還是只做這個功能的子功能。
這就是功能結構圖的由來。
功能結構圖是什么
功能結構圖是用來表示復雜功能的內部結構，包含了哪些子功能。
設計特性
最好設計成獨立的模塊，和其他功能盡量不存在關聯。
注意是功能內部結構，不要誤認為是功能間的關系。（功能間的關系是功能流程圖）
如何畫功能結構圖
以電商app的下單功能為例，來講一下如何畫功能結構圖。
1. 分析功能結構
當我們接到這樣一個需求的時候，腦子中想到的是我們在京東淘寶等電商平台的下單步驟，很容易就想到至少要這樣做。
然后這時候就直接去畫頁面，或者去抄襲競品來設計原型。
2. 避免步驟頁面化
有3個步驟，那就畫3個頁面好了。
簡單的“步驟=頁面”，只是偷懶的做法。
比如提交訂單可以只是一個提交按鈕，選擇商品可以有多種方式，可能會涉及到多個頁面。
3. 避免功能競品化
貌似競品淘寶有現成的，全部照抄一遍就好了。
事實上你們可能不是電商平台，商品也沒有不同的sku。
細化功能粒度
根據自身業務，將下單功能拆分到更細的粒度。
詳見訂單結構，可以結合訂單物理結構、訂單邏輯結構、訂單金額結構一起閱讀。
如果你願意按照這種思路去拆分，可以避免把步驟當作頁面去畫了。
再對照自己的業務是不是也需要用購物車，是否也需要有優惠券。如果是剛剛上線的，這兩個功能完全沒有必要設計。
4. 控制細分粒度
沒必要無限制地區細分粒度，一般2到3層就夠了。比如一般的下單功能架構圖。
不是不可以，而是一般的情況下沒必要耗費太多的精力。但如果需要拆分最底交易系統架構的時候，是有必要的。有興趣的朋友可以看看淘寶產品十年事或者有贊訂單系統的拆分。
使用axure畫
建議使用axure的流程圖功能來畫，因為還支持跳轉到對應的前端線框圖，方便閱讀。
矩形框
表示子功能，子子功能。
有向箭頭
表示子功能間的關系
虛線框
用來表示這部分屬於哪個子功能
二、如何正確的畫出功能流程圖？
這就是我理解的產品架構三部曲：
常見的錯誤畫法
先梳理一下大部分PM畫功能流程的常見錯誤，方便理解其邊界。
1.混入業務維度
特別容易把業務模塊也畫到功能流程圖里面。
區分你的功能流程圖里面有木有業務模塊並不難。唯一的判斷標准是該圖中的每個節點都應該是這個產品中真實存在的功能名稱，否則應該是混入了其他東西。
真正的難點在於如何將業務流程映射成合理的功能流程，以及功能流程如何映射成恰當的業務
流程。
2.混入頁面維度
其次容易將頁面寫到功能流程圖里面。你如某個頁面只是某個功能的子集，你非要把它寫到功能流程圖里面，是不合適的。
比如微信里面，發送照片給好友是一個功能，但是涉及到的頁面“照片"、“選擇相冊”、“某一相冊詳情”以及操作“選中某一照片”，他們都不是功能，完全不應該顯示在功能流程圖里。
當然有些功能的命名，有可能和頁面是一樣的。
3.混入操作維度
每個功能可能包含很多操作，比如微信中發送照片給好友，包含了“點擊相冊”、“滾動照片列表”、“選擇照片並發送”等操作。需要正確區分操作不是功能。
功能流程是什么？
講了一些常見的錯誤畫法之后，再次定義一下功能流程的概念。
功能流程是指產品的所有功能以及相互關系。
1.功能間關系
注意功能間是相互獨立的，但是通過合理組合，可形成新功能。不太建議用一級功能、二級
功能，父功能子功能的叫法。
2.包含哪些元素
功能，使用矩形表示。
功能流向，使用有向箭頭表示。
條件，使用有向箭頭上的文字表示。
已定義流程，使用組合矩形表示。不是必須的，如果整個產品的功能太復雜，可能需要。
3.功能命名
要么是名詞，比如購物車。可加定語，比如：我的紅包。
要么是動賓短語，比如確認訂單。
要么是通用叫法，比如：我的。
可以參考同行業的TOP5 競品。
如果功能簡單，產品層面的1個功能盡量對應着Axure的1個page頁。如果很復雜，請拆分到多個頁面。
4.功能定位
功能是邏輯意義上的概念，用戶是感知到該產品具備哪些功能。一個功能可能是跨越多個頁面，也可能存在於某個頁面里。而頁面是物理意義上的概念。用戶可以在產品里看到包含哪些頁面。
另外功能本身是相互獨立的。但是通過合理組合，可形成新的功能。不太建議用一級功能、二級功能，父功能和子功能的說法。
如何畫功能流程圖
1.羅列所有功能
按照PM設定的用戶使用產品流程，來畫出每個節點的功能。從首次打開app開始算起，進入首頁會有多種走向，均需分別畫出來。
請注意不要隨便把頁面名稱畫出來，除非你確定含有一個同名的功能。
比如上圖乍一看，好像這幾個都是功能，畫的好像並沒有錯。
可事實上，首頁只是頁面的叫法，而不是功能。另外它至少包含了發布邀請、查看邀約列表、頻道列表三個功能。
2.用有向箭頭關聯
使用有向箭頭將功能之間聯系起來。注意箭頭方向代表用戶的使用步驟。
如果你是使用axure，請不要傻乎乎的使用默認模式拖一根線到功能矩形框上，而是切換到連接線模式然后鼠標移動到矩形框連接紅點並關聯到另外一個。
3.增加條件判斷
很多功能是有前置條件的，請使用有向箭頭並輔以文字表示。
所謂的條件就是前后端需要判斷的邏輯。常見的條件有3種邏輯結構。
4. 檢查是否犯錯
上面說的幾個常見錯誤，最好檢查一下有沒有犯。
5.得到功能流程圖
根據上面的步驟，我大概畫了一下微信客戶端主要的功能流程圖。
總結
如果你們的產品比較復雜的話，可能需要根據用戶角色、前后端不同來分別畫出對應的功能
流程圖。
比如微信的功能流程圖，至少用戶使用微信，用戶使用小程序，自媒體使用公眾號，開發者開發公眾號，開發者開發小程序等很多個。
簡單來說，你得清楚你們的業務需要多少個產品來支持，產品間的關系是什么，每種產品需要多少種用戶角色，相互間的關系，有多少個端。
三、如何正確的畫出功能邏輯圖
當我們需要設計任務型功能時，除了基礎的線框圖和交互，更需要提前搞清楚整個功能的內部邏輯流程，簡稱功能邏輯圖。
舉幾個大家熟悉的任務型功能作為例子，方便大家理解概念。
比如電商的下單，大概包含查看商品→選擇數量→填寫收貨地址→添加留言→付款。
其中的退貨也是，選擇商品→申請退貨→填寫退貨信息→賣家審批→寄送商品→賣家確認物品無誤→退款到賬。
包括優惠券的使用，是生成訂單前還是訂單后都是有講究的。
為什么需要功能邏輯圖
當需要設計這樣復雜步驟的功能，一定要學會畫出內部的邏輯流程。
當然有時候也需要結合功能結構的思想，先拆分功能盡量少耦合，再畫出內部邏輯。
然后和后端工程師過一遍邏輯，如果沒有問題。再去設計具體的前端頁面，最后才是專注於視覺細節。
如果沒有先產出功能邏輯圖，而是只畫線框圖和交互，那修改迭代的次數至少是上百次。
功能邏輯圖是什么
表現功能內部的邏輯走向。可指導設計具體的頁面和交互。
1. 功能邏輯圖和功能結構圖的區別
注意是功能內部的邏輯流程，不是誤認為是拆分功能。
兩種圖形的使用場景是不一樣的，分析功能的維度是不一樣的。
一般來說先從業務上拆分功能到最細的粒度，然后再去畫功能邏輯圖。有時候最細粒度的功能很簡單，邏輯圖可不畫。
多啰嗦一句，區分這2者也可以使用UML的用例思想來區分。
2.功能邏輯圖和狀態機的區別
通俗意義上的功能邏輯圖表現是行為這個維度以及變化，而狀態機是狀態間的變化，維度是狀態。
3. 功能邏輯圖和UML時序圖的區別
算是時序圖的簡易版吧，UML學起來有一定門檻。但是功能邏輯圖很容易上手，只是欠缺一些uml的特性。
如何畫功能邏輯圖
繼續以電商APP的下單功能為例來講一下如何畫下單這個功能的邏輯圖。
因為這個功能實在是太復雜，不建議一次性畫出邏輯流程。
然后按照子功能分別畫出對應的功能邏輯圖。注意這里只畫了立即購買的下單功能，購物車結算的可以查看加入購物車，加載購物車，展示購物車，操作購物車。
1. 選擇商品
2. 確認訂單
3. 提交訂單
功能邏輯圖的元素
建議使用Axure來畫，因為還支持跳轉到對應的前端線框圖，方便閱讀。
1. 行為
使用矩形框表示，沒可以區分用戶行為和系統行為，uml時序圖中有區分。
2.流程
使用有頭表示行為的流程。
3.判斷條件
使用菱形表示邏輯的多種路線。如果不復雜，可不用。
4.其他文字
用來輔助理解，可忽略。
總結
強調一下不要搞混功能邏輯圖和功能結構圖的運用場景。
我的建議是能拆分就拆分成功能結構，不能拆分就畫功能邏輯。
四、如何正確的畫出頁面流程圖
說到也main流程圖，看似很簡單。但是其實很多人畫的不規范，不能清晰表達產品整體的頁面架構。
頁面流程圖是什么？
頁面流程圖是指產品的所有頁面以及相互間流向關系。
1.包含元素
頁面，有向線條。
可能包含判斷條件。
不包含具體內容。
不包含彈層、元件等視覺組件。
2. 頁面命名
要么是名詞，比如購物車。可加定語，比如我的紅包。
要么是動賓短語，比如確認訂單。
要么是通用叫法，比如我的。
可以參考同行業的top5競品。
盡量保持和原型軟件中頁面結構的命名一致。
3.頁面定位
每個頁面盡量是一個完整獨立的小功能。
除非功能太復雜，需要多個頁面。此時頁面的作用是功能的某一操作。
請結合上述的頁面命名來考慮每一個頁面該如何定位。
4. 維度只有一種
既然是頁面流程圖，那么研究維度只應該有頁面。尤其不應該看到功能和業務。這個錯誤
很多PM都會犯。
延伸一點，每個產品至少有3大架構：業務流程、功能流程、頁面流程。
頁面流程的作用
之所以頁面流程這個東西出現在產品經理的設計工作中，主要有以下原因。
1.了解全局
對於團隊所有人來說，通過頁面流程圖可以大概了解整個app的情況，偏視覺層。
2.傳達需求
對視覺設計師，知道要做多少視覺稿，具體每個頁面都有哪些視覺元素。
對前端工程師，知道自己該寫多少頁面，搭建頁面代碼結構。
3.評估工作量
用頁面數量來評估各自的工作量，可以大概估算出工期。
4. 梳理業務
頁面流程是業務的直接體現，根據業務區反復研究它，可以讓產品整體變得更簡潔，結構變得更優美。
頁面流程不能這樣畫
大部分初級PM畫頁面流程基本會犯兩個錯誤。
1. 只能有頁面這一維度
上面已經說了，再重申一下只應該出現頁面這個維度，不應該有什么亂七八糟的業務、功能、甚至是組件、元件什么的。
2.不應展示具體內容
有些PM把頁面的具體內容表示出來，其實很不對的。
抽象維度不一致，頁面和頁面內容是兩個概念。
畫頁面內容需要耗費很長世間。
頁面內容改動頻率大，需要經常復查並修改。
具體內容有功能、有控件、有圖標、有文字，很難抽象表述，以及表述完全。如果你這樣畫過，你就會理解這里的苦處。
以閃電約app來畫一個錯誤的頁面流程圖，只畫了幾個頁面。供大家參考。至少犯了以上1、
2、4錯誤。
頁面流程圖應該這樣畫
1.找出所有頁面
不管你使用哪款原型軟件，總有他的頁面結構。據此畫出所有的頁面不難。
需要注意的是頁面是物理層面的，真實存在。而不像業務流程圖中的業務模塊，只是邏輯層面
的，並不需要真實體現。
如果你是使用axure,可以直接拖動左方頁面結構中的頁面標題到右邊的畫布中即可。
2. 用有向線條關聯
使用線條將2個頁面聯系起來，直到把所有的頁面跳轉加上為止。
如果你是使用axure，請不要傻乎乎的連接，而是使用連接線模式。
3. 增加條件判斷
這一步不是必須的，但是稍微復雜一些的產品建議使用。
拿上面的錯誤圖來說，首頁和3個頁面有關聯，那什么情況下跳轉到第一個頁面呢。這個就是需要條件判斷來說明。這一點平鋪的UI視覺稿並不能體現這一點PM的價值。
其實，UI視覺稿的平鋪圖可以作為前端工程師定義代碼層面的頁面結構，屬於物理結構。但是邏輯層面的頁面結構必須輔以條件判斷。
重新畫一下上面的頁面流程圖，正確應該如下：
4.檢查是否犯錯
上面說的幾個常見的錯誤，最好檢查一下有沒有犯。
總結
如果是使用axure來畫頁面流程的話，可以全選所有頁面，然后右鍵一鍵生成流程圖。
其實頁面流程圖還需要按照角色（用戶、商家），端（客戶端，服務端），有時候還需要按照版本來畫，根據自身產品的復雜程度，按照此文方法畫出即可。
五、如何正確的畫出業務流程圖
在實際生活中，我們會碰到各種各樣的流程。比如你去醫院看病，你需要先去服務台領個具體要去看病的某個科室的小票，再前往掛號窗口將小票遞給工作人員，繳完掛號費之后拿到掛號單，再前往具體科室去看病。各處都會有自己的流程，按照流程來走可以快速達到目的，減少不必要的麻煩，當然你也可以獨辟蹊徑，這就屬於流程的優化。
流程是為了達到特定的目標而進行的一系列有邏輯性的操作過程，它可以不規范、可以充滿問題，但它確確實實存在着。只要有事情或任務，就會有流程的存在，將有一定規律的流程用圖表表示出來可以讓流程可視化，從而有利於流程的重組優化。
在工作中，我們常用到的流程圖有：業務流程圖、頁面流程圖和數據流程圖。作為產品，經常談的是業務流程圖；作為交互設計師，則比較關心頁面流程圖；而作為系統分析師，數據流程圖最關鍵。
PART1 業務流程圖
圍繞着以下幾個問題來講述業務流程圖
什么是業務流程圖？
為什么需要業務流程圖？
業務流程圖的兩種圖表類型
兩種流程圖圖例和結構
如何繪制業務流程圖？
常見的繪制流程圖的工具
1.業務流程圖是什么？
業務流程圖，顧名思義，用來描述業務流程的一種圖，通過一些特定的符號和連線來表示具體某個業務的實際處理步驟和過程，詳細地描述任務的流程走向，一般沒有數據的概念。
業務流程圖是最常見的圖表之一，能看懂讀懂是必修課，能繪制便是非常重要的選修課。
2.為什么需要業務流程圖？
分析業務流程，並將業務流程圖表化可以幫助分析者了解業務如何運轉，幫助分析者找到業務流程中不合理的流向。現有產品存在的業務流程未必是合理的，通過業務流程圖，鑽研關鍵事件的流程，分析為什么要這么做，探索出更深層次的問題，從而對現有不合理的業務流程進行重組優化，進而制定優化方案，改進現有流程。
產品在寫需求文檔時主要是對業務規則的描述，而配合以業務流程圖可以讓業務邏輯更清晰；日常梳理關鍵事件業務流程時，畫出業務流程圖可以幫助發現不合理流程，從而對關鍵事件進行優化。
3.業務流程圖的兩種圖表類型
（1）管理業務流程圖
我們現在所說的流程圖其實是傳統的管理業務流程圖，包含基本流程圖和跨職能流程圖（泳道圖）兩種。以醫院掛號流程為例。
基本流程圖雖然明確地說明了整個流程，但卻無法清楚地說明每步流程是由哪個角色負責的。為了有效表示各個流程是由誰來負責的，可以通過泳道流程圖來實現，這樣不僅體現了整個活動控制流，還能清楚知道各個角色在流程中所承擔的責任。
管理業務流程圖已基本能滿足業務流程走向的表達，但在復雜的系統交互中，表達並發概念時，傳統的管理業務流程圖已無法表達，這就需要用到UML建模。
（2）UML活動圖
UML中共定義了13種圖，如下，其中用例圖、活動圖和順序圖用的比較多。
UML細分了各種圖，分別在不同的角度來描述系統流程，在本質上，UML各種圖均屬於流程圖。
其中UML中活動圖同管理業務流程圖類似可用於表示業務過程，唯一的區別是活動圖支持並行行為。傳統的流程圖着重描述處理過程，它的主要控制結構是順序、分支和循環，各個處理過程之間有嚴格的順序和時間關系；而UML活動圖描述的是對象活動的順序關系所遵循的規則，它着重表現的是系統的行為，而非系統的處理過程。
那UML活動圖是如何來表示並發業務流程的呢？
UML活動圖也可包含為基本活動圖和泳道活動圖，表達的方式與管理業務流程圖差不多，但圖例上稍有不同（圖例區別可參考下方）。
同管理業務流程圖一樣，泳道讓流程中個角色的分工一目了然。一個泳道表示流程內的一個角色，泳道內僅僅畫出該泳道所表示角色完成的活動（判斷，並行等可以畫在任意泳道）。
總結：管理業務流程圖或UML活動圖均可以用來表達業務流程，具體使用哪種圖來表達業務流程可以憑君喜好，但要遵循一定的符號結構，不要混搭。不過要表達並行行為的還是使用UML活動圖吧。
4.兩種流程圖圖例和結構
（1）管理業務流程圖
管理業務流程圖的常用符號如下，其基本結構包含：順序結構、選擇（分支）結構、循環結構。
（2）UML活動圖
UML活動圖的常用符號如下，其基本結構除了順序結構、選擇（分支）結構和循環結構外，還可能存在並發的事件流。在UML中，可以采用一個同步線來說明這些並行控制流的分岔和匯合。
同步線：分岔是有一個進入轉換，兩個或多個離開轉換；而匯合則是兩個或多個進入轉換，一個離開轉換。
5.如何繪制流程圖？
（1）在開始繪制業務流程圖之前需要先想清楚的2個問題：
1）所要描述的是哪一段業務流程？
在畫流程圖之前先確定業務流程起終點，是截取某一段業務進行詳細描述，還是整體業務模塊進行描述。不可能將所有的流程都放到一個圖里展示，也不可能大而籠統不畫出關鍵事件，要學會划分業務流程范圍，把握粒度。
舉例
還是以醫院掛號看病為例，先掛號再看病。整個流程下來其實可以細分為兩個流程，分別為掛號流程和看病流程；甚至粒度可以再細點，分為取小票流程、掛號流程、繳掛號費流程、排隊看病流程等，但很明顯，單獨分析取小票流程和繳掛號費流程粒度過小，沒有實際意義。
總結：可采用自頂向下，逐層分解的繪制方法。明確你要梳理的業務流程范圍，首先列出流程中的關鍵事件，如醫院掛號看病，掛號流程和看病流程便算是整個流程中的關鍵事件流程；再結合你分析的目的來判斷是否需要再往下層進行分解，如取小票流程、掛號流程、繳掛號費流程、排隊看病流程。如此例，層層向下分解，直到符合你要分析的目的，當目的是為了對某個業務流程進行優化時，則分解到對應流程即可，繪制出流程圖后再進行分析。
2）所要描述的業務流程是否涉及到參與者？
涉及到參與者的業務流程使用泳道圖來描述更簡單明了。
舉例
業務簡要描述：數學老師讓小麗幫忙把講台上的寫了名字的語文課本送給語文老師，語文老師接下后微笑着對小麗說謝謝。
分析：包含了數學老師、小麗、語文老師這三個參與者，此時用泳道流程圖更合適。
（2）問題想明白了之后便可以對業務流程進行梳理，進而分解各個要素。
業務流程圖有4個關鍵要素：執行操作、順序、輸入輸出、規則；要更清楚的描述業務流程可以有參與者這一要素。
執行操作：執行了什么操作
順序：操作產生的順序
輸入輸出：發生操作的原因和結果
規則：操作產生的條件
參與者：誰參與了這個流程，可以是系統、可以是頁面，也可以是用戶
以上個例子為例進行分解：
業務簡要描述：數學老師讓小麗幫忙把講台上的寫了名字的語文課本送給語文老師，語文老師接下后微笑着對小麗說謝謝。
執行操作和順序（含輸入輸出）：請求幫忙、接受幫忙、拿講台上的語文課本、遞交課本、接收課本、道謝
規則：必須是寫了名字的語文課本
參與者：數學老師、小麗、語文老師
以上是明確給出了業務描述，按照步驟基本上便能畫出業務流程圖。在沒有明確給出業務描述的情況下，對業務流程的梳理主要有兩種方式：
1）深入現場調查，由工作人員介紹業務處理過程。
(2）對現有業務流程的優化。
當已經對現有業務流程熟悉時，通過討論和分析，可梳理出業務流程，再通過優化現有流程中不合理的地方，從而給出一個更好的流程來。
（3）流程圖規范
各圖形形狀/字號統一。如果各個圖形形狀大小/字號相差懸殊，這對於理解圖形的人也是一種折磨，對於某個比較重要的流程可以使用顏色來區分其他普通流程（但顏色數量和種類不應太多，以免重點模糊），再在該重要的流程旁加上注釋說明，就能將重點轉達給對方。
流程名用動賓結構，如輸入手機號。
流程均以開始框開始，以結束框結束。
流程圖從左到右、從上到下排列。
流程線盡量不要交叉。
作者：Kince_X
鏈接：https://www.jianshu.com/p/e3ab696653b6
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。