案例解析 | 10個表格加分項設計(加了億點點細節)

3 評論 6659 瀏覽 51 收藏 25 分鐘

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

在之前我們分享過一篇關于表格設計的詳解,比較系統地分享了表格設計的思路和流程。文章鏈接:年前最后一篇長干貨,B端表格規范最終集奉上。

但表格設計細節太多了,光靠一篇系統性的分享肯定無法覆蓋所有場景和問題,所以本篇內容主要集中在表格設計中面臨的常見問題展開:

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

一、單元格的組成和內間距應用

每個表格都是由若干矩形單元格組成的,單元格內可以包含對應的圖片、圖標、按鈕、文字內容。當我們設計一個表格的時候,不管你有沒有使用線段來分割出每個單元格,都需要用這種網格模式完成表格的布局。

案例解析 | 10個表格加分項設計(加了億點點細節

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

案例解析 | 10個表格加分項設計(加了億點點細節

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

案例解析 | 10個表格加分項設計(加了億點點細節

內間距主要應用在左右兩側,但實際上上下也需要設置,在一些多行或者堆疊的場景中,單元格的高度就要隨內容增加。

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

案例解析 | 10個表格加分項設計(加了億點點細節

二、單元格尺寸設置和響應邏輯

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

如果列數特別多,得做表格的左右視圖滾動還好理解,但如果表格列數特別少怎么辦?強行添加間距來完成列的布局嘛?

案例解析 | 10個表格加分項設計(加了億點點細節

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

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

這時候新的問題又出現了,如果單元格內容寬度不一致怎么辦?比如地址有的長有的短。

那就要根據我們自己對內容的判斷,制定出這類單元格最小的寬度是多少,最少支持多少個字符。字數比這少的留白,字數比這多的用省略號或換行。

案例解析 | 10個表格加分項設計(加了億點點細節

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

案例解析 | 10個表格加分項設計(加了億點點細節

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

三、單元格的內容類型

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

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

案例解析 | 10個表格加分項設計(加了億點點細節

所以我們首先要確定一件事,就是一個成熟的表格就不該只有文本一種單元格類型,而是有多種數據類型共存的,不同數據類型就應該有不同的表現形式,來增加區分度。

比如一般文本、價格、日期、標簽、鏈接、附件、縮略圖、內鏈、用戶、百分比、價格等數據類型。

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

案例解析 | 10個表格加分項設計(加了億點點細節

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

案例解析 | 10個表格加分項設計(加了億點點細節

當然具體使用什么樣式,需要結合具體場景做判斷,不能純粹為了差異性和視覺效果做改變,任何優化都需要在最后和用戶做確認確保它們的有效性。

四、單元格內的文字樣式

前面提的是我們要讓單元格的不同數據類型被表現出來,而這里我們要講的就是純文本樣式了。

雖然很多表格中確實主要以文本為主,不適合將內容替換成不同的數據類型,但文本和文本之間,也是有區別的。

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

案例解析 | 10個表格加分項設計(加了億點點細節

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

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

案例解析 | 10個表格加分項設計(加了億點點細節

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

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

案例解析 | 10個表格加分項設計(加了億點點細節

五、單元格的內容堆疊

在一般的表格設計中,我們默認一個單元格包含一行的內容,因為這符合傳統 Execel 的設計邏輯,每一個單元格要匹配表頭的內容。

但是,這個邏輯顯然在復雜的 B 端項目中是不成立的,因為很多規定只是死的,但設計師是活得……

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

案例解析 | 10個表格加分項設計(加了億點點細節

再或者,直接將同類數據合并進一個單元格中,在單元格另外添加每個數據的標題,也不會直接影響查看。比如 Coding 中的列表案例:

案例解析 | 10個表格加分項設計(加了億點點細節

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

但是,它同樣存在局限性,就是被合并后會難以進行排序,因為一個單元格內包含好幾項內容,精確排序的結果就難以呈現出對應的規律結果。

所以合并信息內容必須添加一個條件,就是被合并對象沒有排序的需求,或者整個單元格有個明確的主體字段,排序只以它為標準。

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

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

首先,因為人眼 F 型的瀏覽習慣,可以直接默認單元格是左對齊,然后找出不符合左對齊條件的那些信息數據,對它們進行居中或右對齊的處理。下面一項項解釋。

1. 最右操作列右對齊

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

案例解析 | 10個表格加分項設計(加了億點點細節

但如果最右側的內容不是常見的操作而是長文本,比如地址、郵箱,那么依舊只能左對齊,因為文本的閱讀是有連續性的,只適合從左側讀起。

案例解析 | 10個表格加分項設計(加了億點點細節

2. 價格類數字右對齊

對于價格或一些統計總數,我們也需要使用右對齊。因為這些數字位數較多,我們在表格中查看它們的主要順序就是先確定位數,再看具體數值。比如 82000000000,那我們要做的第一件事必然是數 “0”。

因為位數長度不同,再通過千位分隔符,還可以對上下單元格進行數額大小的對比,提升查看效率。

案例解析 | 10個表格加分項設計(加了億點點細節

但是,不是所有長數字都要右對齊,因為有些數字組合是沒有位數價值的,比如手機號、數字 ID、年月日等等,它們依舊只適合左對齊。

3. 固定長度的短數據居中

最后一個,就是一些固定長度的短數據類型,比如球員號碼、狀態標簽、百分比、圖標,都是適合進行居中排列的。

案例解析 | 10個表格加分項設計(加了億點點細節

之所以加 “短” 字,就是因為只有數據內容短,居中對齊看起來就整潔干練。但類似手機號、長ID 這些內容,雖然長度也一樣,但居中的效果會非常違和。

七、表格中的批量操作

表格往往會包含批量操作,在復雜的業務場景中確實可以延伸出非常復雜的交互邏輯。我們首先來解釋它的常規交互形態,然后再自己根據實際場景進行優化。

首先,批量操作必然要包含兩個關鍵的要素,多選框和操作列表。多選框用來進行批量選擇,操作列表則是對選中的內容進行處理的按鈕區域。

案例解析 | 10個表格加分項設計(加了億點點細節

建議將可以操作的選項做到表格的左側,類似上方的案例,不管是放在表格上方還是下方都可以。但非常不建議將操作區域放到表格的右上角去,因為選擇和操作的距離太遠,不僅操作起來麻煩,在不熟悉系統的情況下還很難找到操作項。

案例解析 | 10個表格加分項設計(加了億點點細節

也建議操作的選項能在選中被激活時和默認狀態有一定的區別,讓用戶操作過程明顯感知到選中后應該在哪個地方進行操作選擇,可以參考百度云、阿里云的批量交互。

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

八、表格內容的修改

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

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

案例解析 | 10個表格加分項設計(加了億點點細節

既然是表格,那查看、檢索、批量操作才是它的主要功能,不能因為我們可以去編輯它而把它強行表單化。比如將可以修改的文本直接做成輸入框,隨時可以編輯,頁面的觀感就會充滿不確定性(等著你去改)……

案例解析 | 10個表格加分項設計(加了億點點細節

而且改完之后怎么將修改的數據覆蓋原有的,是添加確認按鈕,還是直接光標從現有區域移出后就完成覆蓋?不管哪種操作效果都不好。

所以我一般建議在可修改的表格中,對允許修改的選項添加操作提示圖標。文本必須再點擊后才進入編輯模式,且必須有修改后點擊確認替換原數據的操作過程。

案例解析 | 10個表格加分項設計(加了億點點細節

這么做看起來確實操作變長了,但這是變難用了嘛?再回到前面的要點重復一遍,這是一個表格。還要在這個地方查看信息、復制現有信息,要防止操作太容易,導致誤操作替換了錯誤的信息進去……

九、堆疊表頭的設計要點

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

案例解析 | 10個表格加分項設計(加了億點點細節

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

案例解析 | 10個表格加分項設計(加了億點點細節

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

這種情況先完全忽略掉表格的美觀性,就重點考慮數據的識別性。

因為數據太多,沒有表頭作為提示是不可能認清數據是什么的,所以首先要確保表頭是可以始終存在于視圖區域內容不會被滾動走的。

第二點,既然都用堆疊對表頭做分組了,目的當然是為了強調它們的從屬和上級分類,如果只是像上面案例這樣簡單的用線段分割,那在實際查看過程基本是沒有多少幫助的。

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

案例解析 | 10個表格加分項設計(加了億點點細節

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

這種要羅列大量數據的表格,和前面的表格確實已經快變成兩個物種了。強烈建議大家在 Excel 內先創建出一個 1:1 的數據表,并模擬實際業務操作去動手,你就會產生完全不同的認識,而這是用圖文分享沒辦法詳細解答的感受。

十、序號和ID的認識

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

首先要理解,ID 是表格每個行的唯一標識符,比如學生列表,學生姓名年齡生日都可以完全相同,但ID才是系統區分他們的唯一指標,所以ID的存在是用來做數據對象的標識的。

而序號,則是獨立于數據對象之外,用來標識表格中數據對象的序列,這在 Excel 中的側邊欄是必備的顯示內容。

案例解析 | 10個表格加分項設計(加了億點點細節

本質上說,這個序列和數據對象其實是沒關系的,不管你做了什么篩選、排序、修改,序號1使用就是表格中的第一個對象,2就是第2個,以此類推。

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

這些例子并不多見,所以想不明白序號存在的意義,產品業務方也給不出理由,那就不需要放!

結尾

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

感謝大家收看!

作者:酸梅干超人;公眾號:超人的電話亭(ID:Superman_Call)

本文由 @超人的電話亭 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash ,基于 CC0 協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 原來設計表格也有這么多講究!下次不會說”這里放個表格就行,表頭是…”了!

    來自遼寧 回復
  2. 說實話,讀長文章確實現在困難了,退化了不過我讀完了,很受益

    來自河北 回復
  3. 學到了,謝謝分享

    來自北京 回復