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

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

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

今天我們進(jìn)展到了第三個(gè)。

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

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

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

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

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

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

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

一款产品无到有，产品经理需要做些什么？

在一个产品从无到有的过程中，要做好产品经理这个角色实在是不容易，除了大家都知道的写需求、写需求、写需求，要做的事多着呢。产品经理不是你眼中的只会找你麻烦，提要求..

查看详情 >

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

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

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

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

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

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

直接舉個(gè)例子來說吧。

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

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

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

我們可以梳理一下：

1. 用戶已預(yù)訂

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

2. 用戶已支付

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

3. 用戶未支付

因?yàn)槟承┰颍脩魶]有支付，訂單被取消。

4. 用戶已取消

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

5. 房東已取消

因?yàn)榉繓|的原因取消了訂單，此時(shí)一般就進(jìn)入到了賠付流程。

6. 用戶已退房

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

7. 保潔已清潔

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

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

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

至少上面的工作，達(dá)成了這樣一點(diǎn)：

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

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

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

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

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

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

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

如上所示。

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

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

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

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

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

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

3. 連接條件

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

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

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

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

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

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

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

和技術(shù)如何對齊

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

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

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

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

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

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

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

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

舉個(gè)簡單的例子。

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

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

前端可能是需要這4個(gè)樣式：

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

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