起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識產(chǎn)品狀態(tài)設計，看這一篇就夠了
編輯導語：產(chǎn)品狀態(tài)的設計，聽起來彷佛并不難，但是實際上并不簡單。這里面有許多注意事項，需要牢記才能在產(chǎn)品狀態(tài)設計中避免出錯。在這篇文章中，作者回顧了一些基礎知識，并且總結了設計原則和設計流程，希望能對各位讀者有幫助。
在產(chǎn)品設計中，“狀態(tài)”是非常重要的設計點，它看起來很簡單，似乎只要定義好幾個詞就夠了。
但實際上有很多注意要點，稍不留神就會掉坑里的，所以很多同學在梳理的過程中會感覺越理越復雜、越理越混亂。
這一篇我們就來詳細聊聊產(chǎn)品狀態(tài)的設計。
一、基礎知識
1. 狀態(tài)的定義
狀態(tài)是什么？
狀態(tài)是對某一對象一個時間段內(nèi)業(yè)務進展的概括性描述。
我們將這個定義分解一下：
- 某一對象：狀態(tài)是用來描述業(yè)務中一個具體對象的，每個對象的狀態(tài)是獨立的，只屬于它自己；
- 一個時間段：狀態(tài)表示的是一個時間段，而不是一個時間點，它不是一個瞬時動作；
- 業(yè)務進展：狀態(tài)說明的是對象在業(yè)務中的進展；
- 概括性描述：狀態(tài)具有概括性，是對對象的精簡描述。
例如下圖中淘寶的商品訂單狀態(tài)，描述對象是商品訂單，每個狀態(tài)都會持續(xù)一段時間，這些狀態(tài)說明的是商品訂單在流轉過程中的進展，每個狀態(tài)的描述都非常精簡，格式也很統(tǒng)一。
圖1 商品訂單狀態(tài)示例
2. 狀態(tài)的三要素
狀態(tài)是由輸入條件、狀態(tài)描述、終止條件三個要素組成。
圖2 狀態(tài)三要素示例
1）輸入條件
輸入條件是進入這個狀態(tài)的觸發(fā)開關，當條件被滿足，就會執(zhí)行一次狀態(tài)的遷移，即進入此狀態(tài)。如上圖中，“用戶付款成功”后，商品就會進入【待發(fā)貨】狀態(tài)，“用戶付款成功”就是【待發(fā)貨】的輸入條件。
2）狀態(tài)內(nèi)容
即這個狀態(tài)是什么。
3）終止條件
終止條件是這個狀態(tài)結束的開關，當條件滿足時，此狀態(tài)就會終止。如上圖中的“商家發(fā)貨”，就是【待發(fā)貨】狀態(tài)的終止條件。
上一狀態(tài)的終止條件，是下一狀態(tài)的輸入條件，例如下圖中“商家發(fā)貨”是【待發(fā)貨】的終止條件，是下一狀態(tài)【待收貨】的輸入條件。
圖3 終止條件與輸入條件
無論是輸入條件還是終止條件，都包含手動和自動兩種：
- 手動：即需要用戶手動觸發(fā)，如“商家發(fā)貨”，就需要商家手動點擊“發(fā)貨”按鈕，或輸入發(fā)貨單號并手動提交成功，系統(tǒng)才可判斷商品終止了【待發(fā)貨】狀態(tài)，進入【待收貨】；
- 自動：即無需用戶手動操作，系統(tǒng)根據(jù)已設置好的規(guī)則，當規(guī)則滿足后，自動執(zhí)行狀態(tài)遷移。
這兩種類型的條件可同時存在，也可只存在其中一種。如商品從【待收貨】流轉到【待評價】狀態(tài)，既可手動觸發(fā)，又有自動觸發(fā)機制：
- 手動：用戶主動點擊“確認收貨”按鈕；
- 自動：從狀態(tài)流轉到【待收貨】起開始計算，10天后，系統(tǒng)會自動確認收貨，狀態(tài)變更為【待評價】。
我們在設計狀態(tài)流轉時，會盡量減少需要用戶手動觸發(fā)的條件，改為自動觸發(fā)，但很多時候系統(tǒng)無法做到完全自動，有些環(huán)節(jié)只能通過用戶操作來完成。
然鵝，眾所周知，用戶都是懶的，用戶都是上帝。
我們無法強迫每個用戶按照我們的要求去做，只要有需要手動觸發(fā)的條件，就一定會有用戶不主動做，這就會導致后續(xù)流程無法繼續(xù)進行，所以對于狀態(tài)流轉比較重要的節(jié)點，我們大多會采用手動為主，自動為輔。
的原則，即預留一定的時間等待用戶手動操作，當即將到達這個時間時，給予一定的預警提示，如若用戶仍不操作，則在到達時間后由系統(tǒng)自動向更為常見的方向執(zhí)行。
3. 狀態(tài)的作用
狀態(tài)的作用主要有三個。
1）展示進展
向用戶展示此對象的當前進展，以緩解用戶的焦慮，降低內(nèi)心的不確定感，從而提升用戶體驗。
2）便于描述
將對象不同階段進行歸納，便于日常溝通。
3）統(tǒng)一規(guī)則
對于同一角色，一個對象在一個狀態(tài)中的規(guī)則、操作權限是相同的，不應出現(xiàn)狀態(tài)前半段權限是A，后半段是B的情況，這一點無論是對用戶還是開發(fā)都是有意義的。
4. 狀態(tài)流程
將一個對象各個狀態(tài)按時間線串聯(lián)起來，得到的就是這個對象的狀態(tài)流程。
圖4 狀態(tài)流程示例
二、設計原則
1. 完整連貫
一個對象的狀態(tài)是貫穿這個對象整個生命周期的，前后兩個狀態(tài)是緊密銜接的，中間不應出現(xiàn)任何真空時期。
圖5 完整連貫示例
2. 唯一性
唯一性是指一個對象在一個時間點只有一個狀態(tài)，不會同時存在多種同級狀態(tài)，這是很多同學在設計時沒有意識到的一點，其中有兩個場景是大家容易混淆的：
1）父子狀態(tài)
一個對象有父子狀態(tài)是比較常見的場景，例如前文提到的【待收貨】，是一個比較籠統(tǒng)的父狀態(tài)，它其實包含了【已攬件】、【運輸中】、【派送中】、【待取件】多個子狀態(tài)。
圖6 待收貨的子狀態(tài)
定義父子狀態(tài)的目的，是因為有時候子狀態(tài)過多，在向用戶展現(xiàn)時不方便，這時就可以將幾個相近的子狀態(tài)歸納為一個父狀態(tài)，并以父狀態(tài)展示給用戶。
在這類場景中，有的同學可能就會認為這個商品訂單在一個時間點同時有兩個狀態(tài)，但實際上商品訂單是以子狀態(tài)來流轉的，所以訂單的真實狀態(tài)是子狀態(tài)，父狀態(tài)只是套的一層殼。
2）多名稱
多名稱是另一個容易混淆的場景，因為有的同學會把多個名稱誤以為多個狀態(tài)。
買家收到商品后，訂單就應該從【待收貨】向下一狀態(tài)轉移，這時我們有【已收貨】、【待評價】兩個名稱可以用，內(nèi)涵也是一樣的。在這類場景中，雖然叫法不同，但其實還是同一個狀態(tài)。
3. 區(qū)分視角
雖然一個對象在一個時間點只有一個狀態(tài)，但不代表只有一個名稱。
在實際狀態(tài)設計中，為了讓不同角色的用戶更好的理解一個狀態(tài)的含義，有時即使是同一狀態(tài)，針對不同角色用戶也會使用不同名稱。
4. 統(tǒng)一規(guī)則
前面提到，定義狀態(tài)很重要的一個作用是為了統(tǒng)一這個狀態(tài)下對象的規(guī)則，但要想達到這一目的，就得在設計對象狀態(tài)時遵守這一原則。
5. 粒度適中
很多同學在梳理對象狀態(tài)時，隨著對流程的細化，會發(fā)現(xiàn)這些狀態(tài)越理越細、越理越多，感覺這里可以加個狀態(tài)，那里也可以加個狀態(tài)，最后導致這一對象的狀態(tài)特別多，狀態(tài)流特別復雜，徒增用戶理解和實現(xiàn)成本。
我們在定義對象狀態(tài)時，在滿足前面原則的前提下，應盡量減少引入更多的狀態(tài)，控制狀態(tài)粒度。
6. 通俗易懂
狀態(tài)名稱需要精煉的表達出對象當前階段的核心進展，并容易被大家所理解，如果實在找不到合適的通俗易懂的詞，就要在狀態(tài)旁邊做好說明。
7. 與業(yè)務流同向
在狀態(tài)的定義中，我們強調(diào)了狀態(tài)描述的是業(yè)務進展，這里包含的另一層意思是狀態(tài)流程其實是對業(yè)務流程的概括，狀態(tài)流是在業(yè)務流程的基礎上總結出來的。
所以狀態(tài)流程與業(yè)務流程一定是同向的，即這個對象在業(yè)務上如何流轉，它的狀態(tài)就會以同樣的方向流轉。
三、設計流程
1. 第一步：梳理操作流程
在設計原則2.7中，我介紹了狀態(tài)流程與業(yè)務流程的關系，那我們是不是有了業(yè)務流程就能梳理出狀態(tài)流程呢？
答案當然是否定的，不然我為什么要問呢。
業(yè)務流程之所以不能幫助我們梳理出狀態(tài)流程，是因為業(yè)務流程只能幫我們提煉出狀態(tài)三要素中的“狀態(tài)描述”，無法幫助我們精準的確定另外兩個要素——“輸入條件”和“終止條件”。
大家都知道，在代碼實現(xiàn)中，狀態(tài)要想在系統(tǒng)中流轉，需要精確的指令才能進行下一步，這些指令就是狀態(tài)的“輸入條件”和“終止條件”，而業(yè)務流程的粒度顯然無法滿足系統(tǒng)對“精確”的要求，例如商品流轉的業(yè)務流程是：
圖7 業(yè)務流程示例
在這個流程中，系統(tǒng)無法知道什么算“商家發(fā)貨”、什么叫“物流配送”。
所以業(yè)務流程無法直接指導系統(tǒng)進行狀態(tài)流轉，這時就需要我們梳理出對象在系統(tǒng)中的操作流程，通過系統(tǒng)中明確的操作或業(yè)務規(guī)則來向系統(tǒng)發(fā)出精準指令。
圖8 操作流程示例（過程做了大量簡化）
在這個操作流程中，對于系統(tǒng)自動處理的部分，可以通過增加一個名為“系統(tǒng)”的泳道，來體現(xiàn)系統(tǒng)自動完成的操作。
雖然狀態(tài)流程是在操作流程的基礎上梳理的，但操作流程卻是在業(yè)務流程的基礎上細化出來的，所以業(yè)務流程也是很重要的（要充分理解這一步，需要先理解業(yè)務流程和操作流程的含義和區(qū)別，不過這要扯很久，也偏題了，所以關于各種流程的介紹我們擇日再聊）。
2. 第二步：歸納狀態(tài)
在梳理的操作流程基礎上，我們再依據(jù)前面提到的設計原則，提煉、總結出此對象的各個狀態(tài)。
同樣的，歸納狀態(tài)時要明確狀態(tài)的三個要素分別是什么。
3. 第三步：梳理狀態(tài)流程
有了第二步梳理的各個狀態(tài)，順著操作流程的方向，就能得到我們的狀態(tài)流程了。為了溝通更方便，表達更清晰，狀態(tài)流程圖就是必不可少的，一般的狀態(tài)流程圖有三種表現(xiàn)形式。
1）純狀態(tài)流轉
即流程圖中僅體現(xiàn)狀態(tài)的流轉，不展示其他信息，如下圖所示。
圖9 純狀態(tài)流程圖
這種形式很簡單、干凈，適用于向業(yè)務方、上級領導等不需要了解細節(jié)的關聯(lián)方匯報，但對于開發(fā)同學來說肯定是不夠的，這時就得采用后面兩種形式了。
2）與操作流程結合
既然狀態(tài)流程是在操作流程的基礎上梳理的，這就說明這兩個流程其實是可以合并處理的。
圖10 狀態(tài)流程與操作流程合并
如上圖所示，在狀態(tài)輸入條件后展現(xiàn)狀態(tài)名稱，到下一狀態(tài)開始前，中間過程均為屬于此狀態(tài)。
這種形式在操作流程較短時比較方便，可以用一張圖體現(xiàn)兩個流程，但當操作流程較長時，這張圖的可讀性就比較差了，不同信息間會產(chǎn)生干擾，這時就推薦用第三種方式了。
3）僅體現(xiàn)狀態(tài)三要素
圖11 僅展示狀態(tài)三要素
如上圖所示，這種形式是在上一形式的基礎上，去掉中間無關操作，僅保留狀態(tài)的三要素，這樣既可以滿足開發(fā)同學對觸發(fā)條件明確的要求，也方便進行講解匯報。
4. 第四步：整理狀態(tài)定義表
如果整個狀態(tài)及流程容易理解，這一步可以省略，但如果定義的狀態(tài)和相應規(guī)則比較復雜，那最好整理一張狀態(tài)表來說明各個狀態(tài)的要素、具體含義和相應規(guī)則，以便統(tǒng)一各方認識。
表1 狀態(tài)定義表模板
四、關聯(lián)對象的狀態(tài)設計
大多數(shù)情況下，能夠梳理清楚業(yè)務流程和操作流程，清晰準確的定義狀態(tài)三要素，那狀態(tài)設計基本就不會有什么問題了。
不過在狀態(tài)設計中有一類場景會稍微復雜一些——關聯(lián)對象的狀態(tài)關系如何處理。
這里的關聯(lián)對象，是指兩個流程進展上相互有影響的對象，例如父子訂單，父訂單的流程進展受子訂單的影響。
舉個具體例子，在某個需求管理工具中，假設需求的狀態(tài)流程為：待處理——開發(fā)中——測試中——已完成。
這時小明創(chuàng)建了一個需求，同時在這個需求基礎上拆分了兩個子需求，那么父子需求的狀態(tài)關系應該怎么處理呢？這里有幾個常見的處理原則。
1. 一個對象僅有一個狀態(tài)
父子對象雖然在業(yè)務上有父子關系，但各自狀態(tài)是完全獨立的，無論是業(yè)務角度還是實現(xiàn)角度都是這樣，即便兩者可能某些狀態(tài)的命名都一樣，但在邏輯上必須是互相獨立。
所以雖然狀態(tài)名稱相同，但實際是不同的對象，實質(zhì)是不同的。
2. 狀態(tài)關系與對象流程關系相同
既然兩個對象在流程上已經(jīng)相互影響了，那么狀態(tài)上也會存在一定的邏輯關系，因為狀態(tài)流程是建立在對象業(yè)務（或操作）流程基礎上，常見的幾類關系有：
1）包含關系
即一個對象在多個狀態(tài)間流轉時，另一對象看到的仍是一個狀態(tài)。
例如商品消費訂單和這個商品的配送訂單，就是一對父子關系，消費者看到的消費訂單是【配送中】，但配送訂單可能會經(jīng)過【分揀中】、【運輸中】等等很多狀態(tài)，這就是狀態(tài)的包含關系。
而之所以狀態(tài)是包含關系，是因為這兩個流程是包含關系，商品配送流程可以看作是商品完整流程中的子流程；
2）銜接關系
即一個對象先到某個狀態(tài)，另一事項才會到某個狀態(tài)。例如需求要想進入【已完成】狀態(tài)，需要子任務進入【已完成】，父任務才允許【已完成】。
3）完全同步
即兩個對象的狀態(tài)是同步的，一個對象隨另一對象狀態(tài)變更而變更。
那有的同學會問了，在很多需求管理工具中，雖然父子需求存在父子關系，但為什么他們的狀態(tài)是完全獨立，相互之間不影響呢？
這其實也是體現(xiàn)了這一原則，因為在這些工具的定義中，父子需求的流程上相互沒有影響，所以雖然他們存在邏輯關系，但相互間狀態(tài)不影響。
到這里，關于產(chǎn)品狀態(tài)的設計就介紹完了，如果各位讀者朋友覺得寫得還有點用，記得加我微信一起交流哦~~
作者：周翔；公眾號：周翔Fly；個人微信：zhouxiangxgg
本文由 @周翔 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。
題圖來自 Unsplash，基于CC0協(xié)議。
我有一個問題，我的對象是任務，任務區(qū)分了父任務和子任務；子任務的狀態(tài)：待開始、進行中、已達成、未達成、已取消；但是父任務狀態(tài)：待分配、分配中（年度任務被拆季度，可以多次分配）、已分配、進行中、已達成、未達成，父任務的狀態(tài)：分配中和進行中會出現(xiàn)同時存在；那是不是我的狀態(tài)區(qū)分就不合理？應該區(qū)分為分配狀態(tài)、和進度狀態(tài)，兩個狀態(tài)來描述父任務？
狀態(tài)是唯一的，不要出現(xiàn)一個時間點多個狀態(tài)的情況，需要定義更細致清楚一些，否則后面很多跟狀態(tài)關聯(lián)的各種邏輯就扯不清
父子任務狀態(tài)映射關系要定義好，畫個父子狀態(tài)關系圖就清楚了
我的新書《不枯燥的B端產(chǎn)品實戰(zhàn)課》已上線，更多干貨盡在書里，京東地址：https://item.jd.com/12786741.html
是不是沒有同一個對象，不同角色有不同數(shù)量的狀態(tài)。
您好，同一個單據(jù)對于不同角色可以不同狀態(tài)嗎？涉及角色有5個？頭疼中。。。。
狀態(tài)是同一個，名稱可以不同，一個對象一個時間點只有一個狀態(tài)，這個原則一定要守住。之前也有讀者遇到過類似的問題，我給的另一個建議是：盡量用通用的名稱，不要用「待我評審」之類個性化表達，這樣定義狀態(tài)名稱會更簡單
較難掌握的其實是異常流程的狀態(tài)。
這個關鍵還是要把異常流程梳理清楚，狀態(tài)基于流程
為什么要把訂單狀態(tài)跟物流狀態(tài)混到一塊兒呢
物流的對象也是商品，所以從商品大流程上看，這些狀態(tài)都是對商品的
問題：電商系統(tǒng)中，訂單狀態(tài)和物流狀態(tài)在數(shù)據(jù)庫中是一個字段嗎
ChatGPT：在通常情況下，訂單狀態(tài)和物流狀態(tài)在電商系統(tǒng)的數(shù)據(jù)庫中是不同的字段。
訂單狀態(tài)是指訂單在整個交易過程中所處的狀態(tài)，例如”待付款”、”已支付”、”已發(fā)貨”、”已完成”等。這些狀態(tài)用于表示訂單的進展情況和當前狀態(tài)。
物流狀態(tài)是指訂單對應的物流信息的狀態(tài)，例如”已攬收”、”運輸中”、”派送中”、”已簽收”等。這些狀態(tài)用于跟蹤訂單的物流進程和最新狀態(tài)。
在數(shù)據(jù)庫中，通常會創(chuàng)建兩個獨立的字段來分別表示訂單狀態(tài)和物流狀態(tài)，以便于查詢和管理。這樣可以更好地對訂單和物流進行跟蹤和管理，并提供準確的狀態(tài)信息給用戶。