案例解析｜10個表格加分項設計（加了億點點細節）
在日常業務場景中，表格這一元素是十分常見的，不過不少人卻還是不能將表格設計得盡善盡美。不過我們也不能妄想解決所有場景下的表格設計問題，所以不如選擇從常見問題入手展開設計，比如本文作者便總結了表格設計常會面臨的問題及解決方案，一起來看看吧。
在之前我們分享過一篇關於表格設計的詳解，比較系統地分享了表格設計的思路和流程。文章連結：年前最後一篇長乾貨，B端表格規範最終集奉上。
但表格設計細節太多了，光靠一篇系統性的分享肯定無法覆蓋所有場景和問題，所以本篇內容主要集中在表格設計中面臨的常見問題展開：
單元格的組成和內間距應用；
單元格尺寸設定和響應邏輯；
單元格的內容型別；
單元格內的文字樣式；
單元格的內容堆疊；
單元格的對齊模式處理；
表格中的批次操作；
表格內容的修改；
堆疊表頭的設計要點；
序號和 ID 的認識。
一、單元格的組成和內間距應用
每個表格都是由若干矩形單元格組成的，單元格內可以包含對應的圖片、圖示、按鈕、文字內容。當我們設計一個表格的時候，不管你有沒有使用線段來分割出每個單元格，都需要用這種網格模式完成表格的佈局。
這意味著，單元格之間是沒有間距的，它們相互之間是緊密貼合在一起的，而不是透過外邊距控制佈局的。
在此基礎上，為了防止單元格內容和其它單元格內容貼到一起，或在有格線的時候和格線貼在一起，我們就需要為每個單元格新增內間距，可以使用4的倍數設定。
內間距主要應用在左右兩側，但實際上上下也需要設定，在一些多行或者堆疊的場景中，單元格的高度就要隨內容增加。
不過，內間距的使用也不是完全一致的，在部分單元格上可以忽略，比如表格中最左側的選擇列，和最右側的操作列，都可以忽略內間距和邊緣貼合。
二、單元格尺寸設定和響應邏輯
在上面的邏輯中，單元格的寬/高= 單元格橫豎間距 + 內容寬/高，看起來很靈活，但是它不能完全解決表格的列寬分配問題。
如果列數特別多，得做表格的左右檢視滾動還好理解，但如果表格列數特別少怎麼辦？強行新增間距來完成列的佈局嘛？
這肯定是不合理的，所以我們需要在前面的基礎上新增新的條件，就是單元格的
最小寬度和響應邏輯
。
首先說最小寬度，單元格雖然可以在響應模式下被拉伸，但可以肯定的是縮小到 10px 以內的單元格根本就沒有存在的必要。所以每個單元格都是有最小尺寸的，而最小尺寸需要根據內容決定。
這時候新的問題又出現了，如果單元格內容寬度不一致怎麼辦？比如地址有的長有的短。
那就要根據我們自己對內容的判斷，制定出這類單元格最小的寬度是多少，最少支援多少個字元。字數比這少的留白，字數比這多的用省略號或換行。
所以，當我們排列表格的時候，就是先將所有單元格的最小列寬組合起來，然後對比表格的整個檢視區域。如果寬度無法達到，我們就使用等比的方式對它們進行放大，適配檢視的寬度。
這就是表格響應式佈局的底層邏輯，檢視區域大於單元格最小的尺寸總和，單元格寬度等比放大（高度基本不變），小於則使用檢視左右滾動模式。
三、單元格的內容型別
很多 B端專案的表格只是從 Excel 表格直接照搬進來的，只有一系列的字串文字。
但時代是在發展的，現代表格對單元格內容的需求並不只侷限在文字而已，不管是飛書、語雀、石墨還是 Notion、Clickup、Coda 等雲端工具，都拓展了單元格內容的支援範圍。
所以我們首先要確定一件事，就是一個成熟的表格就不該只有文字一種單元格型別，而是有多種資料型別共存的，不同資料型別就應該有不同的表現形式，來增加區分度。
比如一般文字、價格、日期、標籤、連結、附件、縮圖、內鏈、使用者、百分比、價格等資料型別。
雖然很多時候我們獲得的需求是隻有文字，但我們要學會自己去判斷背後的資料型別是哪種，從而延伸出對應的設計型別出來。但只使用文字的表格不僅可讀性極差，往往也並不能帶來更高的效率和使用體驗。
所以儘量去積累不同的資料型別展示形式，比如過去 QQ 使用彩色的圓形來表示線上、忙碌、離線等不同狀態，在同樣簡單反映裝置狀態的表格中，我們也可以使用同類的方法。或者對包含百分比進度的資料，使用進度條而不是單純放數字。
當然具體使用什麼樣式，需要結合具體場景做判斷，不能純粹為了差異性和視覺效果做改變，任何最佳化都需要在最後和使用者做確認確保它們的有效性。
四、單元格內的文字樣式
前面提的是我們要讓單元格的不同資料型別被表現出來，而這裡我們要講的就是純文字樣式了。
雖然很多表格中確實主要以文字為主，不適合將內容替換成不同的資料型別，但文字和文字之間，也是有區別的。
首先就是很多表格都包含一個核心欄位，比如班級學生、執勤醫生表格，那麼這個表格中最重要的資訊必然是姓名。雖然可能也會有重名的情況，姓名不具有唯一屬性，但作為資料主鍵（資料庫概念）中的使用者 ID，是沒有任何可讀性的，所以不應該被凸顯。
如果我們判斷不出來什麼文字重要，但至少我們應該可以判斷哪些字元是不重要的，這種不重要不一定是資料本身的價值，而是它對於我們的瀏覽、檢索沒有太大的價值。比如前面例舉的複雜的 User_id 號，或者沒有任何規律的商品編碼，再或者一長串的雜湊值……
我們就可以透過最基本的字重、灰度來適當調節它們的對比即可，弱化那些對於瀏覽而言不重要的資訊，才能提高整個表格的檢視效率。
如果要為文字增加色彩，那麼該文字的欄位意義要符合使用者的心智。比如連結是藍色的，上漲是紅色（可能是綠色），狀態正常是綠色，警示文字是橙色，以此類推……
同時，針對一些比較特殊的文字型別，尤其是和數字相關的，是可以切換數字字型型別的。比如財務、金融、虛擬貨幣類平臺，對金額、百分比的資料展示異常關注，雖然不一定要在樣式上做得非常特別，但往往會獨立使用一個字型顯示金額和百分比。
五、單元格的內容堆疊
在一般的表格設計中，我們預設一個單元格包含一行的內容，因為這符合傳統 Execel 的設計邏輯，每一個單元格要匹配表頭的內容。
但是，這個邏輯顯然在複雜的 B 端專案中是不成立的，因為很多規定只是死的，但設計師是活得……
在一些長表格中，很多近似、前後關聯、前後從屬的資料，是可以進行合併的。比如頭像、使用者名稱、ID 編號，或者專業和所屬院系，左右眼視力狀況，體重、體脂率和肌肉含量，都是能夠進行合併的資料型別。
再或者，直接將同類資料合併進一個單元格中，在單元格另外新增每個資料的標題，也不會直接影響檢視。比如 Coding 中的列表案例：
對單元格內容進行堆疊合並，是需要設計師去判斷可行性的，這可以很好的減少表格的長度，降低次要資訊的佔比，加快同類資料資訊的識別速度，提升整體的使用效率和體驗。
但是，它同樣存在侷限性，就是被合併後會難以進行排序，因為一個單元格內包含好幾項內容，精確排序的結果就難以呈現出對應的規律結果。
所以合併資訊內容必須新增一個條件，就是被合併物件沒有排序的需求，或者整個單元格有個明確的主體欄位，排序只以它為標準。
六、單元格的對齊模式處理
單元格的對齊上，很多人一直沒搞明白怎麼處理，因為實用性是高於美觀度的，所以只需要遵循幾個固定的邏輯做判斷，其實特別簡單。
首先，因為人眼 F 型的瀏覽習慣，可以直接預設單元格是左對齊，然後找出不符合左對齊條件的那些資訊資料，對它們進行居中或右對齊的處理。下面一項項解釋。
1。 最右操作列右對齊
最右側操作列檢視邏輯和左側內容不同，我們要找操作選項的時候視線是從右側開始向左看起 （F型反轉）的，所以作為操作項右對齊的模式效率更高。
但如果最右側的內容不是常見的操作而是長文字，比如地址、郵箱，那麼依舊只能左對齊，因為文字的閱讀是有連續性的，只適合從左側讀起。
2。 價格類數字右對齊
對於價格或一些統計總數，我們也需要使用右對齊。因為這些數字位數較多，我們在表格中檢視它們的主要順序就是先確定位數，再看具體數值。比如 82000000000，那我們要做的第一件事必然是數 “0”。
因為位數長度不同，再透過千位分隔符，還可以對上下單元格進行數額大小的對比，提升檢視效率。
但是，不是所有長數字都要右對齊，因為有些數字組合是沒有位數價值的，比如手機號、數字 ID、年月日等等，它們依舊只適合左對齊。
3。 固定長度的短資料居中
最後一個，就是一些固定長度的短資料型別，比如球員號碼、狀態標籤、百分比、圖示，都是適合進行居中排列的。
之所以加 “短” 字，就是因為只有資料內容短，居中對齊看起來就整潔幹練。但類似手機號、長ID 這些內容，雖然長度也一樣，但居中的效果會非常違和。
七、表格中的批次操作
表格往往會包含批次操作，在複雜的業務場景中確實可以延伸出非常複雜的互動邏輯。我們首先來解釋它的常規互動形態，然後再自己根據實際場景進行最佳化。
首先，批次操作必然要包含兩個關鍵的要素，多選框和操作列表。多選框用來進行批次選擇，操作列表則是對選中的內容進行處理的按鈕區域。
建議將可以操作的選項做到表格的左側，類似上方的案例，不管是放在表格上方還是下方都可以。但非常不建議將操作區域放到表格的右上角去，因為選擇和操作的距離太遠，不僅操作起來麻煩，在不熟悉系統的情況下還很難找到操作項。
也建議操作的選項能在選中被啟用時和預設狀態有一定的區別，讓使用者操作過程明顯感知到選中後應該在哪個地方進行操作選擇，可以參考百度雲、阿里雲的批次互動。
最後，很多表格高度是超過一屏的，需要滾動的，那麼這個操作欄就需要懸浮在頁面上而不被滑出螢幕之外，這才能確保批次操作的效率和體驗。
八、表格內容的修改
表格除了批次操作，也有允許直接在表格中進行單元格編輯和修改的需求。雖然這裡也存在很不一樣的業務需求和操作場景，但我還是要給出一個套比較萬能的解決方案。
首先一定要明確現在做的東西是一個可以編輯的表格，而不是做一個長得像表格的表單，比如下圖千牛的批次裝修頁，看起來很像表格，但本質上它是個表單。
既然是表格，那檢視、檢索、批次操作才是它的主要功能，不能因為我們可以去編輯它而把它強行表單化。比如將可以修改的文字直接做成輸入框，隨時可以編輯，頁面的觀感就會充滿不確定性（等著你去改）……
而且改完之後怎麼將修改的資料覆蓋原有的，是新增確認按鈕，還是直接游標從現有區域移出後就完成覆蓋？不管哪種操作效果都不好。
所以我一般建議在可修改的表格中，對允許修改的選項新增操作提示圖示。文字必須再點選後才進入編輯模式，且必須有修改後點選確認替換原資料的操作過程。
這麼做看起來確實操作變長了，但這是變難用了嘛？再回到前面的要點重複一遍，這是一個表格。還要在這個地方檢視資訊、複製現有資訊，要防止操作太容易，導致誤操作替換了錯誤的資訊進去……
九、堆疊表頭的設計要點
堆疊表頭，就是表頭類似 Excel，包含上下的層級和從屬關係，比如在 Ant Design 表格頁面中有展示的表頭分組效果。
這種情況一般不用，但用的話幾乎都使用在表頭數量極多的場景，透過堆疊的方式來對不同的表頭進行歸類，便於在眾多資料中理解該資料型別的歸屬，比如你們可以檢視下面我們某學員的專案需求，接近 80個欄位的表頭：
碰到這種情況確實是很蛋疼，但是沒辦法，有的專案就希望在表格頁面檢視所有資料，而不整理進詳情頁面中。針對這個情況就不要考慮美觀的問題，而是識別性的問題。
這種情況先完全忽略掉表格的美觀性，就重點考慮資料的識別性。
因為資料太多，沒有表頭作為提示是不可能認清資料是什麼的，所以首先要確保表頭是可以始終存在於檢視區域內容不會被滾動走的。
第二點，既然都用堆疊對錶頭做分組了，目的當然是為了強調它們的從屬和上級分類，如果只是像上面案例這樣簡單的用線段分割，那在實際檢視過程基本是沒有多少幫助的。
所以，在這種非常接近 Excel 排列邏輯的表格中，也使用操作 Excel 常用的手法，就是給不同的分類新增不同的背景色，讓它們更好被區分出來。
雖然我們可以用很淺的背景色防止它們太上頭，但這個頁面的視覺效果基本是和美觀無緣了。原因於資訊的識別效率，美觀是值得被犧牲的。
這種要羅列大量資料的表格，和前面的表格確實已經快變成兩個物種了。強烈建議大家在 Excel 內先創建出一個 1：1 的資料表，並模擬實際業務操作去動手，你就會產生完全不同的認識，而這是用圖文分享沒辦法詳細解答的感受。
十、序號和ID的認識
在表格中，還有一個很容易糾結的地方，就是需不需要加 “序號”，而序號很多時候又和ID的理解有衝突。
首先要理解，ID 是表格每個行的唯一識別符號，比如學生列表，學生姓名年齡生日都可以完全相同，但ID才是系統區分他們的唯一指標，所以ID的存在是用來做資料物件的標識的。
而序號，則是獨立於資料物件之外，用來標識表格中資料物件的序列，這在 Excel 中的側邊欄是必備的顯示內容。
本質上說，這個序列和資料物件其實是沒關係的，不管你做了什麼篩選、排序、修改，序號1使用就是表格中的第一個物件，2就是第2個，以此類推。
它在 B 端專案中的存在價值並不是特別突出，常規情況下我們肯定不需要放。但如果出現了一些對錶格序列、數量比較敏感的場景，比如要檢視排序結果範圍內的物件數量，或者設定表格匯出範圍（從某個序號到另一個序號之間）。
這些例子並不多見，所以想不明白序號存在的意義，產品業務方也給不出理由，那就不需要放！
結尾
以上就是今天分享的表格相關知識點了，下一次分享表格可能就是表格中的層級摺疊說明了。有其它的問題也可以在留言中提出，有好的問題我也會後面一併進行整理。
感謝大家收看！
作者：酸梅乾超人；公眾號：超人的電話亭（ID：Superman_Call）
本文由 @超人的電話亭 原創釋出於人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash ，基於 CC0 協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。