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

前兩篇中，闡述了『選擇』的五個要點，設計『單選』的注意事項，以及『聯動菜單』和『級聯選擇』等基本概念。

本篇將圍繞『多選』展開，同時介紹『收集器』、『列表構造』、『增項列表』等界面上的重要概念。

破解『多選陷阱』

實際工作中，『多選』通常有幾百個候選項，甚至產品需求是對分頁列表中的數據集進行批量操作。面對此類問題，常見設計方案如下：

設計思路：數據集當中，每一條記錄都包含一個複選框；存在一個『全選』按鈕或複選框，點擊則全部勾選，再次點擊則全部不勾選；針對已經選中的項目進行批量操作。

此設計思路的明顯缺陷：

• 假如選中第1頁第3條和第3頁第5條，此時無法跨頁同時看到哪兩條已經被選中（跨類也一樣）
• 全選操作的範圍模糊，是僅限本頁，還是包含所有的分頁？
• 搜索第一個關鍵字，勾選其中某幾項，此時搜索另外關鍵字，前面所選是否依然有效？如果有效，假如不在當前結果之中，如何辨識？

所以，當設計跨頁、跨類多選的時候，請嚴重注意以上問題。

如何破解『多選陷阱』呢？一個非常簡單的『收集器』就可以搞定：

看起來像『購物車』吧？沒錯，它就是一種典型的『收集器』。

特別注意，在設計『收集器』時，請保持下面的原則：

收集器中不應該再有跨頁或者跨類多選，否則將又製造一個新的『多選陷阱』。（通常不會再分頁，或者只分類不多選）

跨級多選是大坑

多級分類，只有在末端節點才有葉子，形成跨類多選；還有另外一種更複雜的情況，即在每一級節點上都可能包含葉子，形成『跨級多選』。

B端產品需求中，通常存在『企業的組織架構』，它代表了一類數據關係：嚴整的樹形多級分類，每一級都可能包含葉子。於是，既要保證等級森嚴，又要進行多選，成了亘古難題。

真的很難么？通常的設計中，採用樹形結構是常見方案，如下圖：

設計思路：

• 展開和摺疊兩種狀態的區分，切換操作；
• 級別之間的縮進關係；
• 枝杈和葉子兩種形式的區分；
• 枝杈包含葉子數的顯示；
• 已經選中和未被選中的區分，切換操作；
• 快速選中某個枝杈下屬的所有葉子和枝杈，以及逆操作；

此設計思路的明顯缺陷，依然是『多選陷阱』：

• 如果枝杈非常多，勾選分布範圍較大，無法在一個屏幕顯示所有被選中葉子；
• 假如某個枝杈被摺疊，那麼該枝杈下屬所含被選中的葉子容易被忽略；
• 如果枝杈為無限級，此時跨級別多選，也無法在一個屏幕顯示所有被選中葉子；

初步結論：樹型結構利於顯示和單選，但不利於多選；用戶辨識複雜度較高，操作複雜度更高，容易落入『多選陷阱』。

臨時的解決方案：增加一個帶路徑的收集器。

列表構造

只會設計APP，已經讓從業者的技能嚴重退化。雖然熟練的設計師都會使用『購物車』解決多選問題，但是Web/桌面軟體的另外一種『多選大殺器』卻越來越變得鮮為人知，那就是『列表構造』：

顯然，列表構造器在處理幾百上千個候選項時：一目了然，節約空間，得心應手。

列表構造器同時存在兩類列表：一類是『源列表』，即候選項目；另外一類是『目標列表』，即已選項目。操作一組控制按鈕，實現『選項』在兩類列表之間切換轉移。

這種大殺器擁有超多的衍生形式，設計貼士如下：

• 對於每個『源』或『目標』，其中即可以是多選也可以是單選；
• 如果『源』或『目標』當中項目太多，可以設計某個列表內的搜索（查找）；
• 『源』或『目標』可以存在分頁（不推薦，可能產生多選陷阱），或者根據長度有滾動條；
• 『源列表』不能出現多級分類（一級分類雖然可以，但也不推薦，跨級更是絕對禁止，後面會介紹）
• 『目標列表』中禁止出現任何形式的分類（僅有一級也不行）；

• 『源列表』當中，應將已選中項目設置為不可選，或者直接剔除已選中項目（移動），防止重複選中；
• 雙擊某個項目可以直接在『源』與『目標』之間切換，或者改變其他觸發形式；

雖然有諸多禁忌，但仍無法阻擋『非APP交互設計師』對它們的喜愛，例如在PC版微信中，『選擇轉發用戶界面』就使用了構造列表器：

級聯列表構造

多級分類結構中，如果只在末端枝杈包含葉子（非跨級），且分級比較固定，例如3級、4級、最大限度為5級，此時可以採用級聯列表構造器，快速實現多選。級聯的多個『源列表』只有最末級為多選，其他級別為單選，參考形式如下：

不難發現，此形式與上一篇提到的『級聯單選』非常相似，只是變為了多選（當然，單選也可以使用級聯列表構造器實現）。

當然，上圖之中也存在『多選陷阱』的隱患：

• 選擇中國的『成都』，但並沒有觸發『>』按鈕進行切換，此時直接將國家改成日本，選擇『東京』，然後觸發『>』，此時成都應該轉移到『目標列表』嗎？

這個問題每個設計師有自己的答案，無論答案是什麼，隱患都不太致命；因為『目標列表』顯性存在，多選陷阱的危害被大大削弱；在操作效率面前，可以向合理性適當妥協。

增項列表與多選嵌套

還有什麼武器能應對海量候選項的多選呢？看看這個大家都熟悉，但可能叫不上名字的『增項列表』。它是列表構造器的變體，比列表構造器更節約空間。

只要屏幕空間允許，多選嵌套可以玩出很多花樣，無非兩種方式：把多選拆分為多步驟『單選』，或者把多選拆分為多步驟『多選』。

兩個重要的排序

本篇介紹的幾種都選形式，都有近似的特徵，多選並非一次完成，而是可以『分塊』轉移。在實際項目中，撰寫PRD和交互文檔時，要特別注意兩個排序的規則：

• 第一，『中間塊』的排序規則，按照選中順序，還是在候選池中的固有順序，生成時間順序，文件大小順序，字幕排序，規則是什麼？正序還是倒序？
• 第二，『中間塊』加入『目標隊列』的規則，隊首還是隊尾？

小結

本篇主要介紹了跨頁、跨類、跨級多選中存在的操作陷阱，並提供『收集器』『列表構造器』『增項列表』等應對複雜多選問題的解決方案。

解決『跨級多選』問題目前並沒有優雅的方案。

所謂『多選大殺器』它們共同的特點是，能夠以較小的屏幕空間和操作代價，提供便捷的『辨識未選』、『操作選擇』、『辨識已選』、『取消選擇』、『明示不可選』。

多選可以級聯並嵌套使用，只要避開『多選陷阱』就能變化出多種形式。它們主要由『源列表』與『目標列表』兩部分組成，其中移動的中間塊的自身順序和加入『目標列表』的順序值得注意。

單選小坑，多選大坑

開篇提到：人類因有選擇而痛苦，沒有選擇，就沒有痛苦；仰天長嘯，交互設計中有關『選擇』的三篇文章終於完成。

前兩篇還是很輕鬆的，寫到多選，消耗了大概三天時間，因為問題極其複雜，害怕誤導諸位讀者，總之是寫了又刪，刪了再寫，往複成篇。

遇到界面上的選擇問題，相信都能夠從這三篇文章中汲取靈感，找到答案。

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

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

Hozin公眾號入口

擴展閱讀

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

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

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

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

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

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