交互水深 10 | 以 [ 訂單狀態 ] 為例，聊聊產品策劃的八字法則

05-03

上一篇看得暈乎乎，甚至開始懷疑人生。好吧，這一篇也不保證一定能看懂，反正就是寫著費勁，看著累人，看懂了就有驚喜！

為了容易理解，本篇聚焦：如何稍微優雅的設計訂單中的各種狀態。

當然，將用到產品策劃中的『萬用八字法則』：搜集、整理、判斷、創新。

搜集：羅列重要的維度

還記得這個原型嗎？三個維度的狀態把用戶搞暈，本次要優化的目標。咱們看看『訂單狀態』『支付狀態』『物流狀態』都有什麼樣的『狀態值』：

圖#01當中，某些狀態值是明顯帶有跨維度關聯，比如『未付款』『待付款』；同時不難發現包含了『評價狀態』這個隱含的維度；並且，每一個維度都會出現『異常』的情況（老司機都懂，正常簡單，異常才難）：

通過圖#02，發現一個有趣的現象，『訂單狀態』和其他維度都有千絲萬縷的聯繫，而其他維度之間貌似是解耦的，莫非『訂單狀態』是個組合之後的『全局維度』？

一次整理：維度之間的關係

狀態維度太多，會造成認知災難。為了化解這種現象，設計師們通過各種努力從心智感知角度縮減維度，最簡單的方法就是創造一個全局維度。

例如，有兩個原始維度『色彩』與『水果』，.運用『多維度狀態可以變成一個維度』，可以創造出一個全局維度『彩色的水果』，這個過程無需任何根據與理由，只是普通的排列組合問題。

『一個維度又可以進行多維度篩選』，這個過程比較複雜：事物都是有兩面性的，多個事物具有多面性，從多個角度找出共性，就可以快樂的進行篩選了。比如『彩色的水果』這個全局狀態，就可以有以下這種篩選（當然還可以有更多種方案）：

所以，在訂單記錄集中，『訂單狀態』是一個全局維度，是『支付狀態』『物流狀態』……甚至『退貨狀態』等一系列原始維度的組合產物。

除了『易於識別，降低認知成本』，全局狀態的好處還有：區別不同狀態提供不同操作，讓迭代開發更容易。

在研究『訂單狀態』這個全局維度之前，先從順序與規則角度，分析一下影響它的原始維度。

二次整理：狀態值的順序

如果理解『同緯狀態之間相互離散』，就可以把任何『值』作為狀態。為了不那麼離譜，通常都會給這些『離散狀態值』附加一些順序和規則，這是一個完全人為的編碼過程。例如，紅綠黃，三個顏色本身是平等的，但是城市交通規則賦予了『紅燈禁止』，『綠燈通行』，『黃燈警示』，並且按照『紅>綠>黃>紅』順序循環切換。

順序，貌似僅僅是先後順序，本質上是增加了一個時間維度；這些順序可以是單向的，也可以是雙向的，並且可以連接在一起形成循環。

假如給圖#02當中的狀態值排序一下，可以有下面的結果：

三次整理：『一動一態』

『一個動作，一個狀態』，即無論兩個狀態之間有何種數量的操作，都可以把這些操作抽象為唯一的一個！這是一個可以和『一個界面完成一個用戶任務』比肩的重要規則，雖然二者應用的範圍不同。

『一動一態』的好處，顯而易見：

讓心智模型變得簡單，減輕用戶認知負擔
讓設計師能輕鬆的處理各種狀態值

將圖#03當中四個維度已經排序的狀態值進行『操作』填充，可以得到下圖：

在填充過程中，加入了各個維度的『就緒』狀態，並且補充了『投遞』這個操作和後續狀態。

判斷：訂單流轉的規則！

訂單，在生活中是一張紙，一種買賣雙方的契約。有關訂單的正常流程特別特別簡單，因為訂單在生活中幾乎是『只有一個同名實體在流程中被同時操作』。

通過圖#04，很容易發現無論有多少種用戶角色，四個維度中只存在7種正常操作：『付款』『出庫』『發貨』『運輸』『投遞』『簽收』『評論』。其他的操作都是『異常』。

顯然，通過對『操作』的梳理可以幫助設計師跨維度考慮『狀態值』，這就是『一動一態』的最大優勢。

不假思索，可以得到兩個有趣的事情：

第一，『正常狀態』和『異常狀態』是兩組完全不相關的互斥關係；
第二，『付款規則』是一個隱藏維度，『先款後貨』和『貨到付款』決定了7個正常操作的不同排序；

為了簡化思考過程，建議先拋棄所有的『異常』，先考慮正常操作的順序問題，記住對於訂單來說，正常流轉是一條簡單的直線！

『分期付款』可以看作是『先款後貨』與『貨到付款』的結合體，略複雜，所以略………（有興趣的朋友自己研究吧）

根據圖#05中的『先款後貨』規則，可以把圖#04當中的『一動一態』分別填充到每個正常操作的首尾，見下圖：

圖06#是按照規則得到的『操作流程』，合併一下冗餘的『未付款』和『待付款』，並且Hozin覺得『備貨中』也沒什麼存在價值，保留8個狀態，將它轉換為『狀態流程』，見下圖：

當然，如果理解事件驅動，並且學習過UML的『狀態圖』，也許會覺得圖#07很不專業；的確，這只是心智認知上的一些梳理，並非技術實現層面；推薦設計師系統學習UML或類似規範，那是個一勞永逸的事情。

關於『貨到付款』的狀態流程，諸位看官有興趣可以整理，公布出來，切磋交流。

創新：處理異常

先解決正常，再解決異常，這樣相對輕鬆愉快，思路不容易被打攪。

按照二八法則，8個狀態通常會引發30～40個異常狀態甚至更多，在實現模型當中7個正常操作都可能產生異常，設計師要逐一處理他們，圖#08只是給出幾個示例而已：

因為訂單一旦產生，就佔用庫存，所以付款具有時效性，超時會觸發異常，進入『庫存退還』流程；
庫存偏差通常會引發真實庫存不足的情況，此時需要排查解決，如果能『重新備貨』就能讓訂單恢復正常；
投遞貨物的過程中，也會存在異常，比如多個包裹當中有一個沒有簽收或者丟失，將進入『簽收異常處理』流程；
某一些異常不會引發其他流程，只是會進行標註，比如『評價超時』實際上就是自動給予好評了；
『退貨』和『退款』是另外一些流程，甚至比『訂單』更複雜，請不要試圖在一張圖上搞定，請盡量解耦；

處理異常會佔用大量的時間和精力，好好享受它們吧……

在界面上解決多維度狀態

根據《交互水深 08 | 列表設計，不止是控制慾望的遊戲》當中的技巧，強烈建議在列表設計中只保留『全局狀態』，這當然還會附加一系列的魔法。

技巧之一：正常狀態與異常狀態同維度展示

因為正常與異常是互斥的，放在一列就好，通常需要給異常已高亮顯示：

技巧之二：正常狀態之後給出下一步狀態

當前狀態與後續狀態一起顯示，給予當前狀態『著重顯示』，只要是『狀態流程』都應該這樣做，減輕用戶認知負擔。

技巧之三：滑鼠Hover時PoP狀態流程詳情

正常狀態PoP顯示流程圖，異常狀態PoP顯示詳情，參考下圖：

技巧之四：以『操作』為中心設計篩選功能

有的設計師會擔心：把這麼多維度都合併了，藏起來了，篩選怎麼辦啊？嗯嗯，根據『一個界面完成一個用戶任務』，可以換個思路：篩選是為了找到記錄集當中的目標，因為不同狀態可能會影響允許操作的種類，除了查看狀態，找到目標是為了『操作』；那麼，按照『操作』去篩選就OK了啊，這也是『一動一態』的優勢之一。

總是需要用戶按照『訂單狀態』+『支付狀態』+『物流狀態』篩選半天，好不容易找到目標，最終還是要去找『退款』『退貨』『撤銷』這些按鈕，那還不如直接用下面的篩選設計：

如果有點莫名秒，請快去閱讀『單選小坑，多選大坑』的上中下三篇。

再次叮囑：

『一個界面完成一個用戶任務』，在列表界面盡量保持簡潔，但是在詳情界面，還是依然要多維度忠實的顯示原始維度數據啊，因為那是『詳情』！

小結

『搜集』、『整理』、『判斷』、『創新』是產品策劃的基本法則；合併多維度狀態過程中也會用到這個方法。

搜集：羅列主要維度的上的狀態值，標註關聯『值』並認真發現隱藏維度；

整理：首先，發現維度之間關係，判斷是否包含全局維度；其次，保持維度不變，進行排序；再次，按照『一動一態』原則填充操作；

判斷：那些互斥的存在，立即解耦它們之間的聯繫，縮小思考範圍；找到操作之間的聯繫，給操作排定順序關係和流程；用『操作流程』跨維度反推『狀態流程』；

創新：在解決『正常狀態』和『正常操作』之後，再逐一破解『異常狀態』和相關流程；

多維度狀態並存，此時界面上可選的設計技巧：

正常狀態與異常狀態同維度展示
正常狀態之後給出下一步狀態
滑鼠Hover時PoP狀態流程詳情
以『操作』為中心設計篩選功能

寫文章不容易，請呵護原創未經授權，請勿轉載

精力有限，知乎專欄更新較慢，追番請移步微信公眾號 hozin-com

Hozin公眾號入口

擴展閱讀

交互水深 01 | 從區分 [ 頁面 ] 和 [ 界面 ] 開始吧

交互水深 02 | 設計師對 [ 功能 ] 應該有怎樣的認知？

交互水深 03 | 理解 [ 用戶任務 ] 的 [ 顆粒度 ]

交互水深 04 | 選擇設計中的五個要點【單選小坑，多選大坑】（上篇）

交互水深 05 | 下拉框的濫用、聯動菜單、單選特例、級聯單選【單選小坑，多選大坑】（中篇）

交互水深 06 | 多選陷阱、收集器、列表構造、增項列表【單選小坑，多選大坑】（下篇）

交互水深 07 | 長期設計APP會讓人變傻

交互水深 08 | 列表設計，不止是控制慾望的遊戲

交互水深 09 | 多維度狀態，電燈泡的鬥爭