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

初學交互設計，照貓畫虎未嘗不可。然而，臨摹過程中，控制設計師的慾望，需要刻意練習。因為縱慾無度，不小心寫了4500字，夠看半小時。

整理不斷膨脹的慾望

例如，設計教務系統當中的學籍管理模塊，其中包含一個列表，產品經理提供的需求通常是類似『數據字典』的東西：

開始設計之前，對數據項目進行一下分析：

唯一約束型

比如『學號』，這類不允許重複出現、也不允許重複利用的項目，通常作為資料庫主鍵存在。它們通常不太容易記憶。當然對於ToB產品來說，強制運營人員用唯一約束溝通是具有一定優勢：非常高效。

個性化+靜態文本型

比如『姓名』，這類可以任意填寫，一旦保存就幾乎不會改變的項目。作為查詢條件，比『學號』更容易記憶。

限定+靜態文本型

比如『性別』『民族』，這類在某個限定範圍中的單選，一旦保存就幾乎不會改變的項目。布爾值（是或否），可以視作一種特殊的限定靜態文本類型。通常作為篩選條件存在，非此即彼。

自增數字型

比如『年齡』，這類以某個固定時間周期不斷自我增加的項目。區間篩選、排序，兩者皆可。

自定義數字型

比如『身高』『體重』，這類可以任意填寫的數字項目。區間篩選、排序，兩者皆可。

靜態日期型

比如『生日』和『入學年份』，代表某個裡程碑時刻的日期時間項目，一旦保存就不會改變。區間篩選、排序，兩者皆可。

狀態型

比如某學生的狀態可以在『在讀』『借讀』『肄業』『畢業』……等一系列限定範圍之內切換。通常是系統自動更新，最主要的篩選項目。

多值數組型

比如『職務』，即是班長，同時兼任團支部書記。允許多個值，使用分隔符組成一個數據。組成數組的值，可以是某個限定範圍的，也可以是完全無限定的離散量。如果是限定範圍的多值數組，可以進行篩選。

累加記錄型

比如『三好學生』，實際上指獲得此類榮譽的次數，背後蘊含另外一個相關列表的統計。

假如把需求當中的數據項統統扔進列表，大概是下面的設計：

根本看不清，對吧？因為縱列太多！並且，隨著產品迭代和業務深化，整個列表的項目會越來越多，遠遠超過屏幕寬度所能承受。

縱列臃腫，造成橫向滾動，這種設計無論是桌面端還是移動端，都將帶來巨大的可用性問題。某些設計師朋友們提議：使用流行的『卡片式設計』能解決這個問題呀？沒錯，卡片式設計的確可以避免縱列太多的問題，但是，當每個卡片內容超過屏幕高度的時候，使用效率會非常低。

面對這樣的窘境，設計師必須要大刀闊斧進行縮減設計，竅門就是用戶任務顆粒度的控制。

明確用戶任務

基於『學生列表』，或許需求已經明確指出，並且設計師們還可以腦補出非常多的『使用場景』，諸如下面：

• 通過姓名、身份證、家長姓名、家長手機號碼能精確找到某個學生；
• 通過『在讀』和『班級』能準確輸出當前在某個班的在讀學生名單；
• 利用『畢業年份』篩選，快速找到『某一屆畢業生』的數量和名單；
• 利用『轉學』『退學』篩選，統計歷年生源的流失情況；
• 通過篩選年齡，排序身高、體重，可以得出學生們的身體發育情況；
• 通過篩選入學年份和年級，可以獲取『留級』的學生名單；

除此以外，可能還有：

• 根據狀態和當前用戶許可權，對某個學生的資料進行增刪改查操作；
• 對多個學生的資料進行批量操作，或者批量導入導出功能；

當然，只要腦洞足夠大，還能擴展出很多『好玩的場景』；當然，所謂『場景』越來越多的時候，設計們會發現要思考的維度越來越多，最後腦力枯竭了！這就是很多新手設計師經常遇到的問題，『控制不住膨脹的慾望』。

在此，Hozin提出一個值得爭議觀點：實際上，『場景』可能是個有害的東西！設計師完全沒有必要思考太多的場景，只要將用戶任務高度解耦，回歸『一個界面一個用戶任務』的原則，實現『以不變應萬變』。

學生列表，這個界面的核心用戶任務是什麼呢？其實只有一個：

查找某一條或某幾條學生數據，無它。

為了完成這個任務，必須先搞清楚另外一個問題：

如何區分兩條學生數據，無它。

思考第一個問題：在生活中，如何區分一個人和另外一個人呢？

• 名字，的確很方便，但是『同名同姓』的情況大量存在；
• 面孔，的確很方便，但是圖片不容易量化描述，並且體貌特徵相似的情況也存在（孿生），同名同姓並且面貌相似也是存在的，雖然概率非常低；

於是，在生活中，有了『身份證號碼』這樣的東西，徹底區分兩個自然人，但是它的劣勢也很明顯，不太容易記住！

思考第二個問題：對於學校來說，僅靠身份證號碼能夠實現區分學生嗎？

抱歉，這還真存在問題！身份證號碼的確能區分學生，但是對學籍來說並非唯一條件：

• 學生甲，從本校初中3年制畢業，又考入本校高中部，就會產生兩條學籍記錄；
• 學生乙，從本校初一年級轉學，一年後，回到本校初三年級借讀，也有可能產生兩條學籍記錄；

基於上面兩個問題，設計師應該明白：雖然數據記錄是『學籍』維度，但『學生列表』包含另外一個隱含維度『自然人』！

控制慾望，減法設計

生活中，的確不存在同一個人同時就讀初中和高中的情況；但是在高等教育中，存在同一人同時就讀兩個專業（雙學位，部分學分共用）的情況，為了讓系統兼容更多的業務，需要對數據做『學籍』和『自然人』兩個維度的區分。

同時，還可以進行另外一項工作：區分哪些項目可以進行搜索、篩選、排序操作。

• 唯一約束和自由填寫項目，通常可以進行搜索，比如『學號』、『姓名』、『身份證號碼』、『家長姓名』、『家長手機』；
• 限定範圍的項目，通常可以進行篩選，比如『性別』、『民族』，對於數字和日期時間格式，可以進行區間篩選，比如『生日』、『身高』、『體重』；
• 所有的數字和日期時間格式，都可以進行排序操作，比如『生日』、『身高』甚至『三好學生』這樣的統計項目；

有關搜索、篩選、排序，實在太複雜，Hozin將在後續文章中專門來寫，此處點到為止。

在『自然人』維度，Hozin保留了如下的數據項目：

照片

考慮到Face To Face快速確認身份；

姓名

搜索最便捷的搜索項目，使用率會是最高的；

性別

為同名同姓準備的第一道防線；

年齡

輔助照片共同完成Face To Face確認身份；

身份證後八位

同時代替了生日數據，作為同名同姓的最後一道防線；

在『學籍』維度，Hozin保留了如下數據項目：

學號

唯一約束主鍵，比姓名搜索更高效，給運營人員使用；

班級

由於數據記錄落在了『學籍』維度，因此把狀態和班級進行了合併；『在讀』直接顯示『年級+班級』，其他情況直接顯示『發生年份』+『已轉學』『肄業』『畢業』；『借讀』情況單獨說明。

根據以上的減法，Hozin分別重新設計了桌面端原型：

當然，也包括移動端『卡片式設計』的原型：

並且，以『學籍』為維度，允許同一個自然人出現兩次，比如當查詢某個用戶時，可能的結果是：

至此，彷彿完成了『學生列表』這個界面的核心用戶任務：查找某一條或某幾條學生數據。為什麼是『彷彿完成』呢？請往下繼續看吧

『最簡列表』的擴展設計

上面那個『最簡』設計，Hozin預估會有以下兩種不同的聲音：

第一種聲音來自產品經理和其他設計師：神啊，雖然是簡單了，但是，如果想知道有哪些同學是共青團員怎麼辦？如果想知道2017年哪些同學留級了怎麼辦？如果想統計初二年級的身高體重怎麼辦？

第二種聲音來自程序員：這活沒法幹了，數據介面都寫好， 這數據項變化也太大了，交互設計師這麼搞，是要返工重來吧，想讓程序員集體辭職？

ok，這些問題有辦法應對么？

回答產品經理：

1.政治面貌的按照『共青團員』篩選，將是下面這樣的列表：

2.想知道哪個同學留級了，將是下面這樣的列表：

3.除了根據篩選項/排序項聯動，甚至可以讓用戶自己控制顯示列表中的哪些其他項目：

4.關於『統計』相關功能，有可能違背了『一個界面一個用戶任務』的原則，需要設計專門完成統計任務的新界面。Hozin將在後續文章中專門來寫，此處點到為止。

回答程序員：

心智模型和實現模型，是兩件事。這樣的設計並沒有影響資料庫設計，底層數據介面也無需重寫，只是前端工程師要根據界面交互對數據進行二次加工。

配合使用，優雅的起舞

如果，經歷撕逼、拉鋸式評審和種種磨難，終於完成了界面的高度解耦，回歸了『一個界面完成一個用戶任務』的根本原則。那麼就來看看，這個『學生列表』完成對學籍的管理，還需要哪些其他界面：

學籍記錄詳情

針對某一條學籍記錄展開，包括入學信息、畢業信息、職務、學分等，包含各種變動記錄的統計入口；

自然人卡片

屬於這個用戶本身的屬性，包括身體變化，學籍變遷，家長家庭信息，也包括在各個學習記錄下的各種變動統計入口；

各種變動記錄

圍繞這個自然人，在各個學籍記錄下的各種單項的變化歷史記錄；

這些界面之間的運作關係，如下圖示意：

具體到列表界面原型交互，可能有如下設計：

控制『操作』的慾望

在列表設計中，遇到批量操作問題，已經在交互水深 06 | 單選小坑，多選大坑（下篇）有過相關討論，各位讀者已經成竹在胸。但是，對單條記錄進行操作也要有節制！

假如不加節制，單條記錄的操作，可能會變成這樣子：

產生這種情況的原因有兩種：

第一，每條記錄狀態不同，會擁有不同的操作項目；

第二，當前用戶許可權不同，也會擁有不同的操作項目；

這樣設計的問題也顯而易見：

第一，可能操作區非常靠近，此時，既要確認目標記錄，又要從多個操作中選擇某一個，此時誤操作的可能性非常高！即便設計成下拉框操作，依然存在誤操作風險！

第二，因為不同記錄可能存在操作順序不一樣，上下移動滑鼠會存在不同操作，用戶代價非常高。當然，可以設計成下面這樣，但是很吃藕！

第三，浪費大量的屏幕空間！見上圖↑↑↑↑↑↑

第四，浪費開發工作量！因為在列表中實現一系列許可權判斷和操作，在詳情界面中往往還需要再開發一次相同的許可權判斷和操作；

綜上所述，Hozin推薦的做法是：對於列表中的單條記錄，只有一種『管理』或『查看』操作，所有其它的單獨操作都去往該記錄的詳情界面完成。

這樣設計的優勢顯而易見：

第一，界面高度解耦，功能迭代方便，節約開發工作量；

第二，列表界面操作高度一致性，利於養成用戶習慣；

第三，在詳情頁用戶會明顯確認目標記錄，幾乎不會誤操作；

第四，列表界面將節約大量屏幕空間；

小結

按照『一個界面完成一個用戶任務』原則，推薦以下步驟進行『列表設計』：

首先，對數據項目進行分類整理，區分變化與不變，限定與自由；

其次，明確列表的核心任務是『找到目標，無它』，然後具體問題具體分析；

再次，根據核心任務逐一辨別數據項目，生成『最簡設計』；

進而，在『最簡設計』的基礎上利用聯動進行擴展變化，必要時提供用戶自定義項目功能；

最後，列表界面要和詳情界面、變動記錄界面配合完成更多的用戶任務。

『場景』對設計師可能是有害的，應該將界面高度解耦，努力尋找『以不變應萬變』的設計方法！

批量操作使用收集器完成；單條記錄操作應該儘可能放入詳情界面，而不是在列表界面浪費屏幕空間和開發資源。

總之，每當面對複雜問題，請設計師別想太多，縮小思考範圍，『控制自己的慾望』。

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

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

Hozin公眾號入口

擴展閱讀

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

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

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

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

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

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

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