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

上一篇文章，介紹了如何精簡列表設計，其中蘊含了一些狀態合併技巧；趁熱打鐵，本篇將主要從『心智感知』角度展開介紹，如何應對各種複雜的『狀態』；請注意，本文並非討論『技術實現』的相關問題，請不要吹毛求疵。

只需三個維度，便是一場災難

電商產品中，一個購買行為通常包含至少三個維度的狀態值：訂單狀態、支付狀態、物流狀態。於是，賣家管理平台通常可能會有如下的列表設計：

如果基本掌握《交互水深 08 | 列表設計，不止是控制慾望的遊戲》當中的技巧，設計師可以輕鬆的將這個設計進行簡化，但是有關『狀態值』的那部分恐怕無從下手。將上圖局部放大，再仔細看看：

圖中，已知訂單狀態有6個，付款狀態有2個，物流狀態有5個，至少是60種組合；並且，目前看來是毫無規律可循：

同樣是『已付款』狀態，訂單狀態可能有很多種；

同樣是『已付款』+『已簽收』，訂單可能是『已完成』或『已評價』（評價狀態被隱藏在詳情中）；

訂單狀態中的『代付款』和支付狀態中的『未付款』，明顯冗餘；

如果再加上『退貨狀態』和『退款狀態』，絕對可以讓用戶抓狂；因為每增加一個維度，組合可能性都將乘以這個維度上的『狀態值數量』；用戶無法簡單的分辨多維度狀態交叉，無法一目了然的獲知真正的『狀態』。

面對問題，某些朋友會不以為然：反正是ToB產品，都是專業賣家嘛，只要提供狀態篩選就好了呀？呵呵，把鍋甩給用戶，這個姿勢很贊！

那麼，Hozin嘗試徹底的討論一下『狀態』，先聊聊生活中的一個小故事……

會玩兒燈的『狀態大師』

假設，有一種燈泡，它們有三個狀態值『關閉』『白燈』『彩燈』，並且每一枚燈泡都擁有一種獨特的顏色。那麼，每一盞燈可以使用一個三項開關控制。以紅色彩燈為例，如下圖：

某個房間需要安裝4盞類似的燈泡，分別為#01紅色、#02藍色、#03綠色、#04紫色，此時理論上需要4個三項開關，一共有81種開關組合形式。

此時，燈光師出馬上陣，給出了建議：有5種固定的燈光組合，能夠協調室內氛圍，讓光線更具有戲劇性效果。並且，燈光師提供了從實現模型到心智模型的具體設計方案：

這個鍋，甩給了電工師傅。最終Ta根據燈光師的需求，對開關面板進行了改造，最終保留了4個互斥的按鈕，如下圖：

這個生活中『玩兒燈』的小故事，揭示了兩個有趣的現象：

多維度狀態可以變成一個維度；

4盞燈81種開關組合，經過捨棄，保留5種組合；5種組合被分別命名，扔進一個全新的維度。

一個維度又可以進行多維度篩選；

5種開關組合，可以變成4個互斥的按鈕；當然也可以變成『1個兩項開關』+『2個互斥的按鈕』，或者更多設計方案（大家有興趣可以試試）。

以上兩個基本原理，非常重要！

『狀態』的本質是什麼？

普通認知是這樣的：

吃飯、睡覺、玩手機就是生活狀態；撕逼開會、蛋逼閑著、苦逼忙著就是工作狀態；暢通、擁堵就是交通狀態；出生、衰老、患病、掛了就是健康狀態……

狀態不就是同一維度上的各種日常嗎？

作為信息架構師，對『狀態』的認知可不止這些日常：

首先，狀態的維度是沒有界限；

『Hozin的耳朵有點缺機油，還經常睜不開』，在生活中這是個病句，一句瘋話。缺機油是發動機的狀態，睜不開是眼睛的狀態，不符合耳朵的器官特質，但這種界限在信息世界裡，是可以完全打破的！只要自定義一個叫『Hozin的耳朵』的維度就可以了。

其次，同一維度上的狀態值可以是離散量；

所謂『離散』，就是完全不相關。例如『Hozin的耳朵』這個維度上，可以有『缺機油』『睜不開』『沒吃飽』『退休』『懷孕』這些毫無關係的值，只要Hozin喜歡就可以！因此，某個維度上的狀態值，理論上是無限的！但實際使用中，為了效率，又往往是限定範圍的。

並且，同一維度上的狀態值可以任意切換；

在真實世界中，人死不能復生，從『生』到『死』是一種不可逆的狀態切換。但在信息世界裡，完全可以『起死回生』，不受約束呀！

信息是創建一切宇宙萬物的最基本萬能單位，它不是物質，也不是能量，也沒有大小。

這句話不是Hozin瞎編的，而是美國數學家 Norbert Wiener 說的，若能理解其中奧義，恭喜你啊，已經無限接近『信息架構師』還有個十萬八千里吧！

好，回到主題，Hozin認為：

在信息世界裡，『狀態』的本質是一種編碼。

既然是編碼，那就可以隨便搞咯，甚至可以人工創造出《生活大爆炸》當中的克林貢語，只要你喜歡就好。

編碼是什麼啊？說起來還真和燈泡有點關係，請閱讀這本書《編碼：隱匿在計算機軟硬體背後的語言》，反正有二極體、燈泡和電能，就能造出計算機，純屬電工手藝。

補充：『狀態值』能做什麼？

首先，可以作為各種判斷條件的基礎素材；

可以廣義的理解為：任何條件判斷條件都是狀態，即任何『值』都是狀態，任何功能（CRUD）都是『切換狀態』

其次，『切換狀態』可以是各種操作的結果；

往往，用戶操作了幾百下，就為了改變一個狀態而已，其他的什麼都沒得到，囧～

技巧：快速合併前置維度

經常發生一種情況：某一維度的『值』要依靠另外一個前置維度的『狀態值』才有效。此時，可以將兩個維度進行合併。

如下圖，只有使用了分期付款功能，才有分期付款的具體金額，可以將二者合併。

這種合併的本質，並非是誰吃掉了誰，而是生成一個全新的維度。

沒錯，在上一篇的簡化『學生列表』例子中，就使用了此技巧將『學生狀態』與『年級+班級』進行了合併，因為：已經畢業、肄業、轉學、退學的離校學生已經沒有了年級和班級。

小結

在信息世界裡，狀態是一種編碼。根據『信息的離散性』，狀態具有三個特點：第一，維度無界限；第二，同維狀態值之間離散；第三，同維狀態值之間可以任意切換。

廣義上，所有的數據都『狀態』，任何『值』都是『狀態值』，它們既可以作為判斷條件，又可以作為操作結果。

多維度的狀態並存，會帶來用戶認知的巨大負擔！為了解決這個問題，減輕認知負擔，可以利用兩個原則：『多維度狀態可以變成一個維度』和『一個維度又可以進行多維度篩選』。

設計過程中，需要在『實現模型』和『心智模型』之間不斷轉換，通過『創造新的維度』合併多個維度。

常用技巧：快速合併前置維度。

劇透：咱們還沒解決『訂單狀態』『支付狀態』『物流狀態』的問題呀？別急，下一篇將圍繞『狀態流程』展開，敬請期待吧。

本文關於信息架構的相關闡述略有難度，不能理解的話，就先囫圇吞棗吧

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

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

Hozin公眾號入口

擴展閱讀

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

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

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

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

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

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

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

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

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

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

推薦閱讀：