后臺列表設計避坑指南(下)

2 評論 22343 瀏覽 115 收藏 11 分鐘

編輯導語:列表頁是后臺界面的重要組成之一,上篇說了后臺列表設計的“搜索”設計(詳情見:后臺列表設計避坑指南 上);本篇繼續講剩下的兩個部分的“坑”和必坑指南,我們一起來學習一下。

列表頁是構成后臺使用界面的重要組成之一,聚合了眾多信息并提供操作入口。

區別于小而美的C端產品列表,后臺系統的用戶希望列表的內容又多又全面(表格),但在操作時又能支持快速定位(搜索,包含篩選)、準確處理(操作)。

這需求貌似有些矛盾,但在很多場景下,例如客服在接待客戶時窗口時間極其短暫,既要全面獲取相關信息,又要快速應對解決客戶問題;因此這需求不僅合理而且是剛需。

列表頁由「搜索」、「表格」和「操作項」三大基本塊組成。剛才提到的矛盾點也是由這三個模塊之前的互相影響和制約(后面會詳細闡述)。

我們當初由于在設計時忽視了特定場景細節,以及生搬硬套了一些看起來很美很簡約的交互樣式,沒有處理好這三個模塊內部以及之間的關系,被用戶抱怨說不好用。

這篇文章就將「搜索」、「列表」、「操作」三塊問題進行分析和定位,盤點一下那些被淘汰掉的解決方案,給大家提供一份避坑指南。

注意,不存在“最好”的通用方案,只有應對具體需求“最合適”的解決方案。

二、列表

列表的主要問題依舊是內容太多帶來的:

  • 表頭字段太多,超出屏幕之外,左右滑動才能完整查看條目內容,導致眼動頻繁,增加認知負擔。
  • 條目太多,批量操作可能要多次翻頁。

另外,其他潛在問題也會增加列表展示的復雜性,例如條目之間存在一定相關性——基于某份主合同后續簽訂幾份補充合同(這里不討論業務邏輯合理性);那么簡單按照簽訂時間點排序,就無法體現合同之間的關聯關系。

在設計時,應著眼于避免內容太多導致的認知負擔和操作成本。我們嘗試了一些方法來減少信息噪音,抽象來說方法歸為兩個字——「藏」和「換」。

「藏」,就是隱藏低優先級信息,需要的時候才允許他們出現;「換」就是轉換信息呈現的形式;下面我們一一展開。

1. 方法一:藏

1)用戶來配置展示哪些表頭項

和之前提到的搜索區域配置功能類似,允許用戶配置表頭項,隱藏暫不需要的內容。

【工作小結】后臺列表設計避坑指南(下)

△ 設計者 Ashmita Bhattacharyya

2)使用展開行

適合主次層級對比強烈的列表。將重要度低的內容放入展開行內,這樣可以避免橫向滑動。

但如果同時查看多條展開行,需要多次點擊展開。

【工作小結】后臺列表設計避坑指南(下)

△ 圖片來自Element UI3、樹形數據

使用樹形數據可以將一組有父子關系的數據聚合呈現,類似文章一開始提到的主合同+補充合同的場景。

【工作小結】后臺列表設計避坑指南(下)

△ 圖片來自Element UI

2. 方法二:換

1)使用圖像代替文字

圖像比文字在信息傳遞上更直觀——原因是人們對圖像的處理效率遠高于閱讀和理解;利用清晰易懂的圖像可以將信息檢索效率提升一個數量級。

【工作小結】后臺列表設計避坑指南(下)

△ 圖片來自設計者Dwinawan2、合理的默認排序規則

常見的排序規則包含時間的正、倒序等;合理的排序規則,決定了首屏是否能呈現對用戶重要度更高的內容,以及操作反饋是否可見。

舉個例子,用戶新創建完成一個新條目后,列表按照創建時間正序排列,刷新后沒有任何變化,需要用戶翻到最后才能看見,那么這個反饋體驗就不太好。

我們也可以根據信息的狀態設置權重參數,綜合計算權重值后,重要度高的信息排在前面。

舉個微信的例子,大家是否發現訂閱號消息的排序并不是按照更新時間排序?

微信的解釋是——訂閱號消息排列順序會根據訂閱號的優質程度、用戶對訂閱號的喜愛程度以及群發文章的內容質量等綜合因素動態變化;也就是有多個權重參數值疊加,綜合排序。

另外還可以允許用戶將任意條目置頂等,例如微信可以將某人或某群組的消息置頂。

3. 注意

1)橫向滾動條

橫向滾動條在底部的話,可能因為列表條目太多(例如一頁展示50條),導致用戶未將列表拉到底就看不到滾動條;如果設備是觸屏,無法支持左右滑動會非常不便,因此列表頂部也需要展示橫向滾動條。

2)固定列

如果列表支持橫向滾動,那么選擇列、名稱等標識列、操作列等建議固定,便于定位和操作。

【工作小結】后臺列表設計避坑指南(下)

△ 頂部橫向滾動條、固定列

3)數字右對齊

在小數位保持一致的情況下,數字右對齊,更容易對比數字大小。

4)空數據

沒有的數據不要為空,可以用符號「-」代替。

【工作小結】后臺列表設計避坑指南(下)

△ 數字右對齊、空數據

三、操作

操作我們大致分成兩類來分析:

  • 批量操作,例如添加/導入、設置/分配、刪除、導出等。
  • 針對單條內容的操作,例如編輯、刪除、查看等。

1. 批量操作

批量操作相對復雜度高,出錯的概率也更大,以下幾條內容是我們設計摸索過程中總結出來的防錯策略:

  • 不建議支持跨頁選擇跨頁選擇首先會增加開發難度及測試復雜度,用戶操作也容易出錯;比如,在選擇過程中,已選擇數據的狀態可能在外部發生了變化,不再符合批量操作的條件,從而導致任務處理失敗。
  • 設置處理數目上限如果數據量太大,系統負擔過重,也會增加超時等任務失敗的頻率。
  • 協助計算在用戶選擇過程中動態計算合計值并實時反饋,防止用戶提交后才發現無法通過系統的校驗條件;例如用戶在批量還清多筆賬單時,可以在選擇頁面就提醒用戶所選金額超出賬戶余額限制,而不是在提交后才給用戶報錯。
  • 異步反饋有些操作數據量大,處理耗時較長,例如導出全量內容等,可采用異步的反饋方式,以避免耽誤用戶處理其他任務;依據場景,異步反饋還可采用多種通道保證信息傳達給客戶,例如系統內提示+短信+郵箱提示等。

2. 單條操作

1)列表的信息展示,我們會嘗試取舍和隱藏;但關于操作,在很多場景下,盡量全部展示,避免用戶需額外點擊才能將操作項喚出。

原因有二:降低學習成本、提升操作效率。

【工作小結】后臺列表設計避坑指南(下)

△ 圖片來自設計者Asish Sunny,設計方案將部分操作隱藏,不過在很多場景下并不適用

2)在展示上,可以使用圖標按鈕代替文字按鈕,但要注意語義一定要準確,不要過于追求創新導致語義和用戶心理模型產生偏差。圖標除了具有按鈕功能,還能提示信息狀態,一舉兩得。

【工作小結】后臺列表設計避坑指南(下)

△ 圖片來自設計者Aaron Iker

【工作小結】后臺列表設計避坑指南(下)△ 圖片來自設計者 Kirill Zhukovsky

3)在交互上,如果操作可以在彈窗內解決,盡量不要新開頁面。尤其是連續逐條處理的任務,如果頻繁切換頁面,用戶還要耗費時間重新定位任務條目。

 

作者:杜小杜,公眾號:能呆書房一整天

本文由 @杜小杜 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自?Unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 在交互上,如果操作可以在彈窗內解決,盡量不要新開頁面。尤其是連續逐條處理的任務,如果頻繁切換頁面,用戶還要耗費時間重新定位任務條目。
    這個很重要,我們目前的系統,就各種跳轉頁面,很累的啊

    來自北京 回復
    1. 有道理

      來自北京 回復