列表頁是構(gòu)成后臺(tái)使用界面的重要組成之一，聚合了眾多信息并提供操作入口。區(qū)別于小而美的C端產(chǎn)品列表，后臺(tái)系統(tǒng)的用戶希望列表的內(nèi)容又多又全面（表格），但在操作時(shí)又能支持快速定位（搜索，包含篩選）、準(zhǔn)確處理（操作）。這需求貌似有些矛盾，但在很多場(chǎng)景下，例如客服在接待客戶時(shí)窗口時(shí)間極其短暫，既要全面獲取相關(guān)信息，又要快速應(yīng)對(duì)解決客戶問題。因此這需求不僅合理而且是剛需。
列表頁由「搜索」、「表格」和「操作項(xiàng)」三大基本塊組成。剛才提到的矛盾點(diǎn)也是由這三個(gè)模塊之前的互相影響和制約（后面會(huì)詳細(xì)闡述）。我們當(dāng)初由于在設(shè)計(jì)時(shí)忽視了特定場(chǎng)景細(xì)節(jié)，以及生搬硬套了一些看起來很美很簡(jiǎn)約的交互樣式，沒有處理好這三個(gè)模塊內(nèi)部以及之間的關(guān)系，被用戶抱怨說不好用。這篇文章就將「搜索」、「列表」、「操作」三塊問題進(jìn)行分析和定位，盤點(diǎn)一下那些被淘汰掉的解決方案，給大家提供一份避坑指南。
注意，不存在「最好」的通用方案，只有應(yīng)對(duì)具體需求「最合適」的解決方案。
列表的主要問題依舊是內(nèi)容太多帶來的：
- 表頭字段太多，超出屏幕之外，左右滑動(dòng)才能完整查看條目?jī)?nèi)容，導(dǎo)致眼動(dòng)頻繁，增加認(rèn)知負(fù)擔(dān)。
- 條目太多，批量操作可能要多次翻頁。
另外，其他潛在問題也會(huì)增加列表展示的復(fù)雜性，例如條目之間存在一定相關(guān)性——基于某份主合同后續(xù)簽訂幾份補(bǔ)充合同（這里不討論業(yè)務(wù)邏輯合理性），那么簡(jiǎn)單按照簽訂時(shí)間點(diǎn)排序，就無法體現(xiàn)合同之間的關(guān)聯(lián)關(guān)系。
在設(shè)計(jì)時(shí)，應(yīng)著眼于避免內(nèi)容太多導(dǎo)致的認(rèn)知負(fù)擔(dān)和操作成本。我們嘗試了一些方法來減少信息噪音，抽象來說方法歸為兩個(gè)字——「藏」和「換」！覆亍梗褪请[藏低優(yōu)先級(jí)信息，需要的時(shí)候才允許他們出現(xiàn)！笓Q」就是轉(zhuǎn)換信息呈現(xiàn)的形式。下面我們一一展開。
方法一：藏
用戶來配置展示哪些表頭項(xiàng)
和之前提到的搜索區(qū)域配置功能類似，允許用戶配置表頭項(xiàng)，隱藏暫不需要的內(nèi)容。
△ 設(shè)計(jì)者 Ashmita Bhattacharyya
使用展開行
適合主次層級(jí)對(duì)比強(qiáng)烈的列表。將重要度低的內(nèi)容放入展開行內(nèi)，這樣可以避免橫向滑動(dòng)。
但如果同時(shí)查看多條展開行，需要多次點(diǎn)擊展開。
△ 圖片來自Element UI
樹形數(shù)據(jù)
使用樹形數(shù)據(jù)可以將一組有父子關(guān)系的數(shù)據(jù)聚合呈現(xiàn)，類似文章一開始提到的主合同+補(bǔ)充合同的場(chǎng)景。
△ 圖片來自Element UI
方法二：換
使用圖像代替文字
圖像比文字在信息傳遞上更直觀。原因是人們對(duì)圖像的處理效率遠(yuǎn)高于閱讀和理解。利用清晰易懂的圖像可以將信息檢索效率提升一個(gè)數(shù)量級(jí)。
△ 圖片來自設(shè)計(jì)者Dwinawan
合理的默認(rèn)排序規(guī)則
常見的排序規(guī)則包含時(shí)間的正、倒序等。合理的排序規(guī)則，決定了首屏是否能呈現(xiàn)對(duì)用戶重要度更高的內(nèi)容，以及操作反饋是否可見。舉個(gè)例子，用戶新創(chuàng)建完成一個(gè)新條目后，列表按照創(chuàng)建時(shí)間正序排列，刷新后沒有任何變化，需要用戶翻到最后才能看見，那么這個(gè)反饋體驗(yàn)就不太好。
我們也可以根據(jù)信息的狀態(tài)設(shè)置權(quán)重參數(shù)，綜合計(jì)算權(quán)重值后，重要度高的信息排在前面。舉個(gè)微信的例子，大家是否發(fā)現(xiàn)訂閱號(hào)消息的排序并不是按照更新時(shí)間排序？微信的解釋是，訂閱號(hào)消息排列順序會(huì)根據(jù)訂閱號(hào)的優(yōu)質(zhì)程度、用戶對(duì)訂閱號(hào)的喜愛程度以及群發(fā)文章的內(nèi)容質(zhì)量等綜合因素動(dòng)態(tài)變化。也就是有多個(gè)權(quán)重參數(shù)值疊加，綜合排序。
另外還可以允許用戶將任意條目置頂?shù)，例如微信可以將某人或某群組的消息置頂。
注意
橫向滾動(dòng)條。橫向滾動(dòng)條在底部的話，可能因?yàn)榱斜項(xiàng)l目太多（例如一頁展示50條），導(dǎo)致用戶未將列表拉到底就看不到滾動(dòng)條。如果設(shè)備是觸屏，無法支持左右滑動(dòng)會(huì)非常不便，因此列表頂部也需要展示橫向滾動(dòng)條。
固定列。如果列表支持橫向滾動(dòng)，那么選擇列、名稱等標(biāo)識(shí)列、操作列等建議固定，便于定位和操作。
△ 頂部橫向滾動(dòng)條、固定列
數(shù)字右對(duì)齊。在小數(shù)位保持一致的情況下，數(shù)字右對(duì)齊，更容易對(duì)比數(shù)字大小。
空數(shù)據(jù)。沒有的數(shù)據(jù)不要為空，可以用符號(hào)「-」代替。
△ 數(shù)字右對(duì)齊、空數(shù)據(jù)
操作我們大致分成兩類來分析
- 批量操作，例如添加/導(dǎo)入、設(shè)置/分配、刪除、導(dǎo)出等。
- 針對(duì)單條內(nèi)容的操作，例如編輯、刪除、查看等。
1. 批量操作
批量操作相對(duì)復(fù)雜度高，出錯(cuò)的概率也更大，以下幾條內(nèi)容是我們?cè)O(shè)計(jì)摸索過程中總結(jié)出來的防錯(cuò)策略：
不建議支持跨頁選擇
跨頁選擇首先會(huì)增加開發(fā)難度及測(cè)試復(fù)雜度，用戶操作也容易出錯(cuò)。比如，在選擇過程中，已選擇數(shù)據(jù)的狀態(tài)可能在外部發(fā)生了變化，不再符合批量操作的條件，從而導(dǎo)致任務(wù)處理失敗。
設(shè)置處理數(shù)目上限
如果數(shù)據(jù)量太大，系統(tǒng)負(fù)擔(dān)過重，也會(huì)增加超時(shí)等任務(wù)失敗的頻率。
協(xié)助計(jì)算
在用戶選擇過程中動(dòng)態(tài)計(jì)算合計(jì)值并實(shí)時(shí)反饋，防止用戶提交后才發(fā)現(xiàn)無法通過系統(tǒng)的校驗(yàn)條件。例如用戶在批量還清多筆賬單時(shí)，可以在選擇頁面就提醒用戶所選金額超出賬戶余額限制，而不是在提交后才給用戶報(bào)錯(cuò)。
異步反饋
有些操作數(shù)據(jù)量大，處理耗時(shí)較長(zhǎng)，例如導(dǎo)出全量?jī)?nèi)容等，可采用異步的反饋方式，以避免耽誤用戶處理其他任務(wù)。依據(jù)場(chǎng)景，異步反饋還可采用多種通道保證信息傳達(dá)給客戶，例如系統(tǒng)內(nèi)提示+短信+郵箱提示等。
2. 單條操作
列表的信息展示，我們會(huì)嘗試取舍和隱藏。
但關(guān)于操作，在很多場(chǎng)景下，盡量全部展示，避免用戶需額外點(diǎn)擊才能將操作項(xiàng)喚出。原因有二：降低學(xué)習(xí)成本、提升操作效率。
△ 圖片來自設(shè)計(jì)者Asish Sunny，設(shè)計(jì)方案將部分操作隱藏，不過在很多場(chǎng)景下并不適用。
在展示上，可以使用圖標(biāo)按鈕代替文字按鈕，但要注意語義一定要準(zhǔn)確
不要過于追求創(chuàng)新導(dǎo)致語義和用戶心理模型產(chǎn)生偏差。圖標(biāo)除了具有按鈕功能，還能提示信息狀態(tài)，一舉兩得。
△ 圖片來自設(shè)計(jì)者Aaron Iker
△ 圖片來自設(shè)計(jì)者 Kirill Zhukovsky
在交互上，如果操作可以在彈窗內(nèi)解決，盡量不要新開頁面。
尤其是連續(xù)逐條處理的任務(wù)，如果頻繁切換頁面，用戶還要耗費(fèi)時(shí)間重新定位任務(wù)條目。
承擔(dān)因您的行為而導(dǎo)致的法律責(zé)任，
本站有權(quán)保留或刪除有爭(zhēng)議評(píng)論。
參與本評(píng)論即表明您已經(jīng)閱讀并接受
上述條款。