編輯導語：狀態圖表述了一個對象所處的狀態，以及導致該對象狀態轉變的操作鏈條，是產品經理工作中常接觸到的事物。那么，狀態圖應該如何繪制？狀態圖和流程圖又有什么區別？本篇文章里，作者就狀態圖的繪制策略等方面做了總結，不妨來看一下。

本文是萬字長文《三步教你繪制大廠標準狀態圖》系列文章的第二篇——狀態圖的誤區。

第一篇文章是說狀態圖的繪制標準，其中提到高級產品經理畫的「產品經理工作狀態圖」問題很多，該圖既沒搞清楚目的，更沒搞清楚概念和畫法，總之錯誤很多，畫這樣的狀態圖是會被研發打的。本文就來分析分析這類圖的問題，順便也說說狀態圖和流程圖的區別。

一、狀態圖的問題

狀態圖如果畫錯，其實就是沒有理解第一篇文章中講到的狀態圖的概念和畫法，要閱讀上文請「點擊這里」。下面我們就依據標準說說狀態圖的常見問題。

1. 有對象才有狀態

狀態是針對一個實際存在的事務而言的，這個事務就是一個對象，只有有了對象才有了狀態。這是再自然不過的了，然而很多人卻忽略了這個常識。

下面我們先說說對象是什么，再說問題所在。

簡單地說，一個對象就是一個實際存在的事務。這個事務可以是某家的微波爐或某人的身份認證信息。而一個對象（一個事務）就會有若干狀態，并且只有有了對象才有狀態。比如，這臺微波爐的狀態是已關閉，這個身份認證狀態是已審核通過，無論是微波爐還是身份認證都是實際存在的。

但卻有人在身份審核狀態圖中，加入“已新建”這個狀態。如下圖所示，這是錯誤的！

因為用戶“單擊新建申請”這個操作，是不會產生“已新建”狀態的，這就是打開了身份審核的界面而已。如果用戶單擊關閉，系統不會保留該信息，也就是說這個對象不會被創建。對象不存在，那么“已新建”狀態就是不存在的。

但凡事都不絕對，如果設計的系統是：只要用戶單擊進行身份認證，且用戶填寫了一點內容，就將信息保存成草稿，是會存在“草稿”狀態的。保存成草稿后，用戶退出后再次回來，還可看上次的信息，這時加入“草稿”狀態就有必要。

通常，只有要填寫的內容較多的時候，才會有草稿狀態。有了這個狀態，就能避免出現用戶一次填不完信息，又保存不了的問題。

2. 表達“一個”對象

狀態圖是用來表達對象的狀態。并且，狀態只能表達“一個對象”的狀態，這也是很自然的。

比如，我們不能在一個狀態圖中，同時表達商品和訂單的狀態。如何畫呢？我們根本無法在一個圖中畫出來。訂單有“已發貨狀態”，這和這個商品是否下架沒關系，而“商品已下架”就是商品的狀態。

因此，為避免一個狀態圖中表達兩個對象，我們建議在狀態圖中都寫上對象名。如在身份審核狀態圖中，在每個狀態名中都加入“身份信息”這個對象名。

雖然在狀態中重復寫了對象名，但是卻好處很多。比如我們在上一篇中提到的「產品經理的工作狀態圖」如下。

這個圖的問題就是把多個對象放在了一個狀態圖中，其實這個狀態圖有兩個對象。分別是：需求和身體。

首先，產品經理提交的需求就是一個對象。需求的狀態有已提交、已拒絕和已通過。這樣就可抽象出一個需求管理系統，該系統用來管理需求文檔。

其次，產品經理的身體是另一個對象。身體的狀態可以是健康、生病和死亡，這樣就可抽象一個醫院管理系統。

比如身體狀態是重傷，就不要掛號了，而是直接住進ICU；但如果是輕傷狀態，就要排隊掛號等待就診；如果很不幸，是死亡狀態，那么也不用看病了，要直接進入太平間。

而如果把需求和文檔畫在一個圖里，意義在哪里呢？沒有任何意義。我們只是看到了一個邏輯混亂，讓研發鄙視的產品經理。

產品經理即使生病也可以提交需求，即使不生病也可以不提交需求，生不生病和提交不提交需求就是兩件事，混在一起就錯了。

3. 不可有判斷標志

在有的書中狀態圖可加菱形的“判斷標志”，但不是主流，本人也不建議加入。因為不加“判斷標志”表達會更簡潔和無歧義。而回顧身份審核的狀態圖，如果加入菱形的“判斷標志”，就如下圖所示。

雖然加上判斷標志也說的過去，但不加也一樣能讓人明白，并且是非常簡潔的。但加入判斷標識后，狀態圖的表達就很混亂了。

比如在“身份信息已提交狀態”和“客服判斷身份證信息”之間的連線上，要畫什么操作呢？我們發現不好說明。

以上，就是狀態圖的三個常見誤區。你只要牢記這三個點，就能保證畫出來的狀態圖是正確的，請大家務必牢記！

二、狀態圖和流程圖的區別

有一些朋友們可能會問，狀態圖和流程圖有什么不同？下面我們就來說說這個問題。

其實，狀態圖和流程圖都是在表達一個事務的動態行為，只是在從不同的角度來表達。狀態圖是以狀態為核心表達，流程圖是以活動（或稱動作）為核心表達。

我們再回到身份審核流程，我們分別列出身份審核的狀態圖和流程圖。

從上面的兩張圖中，我們可以看到下面兩個區別。

1. 內容上的區別

狀態圖圈起來的是狀態，如“身份信息已提交”狀態。而流程圖圈起來的是活動，如“用戶提交身份信息”活動。在UML體系中，狀態圖括起來的是狀態，那么就是狀態圖。而流程圖括起來的是活動，那么就是活動圖。

在狀態圖在轉移的線上寫的內容，恰恰對應的是活動圖的活動，如“用戶提交審核信息”，兩者的內容基本等價。而對于流程圖轉移的線上通常不寫內容，只是在進行判斷的時候，要在線上寫上判斷的條件。

2. 使用上的區別

狀態圖和流程圖的區別如此，但是什么時候畫流程圖，什么時候畫狀態圖？概括地說就是——流程多就畫流程圖，狀態多就畫狀態圖，都多就都畫。依據這個原則，我們看看相關情況。

1）需要畫流程圖的情況

訂單流程和登錄注冊流程等，都需要畫流程圖。顯然這些都屬于可以畫若干步的流程圖。其流程挺多，可以通過畫流程圖理順個人思路。比如訂單流程，可以表達從用戶下單、到商家接單、物流送貨等流程，大家可以畫一畫仔細體會一下。

但是“商品管理”就可以不畫。因為就是兩三個單一頁面，也沒有什么判斷，流程也非常簡單。如果要畫，無非是商品發布、商家審核、審核通過發布。

2）需要畫狀態圖的情況

身份審核、訂單流程、商品審核、優惠券領取和使用等都可以畫狀態圖。在這些流程中每個對象都有很多狀態，而通過狀態圖就能知道不同狀態下的不同操作。比如商品狀態有：待審核，已審核，已發布，已下架，已賣光等。

但是“用戶登錄”就不需要畫狀態圖，因為登錄流程中沒有什么狀態，如果要畫就是已登錄，未登錄等幾個狀態。

以上，列出了常見的需要畫狀態圖和流程圖的情況。概括一下就是：流程多就畫流程圖，狀態多就畫狀態圖，如果流程和狀態都多，就都要畫。

三、狀態圖和流程圖的配合

通過上面的案例，我們發現訂單流程既需要畫流程圖，又需要畫狀態圖，此時我們就要考慮兩個圖如何配合。

通常先畫流程圖再畫狀態圖，用流程圖梳理大致流程，用狀態圖梳理細致操作。

比如訂單的流程，就要先用流程圖來梳理下單、退貨和評價等流程，但是發現其中下單和退貨流程又都涉及到了很多的狀態，這就要進一步畫狀態圖。如何通過狀態圖梳理細致操作，我們下一篇會講。

最后，什么時候畫狀態圖？什么時候畫流程圖？其分界線并不絕對。建議對于初學者可都畫一遍，如果覺得該圖意義不大，那么下次就可以不畫。

四、寫在最后

到這里本文就講完了。雖然就是在講概念，但卻能讓你畫的圖不出錯，這就已經能超越很多產品經理了，而你需要做的是認認真真看幾篇文章。

畫的狀態圖不出錯是基礎，但另一方面，也是更重要的是——我們要通過狀態圖把業務考慮全。

其實我畫的「身份審核狀態圖」就沒把業務考慮全。如果把這個圖給研發還是會被打的，不僅會被研發打，運營也會打，用戶也會打。因為這個業務根本就跑不通。

所以下一篇我們就講如何把業務考慮周全，從而做一個不被研發打的優秀的產品經理！

學習提示

曾經有學習群里的產品經理說：“按照這個標準畫狀態圖后，連研發都說我精進了不少，但以前不重視這些基礎，結果畫的圖就總有問題，研發總說我思路不清?！?/p>

是的！學習不是看你學了多少，而是看你是否真的掌握了，尤其是掌握這些基礎知識！扎扎實實學好基礎，比什么都重要！

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

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

題圖來自Unsplash，基于CC0協議