信息量大、操作復雜是B端產品的典型特征。我們如何把具有厚重信息和功能的產品，變得對用戶來說清爽易用？

設計師就像魔術師

My dad once told me that graphic design is the art of fitting a newspaper inside a matchbox, and I would say a lot of interface design is the same.

——Tess Gadd《UX cheat sheet: Preview and full display》

“界面設計就是把報紙塞進火柴盒的藝術”，這個比喻真是太妙了?。ū就粱喊汛笙笱b進冰箱的藝術）。怎么把報紙塞進火柴盒？變魔術嗎？其實從某種角度上看，我們設計師就是魔術師——在適當的時機展示恰到好處的信息。

而我們用到的道具，就是容器類UI組件。區別于其他類型的組件（比如輸入框下拉框），容器類組件就像收納盒，也就是用來收納信息和操作的。

咱們今天就來探索一下，如何利用好容器類UI組件，完成“空間膨脹術”，把報紙絲滑地塞進火柴盒。

本文結構

本文會分成兩部分。

• 第一部分：尋找到問題所在，探索出恰當的設計策略。
• 第二部分：針對設定好的設計策略，提煉出“容器類”組件使用決策樹。

這個決策樹不限于提供以下價值：

• 幫助設計師們在設計過程中高效決策，提升設計效率；
• 幫助產研團隊在討論中快速達成一致、減少內耗；
• 提升匯報時的說服力，獲得干系人支持。

下面我們正式開始吧~

PART 1：定位問題、設定策略

1. 問題所在

一個單點數據關聯的信息量能有多大？看一個網安行業的例子：

安全管理的目標是要確保資產安全。用戶要做的，首先是要清點資產，資產分類分級和業務信息是資產自身屬性。另外，資產本身會存在一系列漏洞，漏洞也有分類分級以及修復過程數據。如果漏洞被利用，就會產生威脅告警，而告警也存在分類分級及處置過程數據。

可以看出，將數據建立層層關聯后，從一個單點可以衍生出來的信息是海量的、無邊的。

我們當然不能把這全家桶一整個砸給用戶呀，用戶會被砸暈的。那我們該怎么做？

2. 設計策略

有兩個定律，跟“復雜”有關。

這兩個定律告訴我們一個道理：復雜，不會讓用戶覺得更好用，甚至增加了不必要的內耗。

處理復雜，我們一般有哪些辦法呢。

第一步，先刪除多余的部分。就好比我們整理房間時，先挑出垃圾和閑置。

第二步，把物品歸類。被子和被子疊在一起，衣服和衣服掛在一起，書本放在書架上?？傊?，不能都堆到床上。

第三步，漸進呈現。這就到了設計師要用“容器類”組件來完成“空間膨脹術”的環節了。

漸進呈現的設計理論有點像C4模型。C4模型是一種軟件架構可視化方法。它的獨特之處，就是從宏觀到微觀，設置了多個焦距，來層層遞進。

3. 內容分析

產品中的內容也存在層層遞進。內容之間的關系，常見以下兩種。

一種是從屬關系，或父子關系。

一種是關聯關系，數據以某種維度建立了關聯。

PART 2：容器，以及如何使用容器

1. 關于容器

我們如何用容器類UI組件，去放置這些復雜且層層關聯的內容？

以下是我們常見的容器類UI組件。

這些組件都可以用來收納，但是它們的特征差異也是巨大的，不能隨意混用。

我從“復雜度高低”和“關聯性強弱”這兩個坐標維度來劃分出四個象限，展示這幾個容器的特征。

左下角這里基本是空的，為什么？因為這個是按照組件的最大潛力來擺放的，高維度可以兼容低維度。

值得注意的是，有一些組件在當前頁面內，而有些在浮層中。浮層在空間Z軸上有高度，視覺表現為有投影。

容器可以展示信息，也可以用來承載操作。我們把這兩個場景分開考慮。首先，我們從信息展示場景開始，分析如何選擇容器。

2. 信息展示容器的決策樹

這里有幾個關鍵問題，我們逐個分析：

關鍵問題一：能否分清主次。

這個問題很難。用戶可能說“這個內容我需要”，但“需要”這個詞存在極大的灰度空間，我們要判斷“需要”是多“重要”，需要從這幾個維度去分析。

關鍵問題二：是否需要對比參考。

如果需要對比參考，不能使用tabs（選項卡）。因為tabs組件存在“排他性”——只有選中tab的子內容是展示的，未選中的tabs下的內容是被隱藏的。

以購物為例，用戶在對幾款產品進行對比挑選時，期望在一個界面同時看到幾款產品的參數和價格等。如果把產品數據放入各tab中，用戶就得在tab間反復橫跳，讓有限的短期記憶承受巨大壓力。

（↑案例：蘋果手機參數對比）

當然，如果沒有對比參考的需求，我們可以考慮把內容歸類到不同tabs下。在使用tabs組件時要確保內容分類合理、標簽文案簡潔易懂。這樣用戶才能理解并愿意探索。

（↑tabs的應用）

關鍵問題三：是否需要保持上下文。

有這樣一個場景：上級單位對多個下屬單位進行考核，打分有一定主觀性，需要參考其他單位得分。如果跳轉新頁面進行打分操作，就會斷開原有上下文的關系，影響用戶操作流暢性。

需要保持上下文的場景中，應避免迫使用戶離開父級頁面，建議在原頁面或浮層中呈現更多信息。

關鍵問題四：是否頻繁往返。

這個一般由任務類型決定，即當前操作是“主線任務”還是“支線任務”。

在主線任務場景中，用戶持續前進。比如網購商品，用戶在選購商品-確認地址-付費-下單完成···等步驟中環環前行。這時建議使用原頁面跳轉的方式。

支線任務完成后，一般要回歸主任務，也就是存在“往返”，就像從小路回歸到大路上。比如清理郵箱：用戶閱讀處理完一封未讀郵件后返回未讀列表，繼續處理下一條。在這里，“閱讀并處理一條郵件”是支線任務，“”清理郵箱”是主線任務。建議給“支線任務”新開標簽頁處理。

關鍵問題五：是不是必須看到的。

當前信息對用戶來說是否重要且關鍵？模態是較為“強勢”的交互模式。原則上，界面態度保持禮貌克制，以免打擾到用戶。

3. 功能操作決策樹

并不是所有容器都適合放置表單操作——部分容器因“排他性”的特征，會隱藏部分信息，可導致用戶遺漏重要操作。

我們一般將操作分成兩類：

• 一類是需要用戶提交信息的，例如填寫表單，一般由用戶喚起。
• 一類是接收和確認系統信息，一般由系統發起。

我們可以按照表單的體量，或者信息的重要及關鍵程度，選擇相應的UI組件。

4. 空間膨脹術

容器組件的的神奇之處是可以多次嵌套和疊加，創造出更多空間。

但注意保持信息體量和層級之間的平衡，避免過多嵌套和疊加，讓用戶在多個容器中迷失方向。

（↑案例：抽屜嵌套抽屜）

（↑案例：tabs嵌套tabs）

（↑案例：抽屜嵌套tabs）

今天的分享就到這里了

感謝讀到最后的讀者們，就用一句話來結束今天的分享吧~

設計一件東西時，總是要在更大的環境中考慮它——房間里的一把椅子、房子里的房間、環境中的房子、城市規劃中的環境。

——埃里爾·沙里寧 (1873–1950)，芬蘭建筑師