起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識你畫的不是圖，畫的是思路，四步教你繪制大廠標準狀態圖（終結篇）
編輯導語：好的狀態圖能夠幫助我們表達得更加清晰、思考得剛全面，并能夠指導后續原型圖的設計。那么，該如何推廣狀態圖梳理業務，指導原型？作者總結了四個步驟，教你繪制大廠標準狀態圖，幫助你做好原型設計。
這是萬字長文《三步教你繪制大廠標準狀態圖》的第三篇，也是最后一篇——用狀態圖梳理操作。
上兩篇文章發出后，有朋友們說：“就是介紹點規則，太教條了，差不多就行了，直接上原型就好！而且資深產品經理也這么說?！?/p>
雖然可以直接畫原型圖而不畫狀態圖，但狀態圖不是無聊的創造，用狀態圖可以讓表達更清晰、思考更全面，并能指導原型圖的設計，你總不能拿著一堆原型告訴研發你的邏輯吧。
下面我們就說說，如何通過狀態圖梳理業務，指導原型。
案例說明：
我們的案例是電商平臺的商品管理。商品管理本質上是內容管理，內容管理包括：文章管理、短視頻管理、優惠券管理等，也包括我們上文提到的身份認證。這些內容管理的邏輯都是類似的。
對于商品管理，商家可以發布商品，平臺可以審核商品，商家可上架商品。但為了簡化流程，我們只考慮人工審核商品，而不考慮自動審核商品。為了梳理出整個業務，需要以下幾個步驟。
- 步驟一：繪制主干的狀態
- 步驟二：進行狀態的拆合
- 步驟三：完善分支的狀態
- 步驟四：完善角色和操作
一、步驟一：繪制主干的狀態
對于一個商品管理，我們先要考慮主干的狀態，并忽略一些次要的狀態。比如對于商品管理，其主干的狀態如下圖所示。
這個狀態圖很簡單，和我們之前的身份認證的狀態圖很類似，我們只要略微調查，就非常容易梳理出來。
和身份認證狀態圖不同，這里多了一個保存成草稿狀態，加入的原因是商家無法一次編輯完商品信息。商家可先編輯一點保存成草稿，就可留待以后再編輯。
但這個狀態圖的狀態并不全，比如商品已被審核拒絕，商品已被刪除等都沒畫。這些缺失的狀態要在后面來完成。
二、步驟二：進行狀態的拆合
狀態是否存在都是要看業務，上一步我們拆分出了“草稿”狀態就是基于業務的需求。這一步，我們要基于業務進一步完善狀態圖，此時我們可以從上到下看狀態并思考：
用兩詞表述的狀態，是要拆分還是合并。
我們前面說了，一個狀態可用兩個詞表述。當用兩詞描述完了后，就要思考這個狀態是要拆分，還是維持原狀態。
比如，一個商品有“已提交、待審核”狀態，可不可以拆成“已提交”和“待審核”兩個狀態？顯然沒有必要，商家已經提交了信息，自然是要讓平臺立即審核的，也就是“待審核”，沒有必要拆成兩個狀態。
但是一個商品在“已通過，已上架”狀態，就可以考慮拆成“已通過”和“已上架”兩個狀態。如一個團購平臺，其商品多數是定時上架的，比如是半夜12點上架。這個時候，一個團購的商品即使審核通過了，也不能在前臺顯示，而要到了半夜12點再上架。
因此要拆分出“已通過”和“已上架”這兩個狀態。這兩個狀態也可以換個表述，分別為“已通過，待上架”和“已上架，正銷售”，如圖所示。
而再進一步，“已上架，正銷售”是否要拆成兩個狀態呢？仍然可能有必要。因為一些團購的商品，只是顯示在前臺，但未到售賣時間，還是不能進行銷售的，也就是處于“已上架，待銷售”狀態。只有到了開團時間，該商品才會變為“已上架，正銷售”狀態。
雖然“已上架，正銷售”狀態可以拆分成“已上架，待銷售”和“已上架，正銷售”兩個狀態。但是為了說明主要問題，我們認為該業務只有“已上架、正銷售”狀態，并不需要拆出新的狀態了。
三、步驟三：完善分支的狀態
主干狀態梳理完畢后，需要梳理分支狀態。分支狀態的尋找，可通過找和主狀態相反的狀態來獲得，比如：
- 既然審核有“已通過”狀態，就要有“已拒絕”狀態。
- 既然商品有“已上架”狀態，就要有“已下架”狀態，而下架的原因又包括：商家自己主動下架和商品賣光自動下架，即有“下架”和“賣光”狀態。
- 既然商家可以創建一個商品，那么就可以刪除一個商品，即商品有一個“刪除”狀態。
基于以上幾種情況，我們可以抽象出新的狀態，包括：已拒絕、已下架、已賣光和已刪除。加入這幾個狀態的狀態圖如下圖所示。
四、步驟四：完善角色和操作
上面我們把狀態都列全了，下面就要考慮狀態之間的轉移。一個狀態有可能轉移到任何一個狀態，包括轉移回自己。而觸發狀態的轉移可以是任何角色，這個角色可以是商家、審核人和系統等。所以這一步的思考的原則是：
不同的角色能否將當前狀態，轉移到其他狀態和自身。
下面我們就按照這個原則進行思考，我們要分別從商家、審核人和系統這三個角色出發進行思考。
1. 商家的操作
按照上面的原則，我們可以完善商家的所有操作，如下圖所示。為了便于閱讀，所有新增加的操作，都用粗字并加下劃線標記。
我們的思考如下：
（1）在“開始”狀態，能不能轉移到其他狀態？
從商家的角度，從開始狀態進行梳理，通過逐一梳理七個狀態，包括草稿、待審核、已通過、已拒絕、已上架、已下架、已賣光。刪除狀態沒有列出，我們最后單獨說。
可以發現，商家新建商品的時候，除了可以將商品保存為草稿外，還可以直接提交信息進行審核，此時狀態變為“已提交，待審核”狀態。因此需要增加轉移連線，從開始直接引線到“已提交，待審核”。
（2）在“草稿”狀態，能不能轉移到其他狀態？
從商家角度，從“草稿”狀態，再次逐一梳理七個狀態，發現商家除了可以從“草稿”狀態，轉移到“已提交，待審核” 狀態外。還可以在“草稿”狀態下繼續編輯，并再次保存為“草稿”，因此需要在“草稿”狀態下，增加回環轉移連線。
（3）在“已提交，待審核”狀態，能不能轉移到其他狀態？
從商家角度，從“已提交，待審核”狀態，再次逐一梳理七個狀態，發現從“已提交，待審核”可轉移到“草稿”和“已提交，待審核”兩個狀態。其中轉移到“草稿”相當于撤回，而內部再轉移到“已提交，待審核”，是說商家發現商品描述的問題，要修改后再次提交，此時狀態還是“已提交，待審核”。
（4） 在“已拒絕”狀態，能不能轉移到其他狀態？
從商家角度，當一個商品被拒絕商家有兩個選擇。要么修改完內容立即提交，并再次等待審核，即從“已拒絕”到“已提交，待審核”狀態。要么直接修改并保存，相當于撤回到草稿，即從“已拒絕”到“草稿”狀態。
按照同樣的方法，我們可梳理其他狀態的轉移。
2. 審核人的操作
商家的操作梳理完畢后，審核人的操作梳理是一樣的。我們可以梳理出，審核人可以將“已拒絕”轉化成“已通過”，可以將“已通過”轉化成“已拒絕”。從業務角度，畢竟存在誤操作，這樣就要允許審核人修改自己的錯誤。
此外，還有一種特殊的轉化要注意，比如因為平臺出了新規，要打擊假貨，這就需要批量下架商品。此時對于平臺端，要能看到商家的已上架、已下架和已賣光等的所有商品，并進行批量下架操作。而這種情況不同于常規商品的審核，我們不在本狀態圖里體現。
3. 系統的操作
系統也可以改變商品狀態，在本案例中有兩種情況，分別是定時上架和賣光下架，沒有其他的操作的了。
4. 刪除狀態說明
刪除狀態是個特殊狀態，如果為了追求靈活性，可以在任何狀態下刪除該商品。但是有可能會造成誤刪，所以只允許在個別狀態下允許刪除商品。另一方面，如已上架的商品要刪除，通常也沒必要。因此，我們可要求在草稿、下架等狀態下才可刪除商品。
而在狀態圖中，要表達這些轉移將造成連線過多。此時可以在狀態旁邊加備注來說明，即在“草稿和下架狀態下，商家可刪除商品”。
如果為了防止誤刪，則還可以支持回收站。即當商家刪除了商品后自動進入回收站，并設定三個月后該商品就會從回收站中徹底刪除。
五、步驟總結
通過以上幾個步驟我們就能理清狀態圖。思考過程匯總如下：
步驟一：繪制主干的狀態。就梳理主干的狀態，而不用梳理細節或分支。
步驟二：進行狀態的拆合。思考每個狀態是否要拆分或合并，通常應多考慮是否要拆分。
步驟三：完善分支的狀態。通過上面兩步，梳理清楚了主干狀態后，這一步就要考慮分支狀態，比如要考慮除了審核通過，還要有審核拒絕等。
步驟四：完善角色和操作。當梳理完所有狀態后，就要再思考狀態之間如何遷移。此時要從角色和操作兩方面思考。角色包括：商家、審核人和系統，操作是考慮一個狀態能否遷移到其他任意一個狀態。
以上的就是梳理狀態圖的步驟總結。
六、后記
到這里，狀態圖三篇文章就全部寫完了。最后做些補充。
1. 要考慮全面就沒那么輕松
既然業務要考慮全面，就不會那么輕松，你會覺得本文繞來繞去，但這就是產品經理的工作，不能有半點馬虎。
而這種認真可以讓你發現問題，比如在上一篇文章中提到身份審核狀態圖就是有問題的，業務也是跑不通的，身份審核狀態圖如下：
請讀者按上面套路分析問題，本文不再回答。
2. 狀態圖可以指導原型
有基礎的產品人可把商品管理狀態圖轉化成后臺原型，你會發現狀態圖會指導后臺設計。比如商家端，頂部就是顯示狀態圖的狀態，如“待審核，待發布，已賣光等”。
也許你會略做歸類，但核心狀態就是這些，且不多不少。而每個狀態下都有商品，商家對商品的操作正好對應狀態圖中的操作，也是不多不少。
這也是本文開頭說的——狀態圖是可以指導原型的。
3. 本文沒有講到的
通過看《教你繪制大廠標準狀態圖》的三篇文章，基本上就可以掌握狀態圖，但并不是全部。
首先，編輯中狀態的處理、找全狀態的其他方法、上線后重新提交的邏輯等仍需仔細思考。
其次，本文的狀態其實和研發實現還有點不同。
最后，書也不同于網文，書就是講知識，會更具體，更準確。這些內容我都寫在了《圖解產品》這本書中了，本文將不再連載。
作者：擎蒼，《“圖解”產品：產品經理業務設計與UML建?！纷髡?，公眾號：圖解產品設計
本文由 @圖解產品設計 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
不僅如此，使用的表示標準的圖例，會導致大家對行業通用的圖例產生質疑 ，直接信息不互通，感覺還有繼續優化的空間
問題很大，因為你的開始和結束用的是圓形，開始和結束不夠準確，開發人員可能會表示不知道哪里是起點和結束，不如最原始的流程圖
補充一句，大佬的思路很棒，學習了
有一處感覺不太合適：圖里“已拒絕”的數據，客戶修改重新提交，然后進行審核，而不是已拒絕的又審核通過了。
身份信息已通過變更成已拒絕，轉化也寫的客戶點擊審核通過 看的一臉懵逼
“待審核”于“已拒絕”狀態下，修改產品后是保存草稿，還是直接提交。作者的狀態圖處理有點繁瑣。個人建議可以直接弄一條線標注“修改產品信息”，然后指向“開始圓點”即可。
寫的很透徹，很有實際指導意義，????????????
6啊
樓主這個圖是用什么畫的
用的是visio，實戰中可用axure，方便統一維護
感謝分享，思路很棒