編輯導語：好的狀態圖能夠幫助我們表達得更加清晰、思考得剛全面，并能夠指導后續原型圖的設計。那么，該如何推廣狀態圖梳理業務，指導原型？作者總結了四個步驟，教你繪制大廠標準狀態圖，幫助你做好原型設計。

這是萬字長文《三步教你繪制大廠標準狀態圖》的第三篇，也是最后一篇——用狀態圖梳理操作。

上兩篇文章發出后，有朋友們說：“就是介紹點規則，太教條了，差不多就行了，直接上原型就好！而且資深產品經理也這么說?！?/p>

雖然可以直接畫原型圖而不畫狀態圖，但狀態圖不是無聊的創造，用狀態圖可以讓表達更清晰、思考更全面，并能指導原型圖的設計，你總不能拿著一堆原型告訴研發你的邏輯吧。

下面我們就說說，如何通過狀態圖梳理業務，指導原型。

案例說明：

我們的案例是電商平臺的商品管理。商品管理本質上是內容管理，內容管理包括：文章管理、短視頻管理、優惠券管理等，也包括我們上文提到的身份認證。這些內容管理的邏輯都是類似的。

對于商品管理，商家可以發布商品，平臺可以審核商品，商家可上架商品。但為了簡化流程，我們只考慮人工審核商品，而不考慮自動審核商品。為了梳理出整個業務，需要以下幾個步驟。

1. 步驟一：繪制主干的狀態
2. 步驟二：進行狀態的拆合
3. 步驟三：完善分支的狀態
4. 步驟四：完善角色和操作

一、步驟一：繪制主干的狀態

對于一個商品管理，我們先要考慮主干的狀態，并忽略一些次要的狀態。比如對于商品管理，其主干的狀態如下圖所示。

這個狀態圖很簡單，和我們之前的身份認證的狀態圖很類似，我們只要略微調查，就非常容易梳理出來。

和身份認證狀態圖不同，這里多了一個保存成草稿狀態，加入的原因是商家無法一次編輯完商品信息。商家可先編輯一點保存成草稿，就可留待以后再編輯。

但這個狀態圖的狀態并不全，比如商品已被審核拒絕，商品已被刪除等都沒畫。這些缺失的狀態要在后面來完成。

二、步驟二：進行狀態的拆合

狀態是否存在都是要看業務，上一步我們拆分出了“草稿”狀態就是基于業務的需求。這一步，我們要基于業務進一步完善狀態圖，此時我們可以從上到下看狀態并思考：

用兩詞表述的狀態，是要拆分還是合并。

我們前面說了，一個狀態可用兩個詞表述。當用兩詞描述完了后，就要思考這個狀態是要拆分，還是維持原狀態。

比如，一個商品有“已提交、待審核”狀態，可不可以拆成“已提交”和“待審核”兩個狀態？顯然沒有必要，商家已經提交了信息，自然是要讓平臺立即審核的，也就是“待審核”，沒有必要拆成兩個狀態。

但是一個商品在“已通過，已上架”狀態，就可以考慮拆成“已通過”和“已上架”兩個狀態。如一個團購平臺，其商品多數是定時上架的，比如是半夜12點上架。這個時候，一個團購的商品即使審核通過了，也不能在前臺顯示，而要到了半夜12點再上架。

因此要拆分出“已通過”和“已上架”這兩個狀態。這兩個狀態也可以換個表述，分別為“已通過，待上架”和“已上架，正銷售”，如圖所示。

而再進一步，“已上架，正銷售”是否要拆成兩個狀態呢？仍然可能有必要。因為一些團購的商品，只是顯示在前臺，但未到售賣時間，還是不能進行銷售的，也就是處于“已上架，待銷售”狀態。只有到了開團時間，該商品才會變為“已上架，正銷售”狀態。

雖然“已上架，正銷售”狀態可以拆分成“已上架，待銷售”和“已上架，正銷售”兩個狀態。但是為了說明主要問題，我們認為該業務只有“已上架、正銷售”狀態，并不需要拆出新的狀態了。

三、步驟三：完善分支的狀態

主干狀態梳理完畢后，需要梳理分支狀態。分支狀態的尋找，可通過找和主狀態相反的狀態來獲得，比如：

• 既然審核有“已通過”狀態，就要有“已拒絕”狀態。
• 既然商品有“已上架”狀態，就要有“已下架”狀態，而下架的原因又包括：商家自己主動下架和商品賣光自動下架，即有“下架”和“賣光”狀態。
• 既然商家可以創建一個商品，那么就可以刪除一個商品，即商品有一個“刪除”狀態。

基于以上幾種情況，我們可以抽象出新的狀態，包括：已拒絕、已下架、已賣光和已刪除。加入這幾個狀態的狀態圖如下圖所示。

四、步驟四：完善角色和操作

上面我們把狀態都列全了，下面就要考慮狀態之間的轉移。一個狀態有可能轉移到任何一個狀態，包括轉移回自己。而觸發狀態的轉移可以是任何角色，這個角色可以是商家、審核人和系統等。所以這一步的思考的原則是：

不同的角色能否將當前狀態，轉移到其他狀態和自身。

下面我們就按照這個原則進行思考，我們要分別從商家、審核人和系統這三個角色出發進行思考。

1. 商家的操作

按照上面的原則，我們可以完善商家的所有操作，如下圖所示。為了便于閱讀，所有新增加的操作，都用粗字并加下劃線標記。

我們的思考如下：

（1）在“開始”狀態，能不能轉移到其他狀態？

從商家的角度，從開始狀態進行梳理，通過逐一梳理七個狀態，包括草稿、待審核、已通過、已拒絕、已上架、已下架、已賣光。刪除狀態沒有列出，我們最后單獨說。

可以發現，商家新建商品的時候，除了可以將商品保存為草稿外，還可以直接提交信息進行審核，此時狀態變為“已提交，待審核”狀態。因此需要增加轉移連線，從開始直接引線到“已提交，待審核”。

（2）在“草稿”狀態，能不能轉移到其他狀態？

從商家角度，從“草稿”狀態，再次逐一梳理七個狀態，發現商家除了可以從“草稿”狀態，轉移到“已提交，待審核” 狀態外。還可以在“草稿”狀態下繼續編輯，并再次保存為“草稿”，因此需要在“草稿”狀態下，增加回環轉移連線。

（3）在“已提交，待審核”狀態，能不能轉移到其他狀態？

從商家角度，從“已提交，待審核”狀態，再次逐一梳理七個狀態，發現從“已提交，待審核”可轉移到“草稿”和“已提交，待審核”兩個狀態。其中轉移到“草稿”相當于撤回，而內部再轉移到“已提交，待審核”，是說商家發現商品描述的問題，要修改后再次提交，此時狀態還是“已提交，待審核”。

（4） 在“已拒絕”狀態，能不能轉移到其他狀態？

從商家角度，當一個商品被拒絕商家有兩個選擇。要么修改完內容立即提交，并再次等待審核，即從“已拒絕”到“已提交，待審核”狀態。要么直接修改并保存，相當于撤回到草稿，即從“已拒絕”到“草稿”狀態。

按照同樣的方法，我們可梳理其他狀態的轉移。

2. 審核人的操作

商家的操作梳理完畢后，審核人的操作梳理是一樣的。我們可以梳理出，審核人可以將“已拒絕”轉化成“已通過”，可以將“已通過”轉化成“已拒絕”。從業務角度，畢竟存在誤操作，這樣就要允許審核人修改自己的錯誤。

此外，還有一種特殊的轉化要注意，比如因為平臺出了新規，要打擊假貨，這就需要批量下架商品。此時對于平臺端，要能看到商家的已上架、已下架和已賣光等的所有商品，并進行批量下架操作。而這種情況不同于常規商品的審核，我們不在本狀態圖里體現。

3. 系統的操作

系統也可以改變商品狀態，在本案例中有兩種情況，分別是定時上架和賣光下架，沒有其他的操作的了。

4. 刪除狀態說明

刪除狀態是個特殊狀態，如果為了追求靈活性，可以在任何狀態下刪除該商品。但是有可能會造成誤刪，所以只允許在個別狀態下允許刪除商品。另一方面，如已上架的商品要刪除，通常也沒必要。因此，我們可要求在草稿、下架等狀態下才可刪除商品。

而在狀態圖中，要表達這些轉移將造成連線過多。此時可以在狀態旁邊加備注來說明，即在“草稿和下架狀態下，商家可刪除商品”。

如果為了防止誤刪，則還可以支持回收站。即當商家刪除了商品后自動進入回收站，并設定三個月后該商品就會從回收站中徹底刪除。

五、步驟總結

通過以上幾個步驟我們就能理清狀態圖。思考過程匯總如下：

步驟一：繪制主干的狀態。就梳理主干的狀態，而不用梳理細節或分支。

步驟二：進行狀態的拆合。思考每個狀態是否要拆分或合并，通常應多考慮是否要拆分。

步驟三：完善分支的狀態。通過上面兩步，梳理清楚了主干狀態后，這一步就要考慮分支狀態，比如要考慮除了審核通過，還要有審核拒絕等。

步驟四：完善角色和操作。當梳理完所有狀態后，就要再思考狀態之間如何遷移。此時要從角色和操作兩方面思考。角色包括：商家、審核人和系統，操作是考慮一個狀態能否遷移到其他任意一個狀態。

以上的就是梳理狀態圖的步驟總結。

六、后記

到這里，狀態圖三篇文章就全部寫完了。最后做些補充。

1. 要考慮全面就沒那么輕松

既然業務要考慮全面，就不會那么輕松，你會覺得本文繞來繞去，但這就是產品經理的工作，不能有半點馬虎。

而這種認真可以讓你發現問題，比如在上一篇文章中提到身份審核狀態圖就是有問題的，業務也是跑不通的，身份審核狀態圖如下：

請讀者按上面套路分析問題，本文不再回答。

2. 狀態圖可以指導原型

有基礎的產品人可把商品管理狀態圖轉化成后臺原型，你會發現狀態圖會指導后臺設計。比如商家端，頂部就是顯示狀態圖的狀態，如“待審核，待發布，已賣光等”。

也許你會略做歸類，但核心狀態就是這些，且不多不少。而每個狀態下都有商品，商家對商品的操作正好對應狀態圖中的操作，也是不多不少。

這也是本文開頭說的——狀態圖是可以指導原型的。

3. 本文沒有講到的

通過看《教你繪制大廠標準狀態圖》的三篇文章，基本上就可以掌握狀態圖，但并不是全部。

首先，編輯中狀態的處理、找全狀態的其他方法、上線后重新提交的邏輯等仍需仔細思考。

其次，本文的狀態其實和研發實現還有點不同。

最后，書也不同于網文，書就是講知識，會更具體，更準確。這些內容我都寫在了《圖解產品》這本書中了，本文將不再連載。

作者：擎蒼，《“圖解”產品：產品經理業務設計與UML建?！纷髡?，公眾號：圖解產品設計

本文由 @圖解產品設計 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議