統計表格設計思路分享
編輯導語:在我們的日常工作中,經常會用到表格的形式進行排列,表格可以比較直觀清楚的表達出差異和變化,在職場中也能給我們提供一些幫助;本文作者分享了關于統計表格的設計思路,我們一起來了解一下。
筆者主要負責某B端產品數據統計相關的產品設計,本次主要分享一些關于統計表格設計相關的經驗和思考,請大家多多指教。
一、統計表格
表格是一種組織整理數據的手段,通過展示行、列數據進行可視化模式的交流。
一般情況下,當有大量結構化的數據需要展示時;當需要對數據進行排序、搜索、分頁、自定義操作等復雜行為時進行使用。
用戶通過數據表格查詢業務數據、了解業務情況,進而達到輔助決策的效果。
二、表格設計思路
當進行表格設計的時候,需要明確該表格要解決的問題是什么?
是否存在已有的數據表格可以解決該問題?能否通過優化當前表格來實現?
在這里就要引用《騰訊產品法》中作者所講:
“好的產品設計,就是運用數量有限的基礎能力,去實現高滿意度的功能?!?/p>
如果不能,那么必須新增表格來解決用戶的需求,下面筆者關于此問題進行分享。
通常來說表格主要包括兩個結構:①列表、②操作(搜索、篩選、導出)。
1. 如何篩選列表字段?
首先,依據用戶的目的篩選數據指標,將所有可能的字段全部列出,然后將核心的字段/最合適的字段展示出來。
然后,判斷數據源的狀態。 若數據來源的表單以“提交”為結點,并且提交之后字段無變化;那么筆者認為該列表為靜態列表,即使后續有其他的操作,也是以“整個表單”為維度的狀態變化,這樣的表格是比較好設計的。
如果表單自提交后,還可以對其中的數據進行修改,那么此列表為動態,這樣的表格就比較復雜了;此時列表數據字段的展示尤為重要,需要考慮數據變化(新增、刪除、更改)對列表的影響。
例如:酒店PMS系統的住宿訂單,具體字段包含:入住人信息(姓名/手機號/性別/民族/身份證/住址)、渠道來源、入住時間、房間號、間夜數、房費金額;收款、收押金、待收款;備注信息;其中,入住人信息可能不唯一(一個訂單可能有兩個入住人或者更多)、房間號也可能不唯一、收款、收押金、待收款等信息都會隨著操作進行變化。
這時候需要考慮:
1)如果字段不唯一,是否有必要全部展示;如果僅展示一個,對后續搜索是否存在影響。
例如上面所講的入住人信息,是否有必要將所有入住人展示出來;如果僅展示一個展示哪個,展示的信息是否支持修改/刪除,修改/刪除后取哪個字段;如果列表僅展示一個,搜索“其他入住人”時數據能否查詢成功。
2) 如果字段動態存在計算邏輯,是否可以直接展示”計算結果”,用戶對此的計算邏輯是否認同并理解。
例如上面的“收款”,用戶在一個訂單中可能操作多次收款,在這里可考慮展示“收款總和”。
2. 列表設計
1)在表格的設計原則中:第一列為列表的唯一標識,在數據中可看做“主鍵”;最后一列為各種操作。
通常來說第一列可采用“創建時間”或“ID”或“用戶名”等進行標識。
2)列表排序
通常情況可按照“唯一標識”進行倒序/正序排列。排列順序主要依據用戶在表格目的;例如:在餐飲行業的訂單中,訂單的創建時間進行倒序排列,用戶主要是期望看到新來的訂單進行排單制作。
在默認排序的基礎上是否需要設置特殊排序。例如:基于上面的訂單列表中,是否會有“接單”操作的概念;比如來自某些地區的訂單需要特殊處理,若有是否需要優先展示待處理的訂單;如果是這樣的話,需要在默認排序的基礎上增加操作/異常處理等維度進行排序。
3)列表分頁
分頁:筆者通常依據頁面內容、頁面布局,來設置每頁展示的數據量;進行分頁的好處是單次請求數據量少,響應速度快。
不分頁:若不進行分頁一次性請求數據過大是否會產生延遲,進而導致用戶的體驗差問題。
3. 列表操作
1)搜索:通過查詢關鍵字來快速定位目標數據,通常分為模糊搜索/精準搜索。
主要的交互形式如下:
2)篩選
列表上方增加篩選操作:
列表內增加篩選操作:
自定義的列篩選功能,并實現一個搜索列的示例。
多項篩選
導出:
“導出”操作按鈕通常是導出當前篩選數據結果。需要注意【導出】按鈕的層級位于篩選、查詢結果后。
三、其他
在設置列表的過程中經常會遇見列表字段過多/長影響頁面展示效果的情況,對于此問題我們可以通過一些交互手段進行規避。
1)固定頭和列:適合同時展示有大量數據和數據列
2)固定列:對于列數很多的數據,可以固定前后的列,橫向滾動查看其它數據
3)限制展示字段,鼠標懸停進行展示詳細信息
以上是筆者本次不成熟的分享內容,歡迎大家下方留言進行交流。
主要參考文章:
本文由 @美的人不生氣 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
- 目前還沒評論,等你發揮!