做到這三點挑戰，產品經理只會不斷升值
2025-4-1 杰睿
為了避免出現用戶所想看的信息被其他海量信息所淹沒的情況，設計師或者產研團隊需要思考如何做好信息收納，讓擁有厚重信息和功能的產品變得簡單清爽且易用。這篇文章里，作者就梳理了如何利用好容器類UI組件達成這一目標的策略，一起來看。
如果你問用戶他需要什么，他的回答大概率是“我全都要”。但是如果你把他想要的東西全都展示在頁面上，會發生什么？
用戶被自己想要的信息淹沒了。他會說：“這根本沒法看，也沒法用，你們的設計太爛了。”
信息量大、操作復雜是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》
“界面設計就是把報紙塞進火柴盒的藝術”，這個比喻真是太妙了！（本土化：把大象裝進冰箱的藝術）。怎么把報紙塞進火柴盒？變魔術嗎？其實從某種角度上看，我們設計師就是魔術師——在適當的時機展示恰到好處的信息。
而我們用到的道具，就是容器類UI組件。區別于其他類型的組件（比如輸入框下拉框），容器類組件就像收納盒，也就是用來收納信息和操作的。
咱們今天就來探索一下，如何利用好容器類UI組件，完成“空間膨脹術”，把報紙絲滑地塞進火柴盒。
本文會分成兩部分。
這個決策樹不限于提供以下價值：
下面我們正式開始吧~
一個單點數據關聯的信息量能有多大？看一個網安行業的例子：
安全管理的目標是要確保資產安全。用戶要做的，首先是要清點資產，資產分類分級和業務信息是資產自身屬性。另外，資產本身會存在一系列漏洞，漏洞也有分類分級以及修復過程數據。如果漏洞被利用，就會產生威脅告警，而告警也存在分類分級及處置過程數據。
可以看出，將數據建立層層關聯后，從一個單點可以衍生出來的信息是海量的、無邊的。
我們當然不能把這全家桶一整個砸給用戶呀，用戶會被砸暈的。那我們該怎么做？
有兩個定律，跟“復雜”有關。
這兩個定律告訴我們一個道理：復雜，不會讓用戶覺得更好用，甚至增加了不必要的內耗。
處理復雜，我們一般有哪些辦法呢。
第一步，先刪除多余的部分。就好比我們整理房間時，先挑出垃圾和閑置。
第二步，把物品歸類。被子和被子疊在一起，衣服和衣服掛在一起，書本放在書架上。總之，不能都堆到床上。
第三步，漸進呈現。這就到了設計師要用“容器類”組件來完成“空間膨脹術”的環節了。
漸進呈現的設計理論有點像C4模型。C4模型是一種軟件架構可視化方法。它的獨特之處，就是從宏觀到微觀，設置了多個焦距，來層層遞進。
產品中的內容也存在層層遞進。內容之間的關系，常見以下兩種。
一種是從屬關系，或父子關系。
一種是關聯關系，數據以某種維度建立了關聯。
我們如何用容器類UI組件，去放置這些復雜且層層關聯的內容？
以下是我們常見的容器類UI組件。
這些組件都可以用來收納，但是它們的特征差異也是巨大的，不能隨意混用。
我從“復雜度高低”和“關聯性強弱”這兩個坐標維度來劃分出四個象限，展示這幾個容器的特征。
左下角這里基本是空的，為什么？因為這個是按照組件的最大潛力來擺放的，高維度可以兼容低維度。
值得注意的是，有一些組件在當前頁面內，而有些在浮層中。浮層在空間Z軸上有高度，視覺表現為有投影。
容器可以展示信息，也可以用來承載操作。我們把這兩個場景分開考慮。首先，我們從信息展示場景開始，分析如何選擇容器。
這里有幾個關鍵問題，我們逐個分析：
關鍵問題一：能否分清主次。
這個問題很難。用戶可能說“這個內容我需要”，但“需要”這個詞存在極大的灰度空間，我們要判斷“需要”是多“重要”，需要從這幾個維度去分析。
關鍵問題二：是否需要對比參考。
如果需要對比參考，不能使用tabs（選項卡）。因為tabs組件存在“排他性”——只有選中tab的子內容是展示的，未選中的tabs下的內容是被隱藏的。
以購物為例，用戶在對幾款產品進行對比挑選時，期望在一個界面同時看到幾款產品的參數和價格等。如果把產品數據放入各tab中，用戶就得在tab間反復橫跳，讓有限的短期記憶承受巨大壓力。
（↑案例：蘋果手機參數對比）
當然，如果沒有對比參考的需求，我們可以考慮把內容歸類到不同tabs下。在使用tabs組件時要確保內容分類合理、標簽文案簡潔易懂。這樣用戶才能理解并愿意探索。
（↑tabs的應用）
關鍵問題三：是否需要保持上下文。
有這樣一個場景：上級單位對多個下屬單位進行考核，打分有一定主觀性，需要參考其他單位得分。如果跳轉新頁面進行打分操作，就會斷開原有上下文的關系，影響用戶操作流暢性。
需要保持上下文的場景中，應避免迫使用戶離開父級頁面，建議在原頁面或浮層中呈現更多信息。
關鍵問題四：是否頻繁往返。
這個一般由任務類型決定，即當前操作是“主線任務”還是“支線任務”。
在主線任務場景中，用戶持續前進。比如網購商品，用戶在選購商品-確認地址-付費-下單完成···等步驟中環環前行。這時建議使用原頁面跳轉的方式。
支線任務完成后，一般要回歸主任務，也就是存在“往返”，就像從小路回歸到大路上。比如清理郵箱：用戶閱讀處理完一封未讀郵件后返回未讀列表，繼續處理下一條。在這里，“閱讀并處理一條郵件”是支線任務，“”清理郵箱”是主線任務。建議給“支線任務”新開標簽頁處理。
關鍵問題五：是不是必須看到的。
當前信息對用戶來說是否重要且關鍵？模態是較為“強勢”的交互模式。原則上，界面態度保持禮貌克制，以免打擾到用戶。
并不是所有容器都適合放置表單操作——部分容器因“排他性”的特征，會隱藏部分信息，可導致用戶遺漏重要操作。
我們一般將操作分成兩類：
我們可以按照表單的體量，或者信息的重要及關鍵程度，選擇相應的UI組件。
容器組件的的神奇之處是可以多次嵌套和疊加，創造出更多空間。
但注意保持信息體量和層級之間的平衡，避免過多嵌套和疊加，讓用戶在多個容器中迷失方向。
（↑案例：抽屜嵌套抽屜）
（↑案例：tabs嵌套tabs）
（↑案例：抽屜嵌套tabs）
感謝讀到最后的讀者們，就用一句話來結束今天的分享吧~
設計一件東西時，總是要在更大的環境中考慮它——房間里的一把椅子、房子里的房間、環境中的房子、城市規劃中的環境。
——埃里爾·沙里寧 (1873–1950)，芬蘭建筑師
本文由 @杜大大杜 原創發布于人人都是產品經理。未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
蘭亭妙微(www.devb.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的大數據可視化界面設計、B端界面設計、桌面端界面設計、APP界面設計、圖標定制、用戶體驗設計、交互設計、UI咨詢、高端網站設計、平面設計，以及相關的軟件開發服務，咨詢電話：01063334945。我們建立了一個微信群，每天分享國內外優秀的設計，有興趣請加入一起學習成長，咨詢及進群請加藍小助微信ben_lanlan