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