在產(chǎn)品設(shè)計中，狀態(tài)管理是產(chǎn)品經(jīng)理不可或缺的技能之一，尤其是在處理復(fù)雜業(yè)務(wù)流程時。本文作為產(chǎn)品實操系列的一部分，聚焦于如何通過狀態(tài)機的概念來優(yōu)化產(chǎn)品設(shè)計。

今天，針對產(chǎn)品經(jīng)理的后端設(shè)計，我們繼續(xù)講講實操內(nèi)容。

如同我上次說過的，流程、信息結(jié)構(gòu)、狀態(tài)、策略，算是產(chǎn)品經(jīng)理進行后端設(shè)計的四個組成部分。

今天我們進展到了第三個。

希望這個系列講完了，能夠給創(chuàng)業(yè)團隊的產(chǎn)品經(jīng)理們，帶來一些幫助。

0 產(chǎn)品or技術(shù)：狀態(tài)設(shè)計的區(qū)別

在技術(shù)的日常開發(fā)中，有一個常用的名詞叫狀態(tài)機。

這和軟件工程相關(guān)，也是非?；A(chǔ)的技術(shù)設(shè)計。

這方面的內(nèi)容很專業(yè)，而且從技術(shù)角度出發(fā)，經(jīng)常可以做出很復(fù)雜的模型，產(chǎn)品經(jīng)理們簡單了解一下就可以。

而產(chǎn)品經(jīng)理在進行產(chǎn)品設(shè)計中，其實是有所不同的。

那么，產(chǎn)品經(jīng)理把狀態(tài)引入到產(chǎn)品設(shè)計中的目的是什么呢？

當然還是為了服務(wù)于業(yè)務(wù)。

就是為了處理一個業(yè)務(wù)在流程中分階段的情況，而且可以在信息結(jié)構(gòu)中來體現(xiàn)。

也就是因為此，我們先講了流程和信息結(jié)構(gòu)，再講狀態(tài)。

講到這里，太過于枯燥了，所以我們直接上案例吧。

1 后端的狀態(tài)：是和業(yè)務(wù)相關(guān)的

根據(jù)流程來梳理，體現(xiàn)到信息結(jié)構(gòu)中

直接舉個例子來說吧。

當時我們做民宿的時候，針對訂單這個基礎(chǔ)產(chǎn)品，從業(yè)務(wù)上可能會有如下幾個流程：

1. 用戶在民宿平臺上篩選到了心儀的房源，并進行了下單，完成了支付；
2. 到了入住日期，用戶進行入住；
3. 到了退房日期，用戶離開；
4. 用戶退房離開后，民宿平臺或房東，會通知保潔進行房間清潔，等待迎接下一批用戶。

就這樣的一個過程中，從業(yè)務(wù)角度出發(fā)，訂單出現(xiàn)了哪些的可標記的狀態(tài)變化呢？

我們可以梳理一下：

1. 用戶已預(yù)訂

用戶在民宿平臺上下單，并且完成了入住時間、入住人信息等內(nèi)容填寫，生成了新的訂單。

2. 用戶已支付

訂單生成后，會等待用戶進行支付，這個時間根據(jù)不同平臺，一般是在半小時或兩個小時之內(nèi)（時間不能太長，否則會惡意占用時段不支付，造成房東的損失）。

3. 用戶未支付

因為某些原因，用戶沒有支付，訂單被取消。

4. 用戶已取消

在入住完成之前，用戶沒有來入住，用戶就自行取消了。

5. 房東已取消

因為房東的原因取消了訂單，此時一般就進入到了賠付流程。

6. 用戶已退房

用戶一直住宿到了退房時間，然后離開。

7. 保潔已清潔

保潔阿姨在用戶離開了之后，進入民宿客房來完成打掃。

以上狀態(tài)是不是也還是挺暈乎？

沒關(guān)系，待我們慢慢講~

至少上面的工作，達成了這樣一點：

我們根據(jù)業(yè)務(wù)情況，梳理出來一個民宿訂單的所有可能的狀態(tài)。

這些狀態(tài)會整理成枚舉值，作為訂單的信息結(jié)構(gòu)的一部分。

注意，以上僅做舉例，和我真正了解到的民宿平臺的訂單狀態(tài)是不一致的，我也是有意為之，請不要借鑒到商業(yè)中。

用狀態(tài)遷移圖連接起狀態(tài)

就拿這個例子來說，如果只是一串零散的訂單狀態(tài)，可能還不具備有足夠強的工具性。

那么此時就需要通過狀態(tài)遷移圖，來把這些零散的狀態(tài)進行連接。

這里就有點像技術(shù)所使用的狀態(tài)機遷移圖了，但還是通過業(yè)務(wù)角度來進行組織的，所以一般也會較簡單。

如上所示。

注意，以上我僅做舉例，和我真正了解到的民宿平臺的訂單狀態(tài)是不一致的，我也是有意為之，請不要借鑒到商業(yè)中。

關(guān)于狀態(tài)遷徙圖，有如下幾個要點：

1. 主狀態(tài)的流程

最好從上到下貫穿，作為主干。

2. 特殊的狀態(tài)、中斷的狀態(tài)

作為枝干在兩側(cè)，這里我把和用戶相關(guān)的放在了左邊，和房東相關(guān)的放到了右邊；

3. 連接條件

狀態(tài)和狀態(tài)之間，通過是某種條件來進行連接，要注意使用單箭頭，即便兩個狀態(tài)可以互相轉(zhuǎn)換，那條件也是不一致的。

4. 到達最終狀態(tài)

從業(yè)務(wù)角度出發(fā)，如果一個狀態(tài)不是最終狀態(tài)，那么一定要達到最終狀態(tài)。

這句廢話可以舉個例子，就是如果用戶已預(yù)訂但沒有支付，那從業(yè)務(wù)角度出發(fā)就一定不是最終狀態(tài)，必須要達到支付時間超時，到達支付未完成才算結(jié)束。

5. 前后端不必統(tǒng)一

后端設(shè)計中所展現(xiàn)出來的狀態(tài)，無論是名稱還是更多內(nèi)容，在前端給用戶展示時不必是統(tǒng)一的。

舉例而言，上圖中的狀態(tài)：支付未完成、用戶已取消、房東已取消，前端都可以展示成訂單已失效；用戶已退房，前端就可以直接展示為訂單已完成，因為保潔的后續(xù)工作已屬于內(nèi)部流程。

和技術(shù)如何對齊

還是老生常談，跟技術(shù)如何對齊呢？

雖然在技術(shù)的實際開發(fā)中，并不一定會需要和業(yè)務(wù)關(guān)聯(lián)比較緊密的狀態(tài)設(shè)計，但是產(chǎn)品跟技術(shù)對齊之后，可以有如下幾個好處：

1. 無論是產(chǎn)品還是技術(shù)，都不會完全脫離業(yè)務(wù)，知曉業(yè)務(wù)流程每一個環(huán)節(jié)應(yīng)該是什么樣的狀態(tài)，便于開展對應(yīng)的設(shè)計；
2. 技術(shù)開發(fā)中就可以避免不必要的分支，比如用戶已取消，就不會再到用戶已支付狀態(tài)，對測試形成用例也會有一定幫助。

2 前端的狀態(tài)：是和交互相關(guān)的

有時候除了后端的狀態(tài)設(shè)計，還有前端的狀態(tài)設(shè)計。

但從概念上來說，兩者其實并不太一致。

如果后端的狀態(tài)設(shè)計是和技術(shù)開發(fā)相關(guān)。

那么前端的狀態(tài)設(shè)計是和交互設(shè)計相關(guān)。

舉個簡單的例子。

如果前端設(shè)計一個音樂播放器，但只有一個主按鈕，根據(jù)交互，需要展示四個狀態(tài)：

• 未播放
• 正在播放
• 播放暫停
• 播放完成

前端可能是需要這4個樣式：

一般來說沒有什么太復(fù)雜的狀態(tài)遷移，所以也不需要畫狀態(tài)遷移圖。

主要是便于和交互設(shè)計師來進行溝通，最終達成成熟的方案。