想象一下你爲企業端產品設計了一個系統，或是設計了某個應用程序。在諸如此類的設計中都需要用到表格。這些表格設計不是那些設計網站中展示的非常精美的表格樣式，而是具有複雜交互和數百個單元格的表格。
在這種情況下，設計師會面臨許多挑戰。 例如：將設計與現有的前端框架進行匹配，或與破壞佈局的“不舒服”數據進行鬥爭。 我們將通過以下步驟來解決這些問題：系統化需求，原子化，定義交互。
1.系統化需求
所以，你已經採訪了目標受衆。現在是時候將他們的需求和需求拼湊在一起，並轉化爲對設計有用的東西。例如，一位用戶說：“我需要看看我的數據如何影響應用程序的其他部分。”或者在看到另一個人使用軟件時，你注意到他只使用快捷方式而根本不摸鼠標。這是什麼意思？第一個用戶的話是關於輸入驗證和提示。你需要考慮將警報或幫助信息附加到表中，或者開發一個有意義的顏色系統。這取決於領域和心理模型。觀察第二個用戶的工作可能是你需要設計鍵盤可設置快捷方式，可能需要考慮比“Cmd + C”和“Cmd + V”更深刻的快捷方式。
這樣，你就有一系列的需求和願望。開放式問題有助於找出真正的需求並過濾掉一時興起。例如，“什麼可以幫助你更快地工作？這如何提高你的工作效率？如果你不能做XX會有什麼改變？“
這時候就需要一個功能框架了。如下圖
任何表的最小構建塊都是一個單元，聯合成行和列，其具有不同於其他單元的特定特徵。 最後，我們將表格的重要補充作爲頂欄，鍵盤命令，處理錯誤等。
簡而言之，構建一個複雜的表，收集並優先考慮用戶需求。 考慮非表格解決方案，例如圖表。
繪製一張樹形圖，系統化所有需要的功能。
2.原子化
原子化是首先設計小的UI組件然後組裝更大的UI組件。 我們將逐漸從字體和顏色等基本粒子轉移到像標題或列這樣的大模態。
字體，顏色和圖標
這些部分可以由設計系統或UI框架定義。 如果爲現有產品創建表，請檢查調色板，字體和圖標是否滿足表格的需要。
單元和配件
當表格原子設計準備就緒時，我們可以繼續設計不同類型的單元。 首先要事先考慮每個元素的“正常”，“懸停”和“激活”的狀態。 後面再添加“點擊”，“禁用”和其他狀態。
單元格可以有工具提示，輸入提示，錯誤消息，佔位符等附件。
行和表頭
設計單元格創建行時，需要查看各種組合是否可以很好地協同工作。 下面我在一行中展示了只讀和可編輯單元格的。 一旦設計一個具有複雜編輯邏輯的表格，那麼表格的某些字段由用戶提供，而其他字段則使用默認值自動計算或填充。
需要注意的是，將鼠標懸停在只讀和可編輯單元格上時，光標會有所不同。 點擊單元格會觸發選擇行或進入可編輯單元格的編輯模式。 你可以在下圖看到用戶選擇一行或多行時的單元格狀態。
現在是時候考慮表頭了。 根據我的經驗，通常無法控制列標題長度並堅持一行。 我在下圖展示了表頭的不同變體。
基於數據的工具，用戶經常需要排序和過濾。 它可以幫助用戶在冗長的數據中找到有價值的信息。 排序和過濾的挑戰是將排序控件和過濾控件與其他標題元素（列標題，度量單位等）結合起來。
與表格單元格不同，過濾器框通常在右側具有“重置”圖標，以便用戶可以查看未過濾的內容。
在示例中，有三種類型的過濾器框。 字母數字過濾器可以按字母和數字進行搜索。 它支持通配符 - 未知數量的未知字符。
日期選擇器過濾器具有日曆，其工作方式與其單元格相同。 允許用戶手動輸入日期並從日曆中選擇是一件好事。 如果他們知道他們在搜索什麼，那麼打字比點擊容易得多。 在我的一個項目中，我們允許輸入“01/25/2017”，“6 12 17”和“2016年9月4日”等日期，僅過濾一個月或一年。
列
複雜表的一個常見功能是固定列。 通常，包含關鍵信息的列（例如，元素名稱或狀態）不可滾動。
雖然表列應該巧妙地適應內容大小，但是當文本被截斷時會發生。 在這種情況下，列大小調整很有幫助。 用戶可以拖動列邊緣並查看長內容。
處理長文本字符串的另一種方法是：使用最長內容拉伸列或將內容折成多行。 第一種方法對於或多或少類似的文本字符串更有效。 如果看到全部內容對於人們來說比保持表格的垂直緊湊更重要，那麼第二個更好。
我們需要定義列的默認最小寬度，以防止表格不適合調整大小。
頂部操作區
什麼構成一張表格？ 單元格，列，行。 此外，複雜的表通常有一個頂部操作區。 與其他組件一樣，頂部欄由較小的元素構成 - 標題和命令。 下面我收集了我們在其中一個產品中使用的各種狀態的命令列表。
現在我們可以嘗試組合不同的元素，看看它是否有效。 這裏有些例子。
當然，這不是功能和元素的最終列表。 它不同於一個項目，可能包含其他內容，例如：
按多列排序;
可自定義的列;
可擴展行;
用於過濾和搜索的邏輯運算符（“和”，“或”，“其他”等）。
如果你猶豫要設計哪些功能，哪些沒有，可以參考奧卡姆的剃刀，或簡約法則。 如果現有的實例滿足需求，則設計者不應創建新實例。 你應該“削減”用戶可能需要的令人討厭的功能。
全表格
只讀表格。 要構建的最簡單的表類型，因爲它只顯示數據。 沒有過濾或編輯選項。
搜索表格。 單元格不可編輯，標題有過濾框和排序控件，可以選擇行。 從實踐來看，這些表格有助於從大量類似的東西中查找，比較和選擇一個項目或幾個項目。
可編輯的表格。 所有或部分單元格都是可編輯的，通常沒有篩選，因爲行的順序可能是自定義的。 這些表格通常會有工具欄並允許使用行執行操作。
簡而言之
從最小的組件開始。 然後逐漸走向更大的，最後，模擬整個表格。
事先考慮每個組件的所有可能狀態。
使用Occam的剃刀原則將元素數量保持在最小但覆蓋所有用例。
3.定義交互
構建塊不足以構建像表格這樣複雜的。設計師應該考慮“遊戲規則”，並設計視覺部分背後的邏輯原則和慣例。
容器與響應式
如何將表格放在界面中？ 例如，它會佔用現有容器中的一些空間還是一個單獨的模塊？ 這些問題的答案完全取決於產品，最好預見可能的問題並徹底定義原則。
有些應用程序使用線條或白色灰色“斑馬線”來使信息更易讀。
定義合理的默認寬度，並允許在需要時手動調整大小。對於閱讀表格，最好在右邊有一些空格而不是列之間的間隙。但是如果一個表包含許多行和列，則水平和垂直滾動是不可避免的。對於手機端的閱讀，還可以把表格做成卡片式利於用戶瀏覽數據。
可訪問性
即使是非常流暢和漂亮的表格也可能成爲用戶的噩夢。因此，遵循可訪問性原則非常重要。 以下是可訪問性方面的主要設計考慮因素。
給出標題並準備簡明的摘要。視力受損的用戶應該能夠在不對其所有單元進行語音處理的情況下處理表格。
注意字體大小。儘管網絡沒有正式的最小尺寸，但16 px（12 pt）被認爲是最佳的。此外，用戶應該能夠在不破壞整個佈局的情況下將表格增加到200％。
爲有色盲的人測試顏色。文本和控件應與其背景具有足夠的對比度。最低要求色比3：1（越多越好）。顏色不應該是標記事物的唯一方式。例如，錯誤消息不應僅依賴於紅色文本，警告圖標將爲色盲用戶提供參考。
避免使用小而模糊的控件。如果可點擊組件至少爲40×40像素，則認爲它們是觸摸友好的。由圖標表示的命令應標記或具有工具提示和替代文本。設計師不應過度使用圖標，因爲用戶可能無法正確理解複雜的隱喻。
簡而言之
內容統一和格式化也是設計師的工作。
不僅要考慮界面元素，還要考慮用例，規則和常用模式。
原文：https://medium.muz.li/complex-tables-356826d11861
譯者：Ever
相關文章推薦：