起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端交互組件之表格篇
編輯導語：在B端產品中，表格的利用率是很高的，同時，由于數據是及其重要性的，所以表格組件的設計尤為重要。接下來，本文作者將表格拆分成多個細節，詳細地講解各部分應該如何設計，以及復雜業務場景下如何利用表格，讓我們來一起學習吧。
B端項目或產品中，表格應該是被利用的最多的了，很多主體界面基本都會用到表格組件。我們常說一個基本的功能是包含增刪改查的，為了完整的表達這一功能，常見的就是用表格組件。
B端產品中數據是關鍵，而表格主要是用于展示和管理數據，如何用好表格，對產品整體的用戶體驗起到重要作用。
目前有很多數據也可以用可視化圖表來展示，但僅僅只是用于最終的數據輸出，數據管理還是傾向于用表格組件。
下面我將表格拆分成多個細節，并詳細講解各部分如何來設計，另外還會談談復雜業務場景下如何利用表格。
一、查詢
常見的就是查詢區域在頭部，下面緊接著一個表格組件。
當數據量小的時候，打開該頁面時，應該是可以看到全量數據的，并通過分頁器來部分加載數據；如果數據量很大，例如億級單位的數據量，系統估計會直接崩潰，所以需要對查詢結果做條件限制。
1.?沒有必輸條件
這種模式就是常見的，打開頁面可以看到所有數據，通過查詢條件進一步縮小搜索范圍。
值得注意的是查詢條件都是非必填項，當你輸入一個或多個條件查出結果后，點擊重置按鈕后再點查詢，即可恢復為全量查詢結果。
如下圖所示：
2.?有必輸條件
本次說的重點是這種有必填查詢條件的情況，打開頁面時看不到數據，查詢條件含有必填項，一個或多個；不輸入查詢條件，直接點擊查詢按鈕會提示必填字段必須輸入，此方式主要用于縮小查詢范圍。
必填查詢條件輸入后，其他非必填查詢條件也可以搭配輸入，進一步縮小查詢范圍。
如下圖所示：
3.?反顯查詢條件
有些系統，根據權限控制要求，一些查詢條件需要反顯，并根據業務要求控制是否可以修改，不可修改的可以置灰。
反顯固定值，如下圖所示：
反顯值可修改，如下圖所示：
很多時候是系統在用戶輸入沒權限的條件時再做校驗，好的用戶體驗就是容錯，可以避免用戶去犯錯。
這里涉及到權限的條件可以固定反顯某個值，或者反顯可以修改的一些值，用戶不管怎么選，都有權限來查，這樣可以避免用戶被提示無權限查詢時的焦慮感。
二、按鈕
B端產品使用按鈕的地方很多，本文主要談談表格的頭部按鈕和右側按鈕。
1.?頭部按鈕
頭部按鈕主要是用于不需要選擇表格數據的操作按鈕，最常用的就是新建功能。
另外就是支持批量操作的功能按鈕，例如導出和刪除，勾選一條或多條導出；不勾選時導出所有，勾選多條數據，批量刪除。批量操作時，表格最左側需要搭配復選框元件。
如下圖所示：
2.?右側按鈕
右側按鈕主要是針對單條數據操作的按鈕，例如查看、修改、刪除等。
如果放在頭部，需要勾選一條數據來操作，勾選多條或者不勾選數據點擊按鈕時，系統都需要校驗；其實也提高了用戶的認知成本，所以我覺得這類操作按鈕可以全部放到右側來。
對于不同數據，功能按鈕根據權限不同來設計，可以免去校驗的認知成本，用戶可以直接上手操作，也可避免犯錯時的焦慮感。
例如有些數據不能修改和刪除時，就可以直接在右側不顯示，避免點擊后再去提示用戶。
如下圖所示：
另外這里有個關鍵點，當表格中的字段很多或者數據內容很多時，會出現橫向滾動條，用戶很有可能看不到右側的操作列，這種體驗是很糟糕的。
這里需要將操作列固定在最右側，另外左側的復選框也可以配合固定在最左側，因為當滾動條往右拖動時，也會看不到左側復選框區域，不便于用戶去操作導出或者其他功能操作。
三、表頭
正常的表頭都是單層，有時候也會有多層的表頭，另外還可以對表頭進行配置，有的是直接在表頭處配置，有的是去系統管理單獨配置。
1.?普通表頭
這種情況是最常見的，表頭字段都是單獨排列，有的會把排序直接放在表頭操作，例如下拉箭頭，可以選擇降序或者升序等。
如下圖所示：
如果需要對字段進行組合排序，也可以將排序功能單獨做成一個功能按鈕來操作。
2.?復雜表頭
復雜表頭主要是指有多層結構的表頭，有時候表頭是普通的，但是數據內容是多層的，就看具體業務情況了，我們的設計主要是為了提高業務操作效率。
如下圖所示：
3.?表頭篩選
具體展示哪些表頭，也不是一成不變的，可能有些系統是固定的值，這也是在前期需求分析時，跟業務確定下來的；就是該業務場景下，這些字段不存在變化，當然就不需要對表頭內容修改了。
但是也才存在一些需要對表頭內容修改的場景，比如默認有一套表頭字段，但是根據不同用戶，可以選擇不同的表頭字段配置。這種是由用戶選擇不同模式，還有一種就是由用戶自定義來配置。
根據用戶不同配置不同的表頭字段，主要是考慮到不同崗位的用戶，查看數據的視角不一樣，對應的關心的字段也會不一樣。如果前期需求分析階段，可以很清晰的確定這些，可以設計成讓用戶選擇崗位來展示不同的表頭字段。
如下圖所示：
如果不是很確定，也可以全部讓用戶自定義，或者兩者結合起來用。比如：可以根據崗位先選擇一套表頭字段，另外用戶也可以自定義再調整。
如下圖所示：
另外還有種情況，就是把表頭字段的設置放到系統管理中來配置，也可以理解為不讓普通用戶來配置，只讓系統管理員來控制表頭字段。
如下圖所示：
可以批量選擇表頭字段，也可以批量刪除掉。
四、行
行主要是針對數據而言，比如行數據展示、選擇行、鼠標滑過行等，同時需要配合左側選擇框來使用。
1.?行數據展示
當數據很多時，密密麻麻堆積在表格內，用戶很容易看錯位，把A行的數據看成B行的。為了有效解決這種問題，最常用的就是用間隔行背景色，就是間隔行設置一個不同的背景色。
如下圖所示：
2.?滑過行
滑過行主要是鼠標滑過某行數據時，給一個滑過顏色，也是輔助方便用戶查看數據的一種手段。
如下圖所示：
3.?選擇行
選擇行主要是針對選中某行時的背景色變化，這里可以配合左側選擇框來使用。
如果只支持單行選擇，左側可以用單選框，選中某行時，除了背景色變化外，左側單選框也是選中狀態；選中其他行時，選中狀態即可切換過來。
如下圖所示：
如果支持多行選擇，左側可以用復選框，選中某行時，除了背景色變化外，左側復選框也是選中狀態，繼續選擇其他行后，可以增加這種選中狀態。
如下圖所示：
五、數據對齊
數據對齊也是一種方便用戶查看數據的手段，包含三種對齊方式：左對齊、居中對齊、右對齊，另外表頭一般是采用居中對齊方式。
下面我將詳細講解下三種對齊方式主要用于哪種場景下：
1.?左對齊
左對齊一般針對字符串類型的數據，例如賬號、文件名等。這種數據長度不固定的，為了有一個良好的展示效果，一般是左對齊，并且給一個左側間距。
如下圖所示：
2.?居中對齊
居中對齊一般針對固定長度類型的數據，比較常見的就是含下拉值的字段，并且下拉值不太多的情況，例如性別、狀態等。
如下圖所示：
3.?右對齊
右對齊一般針對金額類數值型數據，有的可能還固定含有兩位小數點，可以根據具體業務情況來設計。
如下圖所示：
六、分頁器
分頁器一般在表格底部，只要是數據量不是太少的情況，一般都會有分頁器的，主要是對數據進行分段刷新。
分頁器樣式有很多種，在此就不詳細舉例了。
如下圖所示：
七、復雜表格
以上說的都是正常單層表格的各種細節問題，在一些復雜的業務場景下，經常會出現多層表格，可以設計成多層結構或聯動結構。
1.?多層表格
多層表格常出現于有父子級關系的場景，并且父子級都包含新建、修改、刪除等功能。
另外子級表格需要關聯父級表格，如果父級表格目前數據為空，子級表格是不能新建的；如果父子級的字段都是獨立的，這里可以在子級中加一個用于關聯父級的字段，這樣就將父子級串聯起來了。
兩層的比較好設計，就是兩個表格上下擺或者左右擺即可。
如下圖所示：
多層可能不止兩層，可能是三層或者四層，還有的系統為了擴展性，可以無限地增加層級。這樣業務結構就看著很復雜了，作為設計師而言，我們就是要將復雜的業務給簡單化，提高業務人員操作效率。
多層的正好之前有過經歷，我將父級和子級拆分開了，父級和中間子級放一起，最終子級單獨放，具體怎么拆，要看業務情況了。
我之前設計的是命題系統，從產品那里獲取的用戶操作習慣，一般是先把大題命好，就是總分多少、每個題型多少分、題型層級如何等。
感覺就是先搭好框架，然后再把小題命好。根據這種業務規則，我就將父級與中間子級放一起了，作為大題，最終子級作為小題。
比如語文試卷中，首先分為基礎語言部分、閱讀理解部分、寫作部分，然后基礎語言部分又分好幾種題型，每個題型下面又有多個小題，這樣看差不多就是三層結構了。
實際情況可能比這復雜，子級題型可能又分為A部分和B部分，所以命題系統的層級關系是要支持無限拓展的。
如下圖所示：
小結：B端產品設計有時候并沒有所謂的標準答案，到底如何設計，確實要根據實際的業務場景來定；我們的使命本來就是賦能業務，提高業務的操作效率。
如果說業務線下的操作習慣，你不去遵循，違背了業務的心理模型，這樣設計出來的產品才真叫不好用，并且也加大了業務培訓成本。
2.?聯動表格
多層表格如果不設置關聯字段，也可以采用聯動的方式。
比如選中父級表格中某行數據，子級表格數據會跟著變動，這里子級表格的數據是根據父級表格選中的行來變化的，每次只展示某個父級行的子級數據。
如下圖所示：
這里要區別下多層表格，多層表格的子級表格是展示的全量子級數據，所以當數據量很大時，可以采用聯動表格方式，具體還是看實際業務情況了。
回到前面說的命題系統，小題部分我就是設計成聯動的模式，選中大題或者子級可以看到對應的小題。因為大題層級可以無限拓展，設計成多層表格，到小題這里看著就會很亂了，所以我采用聯動表格，小題每次只展示對應大題的。
如下圖所示：
八、總結
以上便是我將表格組件拆分后的詳細情況，組件是死的，人是活的。遇到具體的業務場景，還是需要設計師活學活用，多考慮下業務的心理模型，不要讓表現模型趨近于實現模型，或者說開發模型。
舉個例子：很多時候開發會覺得某個設計太麻煩了，實現起來耗時耗力。因為開發只是站在實現模型角度考慮問題，作為交互設計師，我們就要學會平衡模型的兩邊，盡量讓表現模型趨近于業務心理模型，這樣才能打造出讓業務尖叫的產品。
作者：D.cheerful，微信號：dcf8859，8年B端交互設計經驗。
本文由 @D.cheerful 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels，基于 CC0 協議
我想請教個問題，甲方總是提出在分頁表格的表尾加上合計，針對某幾列數字型進行合計，并且是兩個合計，一個人當前頁合計，一個是所有頁合計，我一直都很反感這個需求，我該如何解釋并拒絕
在表格上方加個統計
你好，可以請教下這個反顯查詢條件是什么嗎？查了下，網上說是查詢條件重置，但是你那上面有重置按鈕，不太懂，感謝??
根據用戶權限自動判斷的，比如你是湖北分行用戶，機構查詢條件就只能是湖北分行；如果是總行用戶，機構查詢條件則是所有的一級分行，例如湖北分行、浙江分行等
嗯嗯，好的，感謝
個人感覺表格篇寫的太泛了沒有解釋性：
首先是查詢統計對于條件的限制沒有體現。
其次查詢后的結果如何展示如何查看，以及常規查統如何呈現界面規則，大量的篇幅去寫了比較細的如hover樣式，選中樣式、聯動表格（某種意義我不認為這是一種好的解決方案）。
表格篇我覺得作者還可以繼續深挖一下，目前寫的內容只是暴露了表格篇作者遇到的情況還不夠多。希望再開新坑，再次書寫！
組件的幾篇文章其實都寫得很泛，主要是對之前項目經歷的一種回顧以及個人的一些看法，有了新項目的感悟，后期會修正補充的
恩恩，期待更新！
這個真不錯，我一個專注于b端產品的公眾號想轉載這幾篇文章，可以么？
可以轉載
再加幾個 例如自定義表格單元右鍵事件，表格監聽鍵盤事件，提供表格快速編輯能力。
建議很好，只是我以前的項目沒有經歷過這些，學習了