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

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

上兩篇文章發(fā)出后，有朋友們說：“就是介紹點規(guī)則，太教條了，差不多就行了，直接上原型就好！而且資深產(chǎn)品經(jīng)理也這么說。”

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

下面我們就說說，如何通過狀態(tài)圖梳理業(yè)務，指導原型。

案例說明：

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

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

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

一、步驟一：繪制主干的狀態(tài)

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

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

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

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

二、步驟二：進行狀態(tài)的拆合

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

用兩詞表述的狀態(tài)，是要拆分還是合并。

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

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

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

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

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

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

三、步驟三：完善分支的狀態(tài)

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

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

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

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

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

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

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

1. 商家的操作

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

我們的思考如下：

（1）在“開始”狀態(tài)，能不能轉移到其他狀態(tài)？

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

可以發(fā)現(xiàn)，商家新建商品的時候，除了可以將商品保存為草稿外，還可以直接提交信息進行審核，此時狀態(tài)變?yōu)椤耙烟峤唬龑徍恕睜顟B(tài)。因此需要增加轉移連線，從開始直接引線到“已提交，待審核”。

（2）在“草稿”狀態(tài)，能不能轉移到其他狀態(tài)？

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

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

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

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

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

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

2. 審核人的操作

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

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

3. 系統(tǒng)的操作

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

4. 刪除狀態(tài)說明

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

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

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

五、步驟總結

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

步驟一：繪制主干的狀態(tài)。就梳理主干的狀態(tài)，而不用梳理細節(jié)或分支。

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

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

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

以上的就是梳理狀態(tài)圖的步驟總結。

六、后記

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

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

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

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

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

2. 狀態(tài)圖可以指導原型

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

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

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

3. 本文沒有講到的

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

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

其次，本文的狀態(tài)其實和研發(fā)實現(xiàn)還有點不同。

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

作者：擎蒼，《“圖解”產(chǎn)品：產(chǎn)品經(jīng)理業(yè)務設計與UML建?！纷髡撸娞枺簣D解產(chǎn)品設計

本文由 @圖解產(chǎn)品設計 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議