下面的10問都是大家常見的表格問題，同時也給出相應的解決方法。

上期回顧：

在表格中，一個單元格的寬度如何確定

首先在確定一個單元格的寬度時，我們需要對所有的字段類型進行最小寬度的設定。通常最小寬度是根據 「表格字段」 內容寬度的決定，不同的內容寬度也會不盡相同。

• 地址字段：算是B端產品經常出現的一個字段，由于地址非常不可控，長短會有非常大的差別
• 成員字段：成員字段單獨拿出來講是因為目前的成員字段展示會出現三種流派：純文字型、頭像文字型、頭像型。在成員字段設計中需要考慮單個與多個的情況
• 日期時間字段：日期時間是一個典型的可控字段，因為格式原因，其寬度能夠被精確掌握，也因此可以做較為多形式上的創新。小Tips：在數字的對齊上，可采取 Helvetica 字體，這樣能夠保證用戶查看數據時，整齊更加容易辨別

通過上述的字段舉例，大家會發現字段寬度無外乎就是幾類情況，通常也會對其寬度大小有所預判，也因此能夠有所了解，咱們將字段寬度梳理出來后，需要最后落實到文檔中，也就是將字段的寬度進行記錄，在后面開發實現中會十分有用。

表格中一行展示字段數據過多時如何處理

如果拿到上面類似需求時，我建議大家不要著急上手做，先試著去分析“如果我是該產品用戶，真正需要哪些字段，理由是什么？”這樣的方式對于你而言有兩點好處：

• 多維思考：能夠讓你深入挖掘需求，進行多維度的思考，而不是做一個單純的組件設計師。當你覺得展示字段有欠考慮時，可以多去和產品同學溝通，了解這條數據展示的背后邏輯，有利于自我快成長
• 捍衛體驗：堅持與用戶站在一起，畢竟我們是整個流程中，為用戶考慮的最后一道防線，不要因為字段設計上缺失進而由用戶來買單，這樣更能幫助你對業務上有更深刻的理解

將需求分析清楚后，我們便可著手去做。在面對數據過多的字段展示時，我們通常都是采取「信息層級」的方式來讓多個字段合理展示，雖然方法都是相同，但是在設計形式上，還是有三種不同的方式。

1. 多層展示：

當橫向數據過多時，為了避免字段的隱藏，只有拓展縱向空間。無論你是使用疊層、銜接，都是將多個同一維度的數據，進行縱向拓展。

比如你需要在一行去展示：發貨時間、發貨地點、發貨人以及物流信息，如果想讓用戶直接了當的看到所有信息，疊層、銜接都能夠達到目的。雖然形式上比較平鋪直敘，但直接在B端往往能取得不錯的效果。

2. 主次展示：

多層展示讓數據平鋪直敘，主次展示讓數據有了輕重。

通常在表格中，一列多條數據必定會有主次之分，然而在B端的表達方式上也會有較大的區別：

• 強弱化：將主次的信息通過粗細、大小、深淺等處理方式進行簡單弱化，形成信息層級，這種方式能夠在短時間內快速設計，適合新手入門進行信息的快速區分
• 標簽化：在將主次信息區分后，對次要信息進行標簽形式的處理，雖然看上去是一個設計形式的轉變，但通常很多輔助信息都是內化為產品的特定狀態，可減少字段頭部的內容寬度，同時便于產品形成一套自身產品的標簽體系
• 符號化：將特殊字段設計為特定的符號，在對表格進行簡化的過程中，將諸如狀態、電話、性別之類的屬性進行符號化，并且可展示當前是否填寫的狀態，一方面將用戶是否填寫該信息，你可一目了然的看到，同時針對這些次要信息，這樣可以提升展示效率，極大降低用戶閱讀所需要花費的時間，同時當用戶Hover就可展示符號下的信息，也便于用戶閱讀

我舉一個實際工作中的例子，在我們自身產品的「OS系統」中，會針對客戶開通產品線的八個產品。對于我們而言，就需要展示客戶名稱、客戶等級、余額、開通產品等20+個字端進行展示，我們便采取了上面三種不同的方式，并且OS端作為小部分銷售用，使用標簽、符號對于系統而言認知成本會變低，按鈕快速點擊，產品就可快速開通，使用會更加合理。

「OS系統」：主要目的是針對銷售在與客戶溝通時，需要查看客戶的信息、開通相應的產品，并且在為其推薦產品后能夠進行快速開通

3. 隱藏展示：

隱藏展示并不屬于上面的兩種形式，主要是將大量的非重點信息進行折疊收起，提供一個較深的細節入口來隱藏掉信息，常見有下拉、浮層、提示框、彈窗…

這種方式雖然用數據更為簡潔，但是會有一定的認知成本，因此使用時需要多加注意，比如在網頁端的淘寶訂單中，也使用同樣的方法將訂單的物流信息進行收納，使信息更加整潔。

干擾表格寬度的因素實在太多，我們應該如何確定表格整體寬度呢？

在B端產品實際工作中，對于很多控件的問題，我們可以從開發實現的角度去尋找答案。

比如我們想要確定表格整體的寬度，就可以從 HTML 的 table 標簽中去尋找，而寬度其實就是 table 標簽的 width 屬性，你可以在 w3school 這類基礎前端教程中找答案，有任何疑問都可以嘗試在上面進行搜索研究。

我們回到表格，其實表格寬度 width 是包含有Pixels、%兩種不同的屬性值。

Pixels：表格寬度以多少像素進行展示，例如width=“100px” 則為50像素的寬度的一個表格寬度。像素作為寬度在前端也被叫做「絕對位置」，由于「絕對位置」牽扯的關聯知識太多，就不進行拓展。

%：表格寬度以多少百分比作為寬度進行展示，例如width=“40%” 則為占整個表格寬度的25%。百分比也可以稱之為「相對位置」。

同時可以明確告訴大家，兩種方式是可以混合使用，也就是我們常說的「表格固定寬度」與「百分比寬度」混用。

當表格最小寬度小于字段總和寬度，根據設計方式的不同，可采取不同的解決辦法。

換行展示：這種方式主要針對定制化開發項目，對于項目內的字段內容能夠有足夠的可控性，因此采用換行的處理辦法能夠展示出更多的內容。同時對于大多數PC用戶而言，寧可采取縱向滾動也要盡量避免使用橫向滾動，因此換行雖然增加了縱向空間， 但用戶使用體驗仍然較為友好

這里我再解釋一下為何避免橫向滾動。

對于所有的鼠標用戶而言，橫向滾動都是極為痛苦的，因為正常鼠標橫向滾動是需要用戶按住 「Shift + 滾動」 才會使表格進行滾動，但在我接受到的眾多用戶吐槽中，很多用戶只會選擇使用鼠標對橫向滾動條進行拖拽，同時很多用戶也不知如何正確查看橫向的內容，所以如果你做的不是一個aPaaS平臺，盡可能減少用戶橫向滾動的場景。

省略隱藏：這種方式主要是針對aPaaS產品的可配置化需求，一般與列寬設置、字段顯隱配置一起出現，同時在用戶Hover時，還可伴隨系統內置Tooltips進行提示。雖然隱藏掉用戶的信息是在軟件層面對于信息的干預，不提倡這種做法，但是在實際需求中，這樣的方式同樣是較為常見。比如在明道云、Teambition、輕流等產品中，為了保證字段的可配置性，都采取省略隱藏的方式，用戶可以對想要的寬度進行自定義。

當表格最小寬度大于字段總和寬度，便可采取百分比的形式。

這樣表格的寬度可以跟隨屏幕寬度進行變化。這里設計師可以進行偷懶，因為在現有較為成熟的框架中，對于表格寬度大于字段寬度都做了等比例的拉伸，因此在這里無需過于糾結。

當表格寬度需要有預設固定寬度時，你便可采取百分比 + 固定寬度的形式，這種方式可以解決表格信息隱藏過多。

因為在表格中，不是所有的字段都需要寬度進行自適應，比如在一些操作、狀態等字段中，本身系統就能對其寬度進行預知，為了減少對于其他字段的隱藏，可采取固定寬度。

這種方式也可以解決表格寬度不夠所帶來的困擾，固定寬度通常為操作、狀態等能夠預知其長度的寬度類型，在設定上盡量在系統中的寬度保持一致，固定寬度的使用有好有壞，常見于表格中尾部的操作。如出現在表格中部，在較長的頁面中進行展示也會帶來許多較差的展示形式。

表格最小寬度。表格主要適配到的最小寬度，這一步驟通常的設計系統的初期就要完成，一方面可根據自己項目目前情況，按照導航寬度等固定尺寸確定最小的表格寬度，這樣在處理最小尺寸時，可以有一個明確的邊界，同時能與開發同學進行理解溝通。

表格中既有復選框，同時有包含樹形結構時，它們倆的先后是有設計原則的嗎？

很顯然，它們的使用意義并不相同，想要了解兩者的區別可以先明確兩者的功能。

• 復選框（check box）：選擇表格當前及其以下的數據，是數據選擇的一種表現方式
• 樹形結構收折箭頭：主要在「樹形表格」中，起到展開數據與收起數據的功能，為了方便父與子的數據都能夠在表格中得以呈現

不知道「樹形表格」可以看上期文章。

當復選框在前，代表復選框權重更高，所選擇的范圍是包含該條數據以及數據下的所有子集，也就是收折箭頭里面的對應內容。

當復選框在后，代表復選框權重較低，選擇的范圍是只針對該條數據進行選擇，也就是你勾選的那一條數據，不會牽涉到下方的子數據。

但在實際情況中，會出現同時存在兩種方案，我在一個樹形結構中，既需要對結構中子數據的勾選，同時又需要讓用戶對單個條件中的數據進行勾選，這時就需要「顯一隱一」，對于用戶高頻使用的的一種方式，進行常駐展示，同時在 Hover 上去后，進行展示，這樣可以避免兩個復選框帶來的認知迷茫。

在小屏幕適配時，對于整體表格可以進行怎樣的優化？

很多設計師都缺少對小屏幕的處理方式，那么小屏幕的尺寸是多少，最小多少算小屏幕，這是我們首先需要明確的。

我們分析一下市面上共有共有多少小屏幕尺寸，數據來自百度流量研究院2020年10月份的數據：

如果我們把 1920 x 1080 以下的分辨率都定義為小屏，則有39.55% 都是小屏幕用戶。

而針對不同的小屏，我們首先需要確定分辨率的下限，這里一般建議大家可以根據用戶自身的使用場景去分析，比如針對銷售的場景，會有許多外出上門拜訪的銷售，這時候就必須考慮到筆記本的小屏幕用戶，一般做到 1440x900 兼容、1280x720 能用即可。

1440x900 兼容，通常會針對主要頁面去設計，如果產品中，該分辨率下的用戶較多，可提出針對該分辨率情況進行單獨適配，簡單優化頁面布局來兼容空間不足的問題。

1280x720 能用，我說說我實際工作的思路，我們可以通過前端代碼屏幕縮放，將小分辨率的屏幕縮小，因而能看見更多的內容。通常做法是將1440px以下的尺寸，進行 Zoom 的90%的縮放，這樣能夠在電腦上看到更完整的信息，但同時也會有相應的缺點，由于整體縮放，需要檢查前端代碼對于整體縮放有沒有進行適配，需要對頁面進行再次走查，同時網站內容都會相應縮小，算是一個迫不得已的方式。

表格中操作項按鈕太多要整合成一個按鈕再展開嗎，當不同的操作信息展示時，能夠采取錯位顯示嗎？

在表格中，操作的展示方式首先分為以下幾種：

1. 對齊式

將所有操作進行整齊排列，一般是一個操作對應一列，當有操作缺失時，展示為空。這種方式能夠讓用戶直接了解到操作的缺失，但反復的出現會造成表格視覺上的冗余，適合列數較少的表格使用。

2. 平鋪式

將所有操作按照一定的預設排列順序進行平鋪。這種方式能夠適應B端的大多數場景，將操作都簡單平鋪出來雖然看上去簡單粗暴，但是在實際工作中，也是一種不錯的處理方式。

3. 隱藏式

將所有的操作按鈕收起到 “更多” 里面，并且用戶點擊后展示操作選項。這種情況常見于當前系統的操作按鈕不可控或重要程度較低時，隱藏能夠盡可能讓頁面進行統一，達到高效整潔的目的。與此同時，隱藏式也會有很多問題，隱藏操作后用戶不能立刻知道我能有哪些操作，對于一些高頻操作而言便是一個噩夢。

因此采用隱藏式需要我們對功能上進行相應的取舍，才能滿足目前對于設計上的統一。

4. 懸停式

將所有的操作進行隱藏，當用戶鼠標懸停時進行展開所有操作。這種方式能夠最大程度上滿足用戶快速查看與編輯的需求，但是在實際使用中，用戶的初次使用門檻較高，需要有一定的學習成本。

5. 主次式

將主要的操作進行展示，次要的操作進行隱藏。這種方式能夠盡可能滿足業務上對于高頻操作時的需求，同時在設計上，能夠將多余的操作進行隱藏，使得設計出的頁面能夠更加統一有效。

6. 多選式

表格中用戶的操作也會有多選的存在，因此也需要你去分辨到底的用戶單條數據操作的場景多還是用戶對于多條數據的場景多，需要有所分辨。如果是在多選場景較為多時，應首要注意多選時的操作優化，可犧牲單條數據所需要應對的操作。

上面六種辦法，你可以根據你的實際情況進行對應的處理方式。

表格的設計規范要怎么專業化的表達，一般如何制定表格規范能跟前端達成一致

這涉及到規范究竟應該如何去表達，其實每一位設計師對于規范的做法也不盡相同，但是要保證你做的規范與前端之間，能夠達成相同的默契，這樣對于我們而言，才有規范的真正價值，這里我分享一下我是如何交付一個表格的。

首先，我們需要交付的需求一共幾個：

1. 表格的寬度文檔

通常是一份Excel表格里面記錄了系統中所有字段的常規寬度，前端可以根據寬度情況進行百分比的縮放，當然你也可以標注在設計稿中，方便前端進行開發，避免在文檔之間反復橫跳

2. 設計稿本身

設計稿本身只需要展示一些簡單的邏輯，同時盡可能的考慮清楚不同角色、不同狀態下，你的設計稿所要呈現出的邏輯，方便在設計評審時與大家進行探討，同時可以出一個簡單的調研、分析的文檔，方便大家提前閱讀，更能清晰地明確業務、功能上的需求點

3. 設計備注

因為在設計稿中，有很多需要文字與前端進行溝通的地方，比如這里的交互說明、邏輯表述等等，我通常會在設計稿的下方單獨標注出設計所需要注意的點，并給出相應的邏輯方便前端進行理解，對于其他同事接手你的工作時，也有更多的幫助

移動端表格如何進行適配？

由于國內的使用場景與國外有很大的不同，也就造成國內的很多產品對于移動端都格外的重視，因此本身表格就過于復雜，移植到移動端就會存在大量的問題，要想真正了解其背后的原理，我們先了解一下「桌面端與移動端的布局思路」

先普及一個知識點，什么是「響應式布局」、什么是「自適應布局」。

響應式布局：是指網頁（一套前端代碼）同時能兼容多個終端，根據每個終端分辨率大小自動調整尺寸

我舉個例子，響應式布局就是將所有元素進行變形、隱藏，但是對于元素的布局等并沒有實質變化，因此響應式大多出現在官網的場景中，這樣的適配更輕量簡單，不會有太多的困擾，比如常見的：飛書、神策、Eagle、藍湖的官網都是采取響應式的方式進行開發。

對于設計而言，響應式一般是先完成對桌面端的設計后再考慮對于移動端的適配，是一個元素由多到少的設計過程。

自適應布局：是指網頁（多套前端代碼）能夠同時滿足多個分辨率的終端，并且多個終端之間布局差異較大。

舉個例子，公司需要設計一個桌面端、Pad端、移動端的三端產品，而且每一個端的布局方式都有著截然不同的思路，而需要滿足這樣的布局場景的最好的辦法就是自適應布局，通過判斷分辨率、設備ID，來進行布局的修改，比如語雀都是采取自適應的方式：

了解完響應式與自適應后，我們先看看移動端表格最具代表性的 Excel 文檔產品是如何適配表格。目前調研了WPS\Office\石墨文檔 \騰訊文檔\飛書，這五大產品。

對于傳統類文檔產品而言，表格要做到的就是能夠滿足用戶的預期。雖然在整體設計上幾個產品都極其類似，但是在細節的處理上，各個產品卻不盡相同。

初始大小：在單元格初始大小中，明顯感受 Office的初始單元格大小最小，我猜測可能與Office通常承載的數據量過大有關，但對于國內的其他文檔類型產品而言，在初始大小上，顯然是讓用戶更易讀每一個單元格內的內容

信息錄入：在信息錄入的場景下，騰訊文檔會提供錄入狀態的放大，這樣錄入體驗明顯更加友好，具體細節如下圖：

值得一提的是，在所有新建場景中，只有WPS在我新建完成表格過后，便立刻彈起輸入框，讓我對需要新建表格的內容進行輸入，顯然這樣的體驗會更加連貫。

但在B端實際工作中，處理移動端的交互方式通常會采取以下四種模式：

1. 直接展示

保留表格現有的表現方式，將表格直接展示出來。看起來像是并沒有做任何適配，但在移動端中，這也不失為一種合理的做法。因為在頗具代表性的文檔產品中，也是如此，而且表格中的操作行為已經深入人心，他們只需要根據自身對于表格的認知，在移動端做出相應的判斷即可，不需要太多思考，但當直接展示遇到大量數據時，這樣處理還是會有點捉襟見肘。

2. 凍結表頭

由于直接展示相對來說閱讀體驗并不友好，便在此基礎上進行優化產生了凍結表頭，將表頭與第一列（通常第一列數據為關鍵數據）的數據進行固定，讓直接展示的數據能夠形成對應的關系，滿足用戶閱讀表格時的基本需求。

3. 清單展示

將表格中的數據進行視圖上的切換，形成 “標題 + 數據” 這樣一一對應的關系。

這樣處理的方式，可以直接展示表格中的數據，讓移動端的表格像一行行表單一樣。但是直接展示List 在國內的實際場景中使用比較少見，對于較少的數據有比較好的效果。

4. 卡片模式

卡片模式主要是將表格中的一些關鍵字段在通過對應的關系實現一個卡片展示一行數據，用戶想要了解數據全貌，可以點擊卡片，進行數據全貌的查看分析，這類做法也是國內移動端常見的做法。

優點：在眾多移動端表格中，這種做法是對用戶較為友好的，首先國內產品對于移動端卡片交互形式都是十分熟悉，不存在用戶的認知偏差，其次卡片流的形式在移動端數據呈現上，要比其他幾種方案來得更加優秀。

缺點：當數據過多時，?卡片展示的效率會隨之降低。用戶需要結合搜索、篩選將數據量降低，使卡片流的長度縮小；因為只展示關鍵數據，當一行數據過多時，用戶不能直接看到數據全貌，需要多一步交互點擊查看。

表格中快捷編輯如何處理？

在傳統的Excel表格中，快捷編輯是最常用的一個狀態，當用戶觸發去編輯表格中的數據，便可實現在表格內的編輯操作，這一交互行為在B端的表格場景中也得以保留。但設計中的細節還有很多需要注意的地方。

首先，表格的快捷編輯分為兩個步驟，「進入編輯狀態」以及「提交編輯數據」，因此在這兩種狀態下，我們都需要設計不同的方式：

1. 雙擊觸發 - 進入編輯狀態

雙擊觸發主要還原 Excel 用戶操作的習慣，用戶雙擊單元格即可實現編輯單元格內數據的操作，看似沒有問題但是在實際工作中這類方式反而并不常見，究其原因共有兩點：

交互埋點深：因為這一交互雖然還原至Excel表格，但用戶在 Hover、Active 時，這類交互方式都不會對用戶有過多的提示，用戶很難想到。

重復操作邏輯奇怪：其實雙擊的操作在桌面端應用算是常見的，但是對于WEB端的產品而言，兩次點擊對于用戶而言都是過于小心，因此雙擊觸發一定要給到用戶足夠多的提示。

2. 按鈕觸發 - 進入編輯狀態

按鈕觸發在我看到的眾多的B端軟件中是最為常見的，通過表格右側的按鈕，提示用戶該數據是可被編輯狀態。同時當用戶點擊編輯按鈕后，直接進行編輯。

按鈕觸發比起雙擊觸發會更加克制，在操作之前用戶就可知道該條數據自己能否編輯，也能提前給用戶自己的預期。點擊按鈕進行觸發，雖然看上去相對繁瑣，但是能夠傳達出更加清晰的操作行為，也未嘗不是一種更加優秀的做法。

3. 失焦提交 - 提交編輯數據

• 在輸入場景中：當用戶輸入完成后，點擊空白區域
• 在選擇場景中：用戶選擇一個后，自動收起下拉菜單
• 在進行提交時，無論成功與否，都會進行提示，但是在選擇場景中的多選需要格外注意，這里的提交方式會有些特殊，在實際場景中，aPaaS產品大多都采取這樣的方式，比如Teambition、明道云等等…

4. 按鈕提交 - 提交編輯數據

當使用按鈕編輯后便可以連續使用按鈕提交，這樣面對用戶多選時，也可更加明確，選擇了多條數據后點擊提交便可提交數據。

最后針對表格上篇中的一條評論進行統一的回復

Q：市面上已經有 Ant Design 如此成熟的 B端設計框架后，你是選擇直接使用，還是選擇自己造一個輪子？

A：當我看到如此的評論后，內心也是十分復雜的，我先說說我自己的看法

商業設計往往并沒有那么簡單，首先關于開源的「中臺框架」并不只是有Ant Design一家，而我們拿它與Element進行比較，也會發現有很多不同的地方。而大家有去思考為何會有這些不同點嗎？ 我想答案大多是否定的。

開源確實是非常棒的一件事，我也是其中的受益者，同時也非常感謝在Ant Design 中的貢獻者，但即使是 Ant Design 也在2018年圣誕節的時候發生了不可控的黑天鵝事件（2018年Ant Design 圣誕節按鈕彩蛋），讓許多使用Ant Design 的前端工程師被迫加班，我也在當天被負責人反復 Call 到（因為他以為是我們如此設計的）因此使用自己獨立的框架也代表著將風險掌握在自己手中，使用現有的框架其實是為了「降本增效」，但成本并不是一個項目需要思考的唯一因素，對于很多企業來說安全也是一個重要的因素。

最后并不是所有的組件Ant Design 都會提供，企業級產品會有很多自身個性化的需求，因此當你走都不會時，如何去跑呢？我自己更愿意把 Ant Design 當作是一本參考書，當你有疑問時你可以翻開看看。

當然任何事情都是有成本的，在小團隊中 Ant Design 確實能夠在項目初期實現快速搭建，一定程度上提升了后臺產品的設計下限，而它的上線還是需要我們一起去努力。

我是CE青年，一個2B行業的 2 B設計師～ 如果覺得不錯，歡迎點贊支持～

歡迎關注作者的微信公眾號：CE青年