在日常業(yè)務(wù)場景中，表格這一元素是十分常見的，不過不少人卻還是不能將表格設(shè)計得盡善盡美。不過我們也不能妄想解決所有場景下的表格設(shè)計問題，所以不如選擇從常見問題入手展開設(shè)計，比如本文作者便總結(jié)了表格設(shè)計常會面臨的問題及解決方案，一起來看看吧。

在之前我們分享過一篇關(guān)于表格設(shè)計的詳解，比較系統(tǒng)地分享了表格設(shè)計的思路和流程。文章鏈接：年前最后一篇長干貨，B端表格規(guī)范最終集奉上。

但表格設(shè)計細(xì)節(jié)太多了，光靠一篇系統(tǒng)性的分享肯定無法覆蓋所有場景和問題，所以本篇內(nèi)容主要集中在表格設(shè)計中面臨的常見問題展開：

1. 單元格的組成和內(nèi)間距應(yīng)用；
2. 單元格尺寸設(shè)置和響應(yīng)邏輯；
3. 單元格的內(nèi)容類型；
4. 單元格內(nèi)的文字樣式；
5. 單元格的內(nèi)容堆疊；
6. 單元格的對齊模式處理；
7. 表格中的批量操作；
8. 表格內(nèi)容的修改；
9. 堆疊表頭的設(shè)計要點(diǎn)；
10. 序號和 ID 的認(rèn)識。

一、單元格的組成和內(nèi)間距應(yīng)用

每個表格都是由若干矩形單元格組成的，單元格內(nèi)可以包含對應(yīng)的圖片、圖標(biāo)、按鈕、文字內(nèi)容。當(dāng)我們設(shè)計一個表格的時候，不管你有沒有使用線段來分割出每個單元格，都需要用這種網(wǎng)格模式完成表格的布局。

這意味著，單元格之間是沒有間距的，它們相互之間是緊密貼合在一起的，而不是通過外邊距控制布局的。

在此基礎(chǔ)上，為了防止單元格內(nèi)容和其它單元格內(nèi)容貼到一起，或在有格線的時候和格線貼在一起，我們就需要為每個單元格添加內(nèi)間距，可以使用4的倍數(shù)設(shè)置。

內(nèi)間距主要應(yīng)用在左右兩側(cè)，但實(shí)際上上下也需要設(shè)置，在一些多行或者堆疊的場景中，單元格的高度就要隨內(nèi)容增加。

不過，內(nèi)間距的使用也不是完全一致的，在部分單元格上可以忽略，比如表格中最左側(cè)的選擇列，和最右側(cè)的操作列，都可以忽略內(nèi)間距和邊緣貼合。

二、單元格尺寸設(shè)置和響應(yīng)邏輯

在上面的邏輯中，單元格的寬/高= 單元格橫豎間距 + 內(nèi)容寬/高，看起來很靈活，但是它不能完全解決表格的列寬分配問題。

如果列數(shù)特別多，得做表格的左右視圖滾動還好理解，但如果表格列數(shù)特別少怎么辦？強(qiáng)行添加間距來完成列的布局嘛？

這肯定是不合理的，所以我們需要在前面的基礎(chǔ)上添加新的條件，就是單元格的最小寬度和響應(yīng)邏輯。

首先說最小寬度，單元格雖然可以在響應(yīng)模式下被拉伸，但可以肯定的是縮小到 10px 以內(nèi)的單元格根本就沒有存在的必要。所以每個單元格都是有最小尺寸的，而最小尺寸需要根據(jù)內(nèi)容決定。

這時候新的問題又出現(xiàn)了，如果單元格內(nèi)容寬度不一致怎么辦？比如地址有的長有的短。

那就要根據(jù)我們自己對內(nèi)容的判斷，制定出這類單元格最小的寬度是多少，最少支持多少個字符。字?jǐn)?shù)比這少的留白，字?jǐn)?shù)比這多的用省略號或換行。

所以，當(dāng)我們排列表格的時候，就是先將所有單元格的最小列寬組合起來，然后對比表格的整個視圖區(qū)域。如果寬度無法達(dá)到，我們就使用等比的方式對它們進(jìn)行放大，適配視圖的寬度。

這就是表格響應(yīng)式布局的底層邏輯，視圖區(qū)域大于單元格最小的尺寸總和，單元格寬度等比放大（高度基本不變），小于則使用視圖左右滾動模式。

三、單元格的內(nèi)容類型

很多 B端項目的表格只是從 Excel 表格直接照搬進(jìn)來的，只有一系列的字符串文本。

但時代是在發(fā)展的，現(xiàn)代表格對單元格內(nèi)容的需求并不只局限在文本而已，不管是飛書、語雀、石墨還是 Notion、Clickup、Coda 等云端工具，都拓展了單元格內(nèi)容的支持范圍。

所以我們首先要確定一件事，就是一個成熟的表格就不該只有文本一種單元格類型，而是有多種數(shù)據(jù)類型共存的，不同數(shù)據(jù)類型就應(yīng)該有不同的表現(xiàn)形式，來增加區(qū)分度。

比如一般文本、價格、日期、標(biāo)簽、鏈接、附件、縮略圖、內(nèi)鏈、用戶、百分比、價格等數(shù)據(jù)類型。

雖然很多時候我們獲得的需求是只有文本，但我們要學(xué)會自己去判斷背后的數(shù)據(jù)類型是哪種，從而延伸出對應(yīng)的設(shè)計類型出來。但只使用文本的表格不僅可讀性極差，往往也并不能帶來更高的效率和使用體驗(yàn)。

所以盡量去積累不同的數(shù)據(jù)類型展示形式，比如過去 QQ 使用彩色的圓形來表示在線、忙碌、離線等不同狀態(tài)，在同樣簡單反映設(shè)備狀態(tài)的表格中，我們也可以使用同類的方法?；蛘邔Π俜直冗M(jìn)度的數(shù)據(jù)，使用進(jìn)度條而不是單純放數(shù)字。

當(dāng)然具體使用什么樣式，需要結(jié)合具體場景做判斷，不能純粹為了差異性和視覺效果做改變，任何優(yōu)化都需要在最后和用戶做確認(rèn)確保它們的有效性。

四、單元格內(nèi)的文字樣式

前面提的是我們要讓單元格的不同數(shù)據(jù)類型被表現(xiàn)出來，而這里我們要講的就是純文本樣式了。

雖然很多表格中確實(shí)主要以文本為主，不適合將內(nèi)容替換成不同的數(shù)據(jù)類型，但文本和文本之間，也是有區(qū)別的。

首先就是很多表格都包含一個核心字段，比如班級學(xué)生、執(zhí)勤醫(yī)生表格，那么這個表格中最重要的信息必然是姓名。雖然可能也會有重名的情況，姓名不具有唯一屬性，但作為數(shù)據(jù)主鍵（數(shù)據(jù)庫概念）中的用戶 ID，是沒有任何可讀性的，所以不應(yīng)該被凸顯。

如果我們判斷不出來什么文本重要，但至少我們應(yīng)該可以判斷哪些字符是不重要的，這種不重要不一定是數(shù)據(jù)本身的價值，而是它對于我們的瀏覽、檢索沒有太大的價值。比如前面例舉的復(fù)雜的 User_id 號，或者沒有任何規(guī)律的商品編碼，再或者一長串的哈希值……

我們就可以通過最基本的字重、灰度來適當(dāng)調(diào)節(jié)它們的對比即可，弱化那些對于瀏覽而言不重要的信息，才能提高整個表格的查看效率。

如果要為文本增加色彩，那么該文本的字段意義要符合用戶的心智。比如鏈接是藍(lán)色的，上漲是紅色（可能是綠色），狀態(tài)正常是綠色，警示文本是橙色，以此類推……

同時，針對一些比較特殊的文本類型，尤其是和數(shù)字相關(guān)的，是可以切換數(shù)字字體類型的。比如財務(wù)、金融、虛擬貨幣類平臺，對金額、百分比的數(shù)據(jù)展示異常關(guān)注，雖然不一定要在樣式上做得非常特別，但往往會獨(dú)立使用一個字體顯示金額和百分比。

五、單元格的內(nèi)容堆疊

在一般的表格設(shè)計中，我們默認(rèn)一個單元格包含一行的內(nèi)容，因?yàn)檫@符合傳統(tǒng) Execel 的設(shè)計邏輯，每一個單元格要匹配表頭的內(nèi)容。

但是，這個邏輯顯然在復(fù)雜的 B 端項目中是不成立的，因?yàn)楹芏嘁?guī)定只是死的，但設(shè)計師是活得……

在一些長表格中，很多近似、前后關(guān)聯(lián)、前后從屬的數(shù)據(jù)，是可以進(jìn)行合并的。比如頭像、用戶名、ID 編號，或者專業(yè)和所屬院系，左右眼視力狀況，體重、體脂率和肌肉含量，都是能夠進(jìn)行合并的數(shù)據(jù)類型。

再或者，直接將同類數(shù)據(jù)合并進(jìn)一個單元格中，在單元格另外添加每個數(shù)據(jù)的標(biāo)題，也不會直接影響查看。比如 Coding 中的列表案例：

對單元格內(nèi)容進(jìn)行堆疊合并，是需要設(shè)計師去判斷可行性的，這可以很好的減少表格的長度，降低次要信息的占比，加快同類數(shù)據(jù)信息的識別速度，提升整體的使用效率和體驗(yàn)。

但是，它同樣存在局限性，就是被合并后會難以進(jìn)行排序，因?yàn)橐粋€單元格內(nèi)包含好幾項內(nèi)容，精確排序的結(jié)果就難以呈現(xiàn)出對應(yīng)的規(guī)律結(jié)果。

所以合并信息內(nèi)容必須添加一個條件，就是被合并對象沒有排序的需求，或者整個單元格有個明確的主體字段，排序只以它為標(biāo)準(zhǔn)。

六、單元格的對齊模式處理

單元格的對齊上，很多人一直沒搞明白怎么處理，因?yàn)閷?shí)用性是高于美觀度的，所以只需要遵循幾個固定的邏輯做判斷，其實(shí)特別簡單。

首先，因?yàn)槿搜?F 型的瀏覽習(xí)慣，可以直接默認(rèn)單元格是左對齊，然后找出不符合左對齊條件的那些信息數(shù)據(jù)，對它們進(jìn)行居中或右對齊的處理。下面一項項解釋。

1. 最右操作列右對齊

最右側(cè)操作列查看邏輯和左側(cè)內(nèi)容不同，我們要找操作選項的時候視線是從右側(cè)開始向左看起 （F型反轉(zhuǎn)）的，所以作為操作項右對齊的模式效率更高。

但如果最右側(cè)的內(nèi)容不是常見的操作而是長文本，比如地址、郵箱，那么依舊只能左對齊，因?yàn)槲谋镜拈喿x是有連續(xù)性的，只適合從左側(cè)讀起。

2. 價格類數(shù)字右對齊

對于價格或一些統(tǒng)計總數(shù)，我們也需要使用右對齊。因?yàn)檫@些數(shù)字位數(shù)較多，我們在表格中查看它們的主要順序就是先確定位數(shù)，再看具體數(shù)值。比如 82000000000，那我們要做的第一件事必然是數(shù) “0”。

因?yàn)槲粩?shù)長度不同，再通過千位分隔符，還可以對上下單元格進(jìn)行數(shù)額大小的對比，提升查看效率。

但是，不是所有長數(shù)字都要右對齊，因?yàn)橛行?shù)字組合是沒有位數(shù)價值的，比如手機(jī)號、數(shù)字 ID、年月日等等，它們依舊只適合左對齊。

3. 固定長度的短數(shù)據(jù)居中

最后一個，就是一些固定長度的短數(shù)據(jù)類型，比如球員號碼、狀態(tài)標(biāo)簽、百分比、圖標(biāo)，都是適合進(jìn)行居中排列的。

之所以加 “短” 字，就是因?yàn)橹挥袛?shù)據(jù)內(nèi)容短，居中對齊看起來就整潔干練。但類似手機(jī)號、長ID 這些內(nèi)容，雖然長度也一樣，但居中的效果會非常違和。

七、表格中的批量操作

表格往往會包含批量操作，在復(fù)雜的業(yè)務(wù)場景中確實(shí)可以延伸出非常復(fù)雜的交互邏輯。我們首先來解釋它的常規(guī)交互形態(tài)，然后再自己根據(jù)實(shí)際場景進(jìn)行優(yōu)化。

首先，批量操作必然要包含兩個關(guān)鍵的要素，多選框和操作列表。多選框用來進(jìn)行批量選擇，操作列表則是對選中的內(nèi)容進(jìn)行處理的按鈕區(qū)域。

建議將可以操作的選項做到表格的左側(cè)，類似上方的案例，不管是放在表格上方還是下方都可以。但非常不建議將操作區(qū)域放到表格的右上角去，因?yàn)檫x擇和操作的距離太遠(yuǎn)，不僅操作起來麻煩，在不熟悉系統(tǒng)的情況下還很難找到操作項。

也建議操作的選項能在選中被激活時和默認(rèn)狀態(tài)有一定的區(qū)別，讓用戶操作過程明顯感知到選中后應(yīng)該在哪個地方進(jìn)行操作選擇，可以參考百度云、阿里云的批量交互。

最后，很多表格高度是超過一屏的，需要滾動的，那么這個操作欄就需要懸浮在頁面上而不被滑出屏幕之外，這才能確保批量操作的效率和體驗(yàn)。

八、表格內(nèi)容的修改

表格除了批量操作，也有允許直接在表格中進(jìn)行單元格編輯和修改的需求。雖然這里也存在很不一樣的業(yè)務(wù)需求和操作場景，但我還是要給出一個套比較萬能的解決方案。

首先一定要明確現(xiàn)在做的東西是一個可以編輯的表格，而不是做一個長得像表格的表單，比如下圖千牛的批量裝修頁，看起來很像表格，但本質(zhì)上它是個表單。

既然是表格，那查看、檢索、批量操作才是它的主要功能，不能因?yàn)槲覀兛梢匀ゾ庉嬎阉鼜?qiáng)行表單化。比如將可以修改的文本直接做成輸入框，隨時可以編輯，頁面的觀感就會充滿不確定性（等著你去改）……

而且改完之后怎么將修改的數(shù)據(jù)覆蓋原有的，是添加確認(rèn)按鈕，還是直接光標(biāo)從現(xiàn)有區(qū)域移出后就完成覆蓋？不管哪種操作效果都不好。

所以我一般建議在可修改的表格中，對允許修改的選項添加操作提示圖標(biāo)。文本必須再點(diǎn)擊后才進(jìn)入編輯模式，且必須有修改后點(diǎn)擊確認(rèn)替換原數(shù)據(jù)的操作過程。

這么做看起來確實(shí)操作變長了，但這是變難用了嘛？再回到前面的要點(diǎn)重復(fù)一遍，這是一個表格。還要在這個地方查看信息、復(fù)制現(xiàn)有信息，要防止操作太容易，導(dǎo)致誤操作替換了錯誤的信息進(jìn)去……

九、堆疊表頭的設(shè)計要點(diǎn)

堆疊表頭，就是表頭類似 Excel，包含上下的層級和從屬關(guān)系，比如在 Ant Design 表格頁面中有展示的表頭分組效果。

這種情況一般不用，但用的話幾乎都使用在表頭數(shù)量極多的場景，通過堆疊的方式來對不同的表頭進(jìn)行歸類，便于在眾多數(shù)據(jù)中理解該數(shù)據(jù)類型的歸屬，比如你們可以查看下面我們某學(xué)員的項目需求，接近 80個字段的表頭：

碰到這種情況確實(shí)是很蛋疼，但是沒辦法，有的項目就希望在表格頁面查看所有數(shù)據(jù)，而不整理進(jìn)詳情頁面中。針對這個情況就不要考慮美觀的問題，而是識別性的問題。

這種情況先完全忽略掉表格的美觀性，就重點(diǎn)考慮數(shù)據(jù)的識別性。

因?yàn)閿?shù)據(jù)太多，沒有表頭作為提示是不可能認(rèn)清數(shù)據(jù)是什么的，所以首先要確保表頭是可以始終存在于視圖區(qū)域內(nèi)容不會被滾動走的。

第二點(diǎn)，既然都用堆疊對表頭做分組了，目的當(dāng)然是為了強(qiáng)調(diào)它們的從屬和上級分類，如果只是像上面案例這樣簡單的用線段分割，那在實(shí)際查看過程基本是沒有多少幫助的。

所以，在這種非常接近 Excel 排列邏輯的表格中，也使用操作 Excel 常用的手法，就是給不同的分類添加不同的背景色，讓它們更好被區(qū)分出來。

雖然我們可以用很淺的背景色防止它們太上頭，但這個頁面的視覺效果基本是和美觀無緣了。原因于信息的識別效率，美觀是值得被犧牲的。

這種要羅列大量數(shù)據(jù)的表格，和前面的表格確實(shí)已經(jīng)快變成兩個物種了。強(qiáng)烈建議大家在 Excel 內(nèi)先創(chuàng)建出一個 1：1 的數(shù)據(jù)表，并模擬實(shí)際業(yè)務(wù)操作去動手，你就會產(chǎn)生完全不同的認(rèn)識，而這是用圖文分享沒辦法詳細(xì)解答的感受。

十、序號和ID的認(rèn)識

在表格中，還有一個很容易糾結(jié)的地方，就是需不需要加 “序號”，而序號很多時候又和ID的理解有沖突。

首先要理解，ID 是表格每個行的唯一標(biāo)識符，比如學(xué)生列表，學(xué)生姓名年齡生日都可以完全相同，但I(xiàn)D才是系統(tǒng)區(qū)分他們的唯一指標(biāo)，所以ID的存在是用來做數(shù)據(jù)對象的標(biāo)識的。

而序號，則是獨(dú)立于數(shù)據(jù)對象之外，用來標(biāo)識表格中數(shù)據(jù)對象的序列，這在 Excel 中的側(cè)邊欄是必備的顯示內(nèi)容。

本質(zhì)上說，這個序列和數(shù)據(jù)對象其實(shí)是沒關(guān)系的，不管你做了什么篩選、排序、修改，序號1使用就是表格中的第一個對象，2就是第2個，以此類推。

它在 B 端項目中的存在價值并不是特別突出，常規(guī)情況下我們肯定不需要放。但如果出現(xiàn)了一些對表格序列、數(shù)量比較敏感的場景，比如要查看排序結(jié)果范圍內(nèi)的對象數(shù)量，或者設(shè)置表格導(dǎo)出范圍（從某個序號到另一個序號之間）。

這些例子并不多見，所以想不明白序號存在的意義，產(chǎn)品業(yè)務(wù)方也給不出理由，那就不需要放！

結(jié)尾

以上就是今天分享的表格相關(guān)知識點(diǎn)了，下一次分享表格可能就是表格中的層級折疊說明了。有其它的問題也可以在留言中提出，有好的問題我也會后面一并進(jìn)行整理。

感謝大家收看！