起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識設計分享：設計可復用表格
“如果我有一個小時去解決問題，我會花55分鐘去思考這個問題，然后用5分鐘來想解決方案。”——佚名
我們是來自CareerBuilder的交互設計師Havana和視覺設計師Ada，我們的視覺設計負責人Mark Patterson給了我們一個任務：設計表格的UI規范，用在包含不同用例和不同目標用戶的產品線上。我們使用到的方法涉及到快速確定目標和問題的核心，并在早期通過測試驗證我們的想法。生成高效的解決方案，快速獲得團隊認可，最后使用用戶測試進行驗證。
表格設計是一件有挑戰性的事
當我們審閱各個產品團隊的原型時，我們發現這些表格是不一致的——它們有多樣化的UX設計解決方式。尺寸、鏈接、CTA、過濾器、排序以及分頁到處都是：
（其他產品線上的表格）
我們需要一種能夠普遍服務所有產品的用例，并且適用于未來將會出現的產品和功能模式。
我們的視覺設計主管發出了特定的用戶界面元素，我們承認，當我們被分配到表格設計時，我們很害怕。表格是一個幾乎每個產品都使用到的模塊。GareerBuilder這個產品服務于多種類型的用戶：求職者、招聘人員以及人力資源部門。每個產品在使用場景、用戶目標以及功能上都存在巨大差異。我們如何才能創造出足夠靈活的表格呢？
更重要的是，我們都在不同的城市，所有的協作都必須遠程進行。
開始設計
接到表格設計的任務后，我們立馬開了一個一個小時的電話會議。我們的目標是往后退一步，回到全局：
1.用戶一般使用表格上做些什么？在電話會議上，我們查看了pattrns.com的幾個例子，推斷表格背后的用戶目標。我們最終總結出了3個用戶目標：
- 一次性瀏覽大量信息，例如：展示多個項目以及對應的狀態
- 快速確定并執行操作，例如：刪除多行、下載多個項目等
- 對比信息，例如：有多少個項目完成，有多少個項目正在進行
（一些表格的例子）
2.表格設計上最大的難點是什么？我們需要設計一個支持排序、多選、批處理以及數據分組的表格。并不是所有的表格都需要這些功能，但是這些特性都是我們需要討論的。
3.表格可以被模塊化嗎？我們把表格分成這些模塊：
- 分頁
- 擴展視圖
- 編輯模式
- 行為召喚
- 定制
- 單元格截斷
- icon/圖片的使用
- 未讀/已讀標識
在5周里，我們碰面了4次，共享我們所獲取的信息，在目標和思考方向上達成共識。會議后，我們研究了各自分配的組件并有了一些初步的想法。我們把這些想法收集起來，并且在5天后開了一次會議。在這個早期迭代會議上，我們的目標是簡單地展示初步解決方案。
基于許多我們不熟悉的用戶案例，我們想通過測試來驗證這些想法，剔除存在的可用性問題、功能缺陷，指出潛在問題和我們的想法。參與的不僅僅有用戶體驗團隊的成員，還邀請了主要開發人員來確保我們的想法在技術上是可以實現的。我們開這個會，就是為了為了避免浪費時間在最終迭代會失敗的問題上。同時也保證了整個團隊可以快速進入狀態。
（表格相關的一些筆記和草圖）
我們取得了一些反饋，接著我們開始新一輪的迭代來調整我們所發現的問題。我們中途還進行了一次會議，來確保各自的項目進度，確定已完成工作和接下來的工作。然后在展示給團隊的會議上縮小選項提交并校對，確保我們不錯過任何狀態。
在這個過程中，我們使用sketch以及craft裝載的公司內部樣式庫。
（我們的工作流程）
表格的組成
如果你正在設計一個表格，我們對不同組件進行的處理可供參考（我們使用了虛擬的數據）：
分頁
之前，我們使用的是簡單的數字分頁。想象一下在幾百個頁面中跳轉到563頁會怎么樣？連續翻562頁是一個非常痛苦的體驗，所以我們引入了一個“跳轉至頁面”的下拉菜單。同時包括一個“每頁顯示x個結果”的下拉菜單，讓用戶能夠自定義他們想要看到的內容。分頁展示是這樣的：
（分頁）
然而，我不是很確定如果我在第4頁時，這個分頁是什么樣的。
（用戶瀏覽不同頁面時分頁的展現）
最后，我們允許各自的產品團隊來決定哪一類的分頁最適用于他們的產品。
“當你設計一個適用于多個產品的組件時，你必須要變得靈活”
（分頁的不同展示選項）
我們在設計分頁時學到的最主要的東西是：循序漸進，深入挖掘，發現背后隱藏的復雜性。（警示：總是有一些隱藏的復雜性。）
編輯模式
我們所做的產品中一個特性是可以編輯特定單元格，當前的設計方式是讓所有可編輯的單元格在視覺上保持一個文本輸入框的樣式。這造成了一個令人困惑的體驗——用戶該怎么去保存這些編輯過的數據呢？目前的設計并不明確。
（可編輯內容以文本框形式展示）
另一個問題就是這樣容易造成誤操作。用戶很容易意外編輯了錯誤的單元格——它可以取消嗎？它會自動保存嗎？其中的交互并不明確。
這種模式的好處是能夠很清晰地展示什么是可以編輯的，什么是不可以的。在上面的例子中，用戶可以修改藝術家的名字以及郵箱地址，但不能更改日期。我們最終決定保留這一優點，但是更精確地符合用戶的期望。
絕大多數用戶對特定的圖標很熟悉，像“鉛筆”、“復選”以及“取消”圖標。鉛筆圖標用來表示可以編輯的內容，我們決定在設計中采用這一點。
（編輯圖標：默認時顯示灰色）
起初，我們使用灰色的鉛筆圖標，當用戶鼠標hover上去的時候，它便轉變為高亮的顏色。一個同事提出了一個可用性的點：移動端用戶怎么辦？移動端沒有懸停狀態，也就無法展示圖標的懸停狀態，那么用戶是否能夠識別出這個灰色的鉛筆圖標是可以點擊的呢？我們構建了一個用戶測試環節來得到這個問題的答案。最后測試的結果顯示在大多數情況下，他們都完全忽視了這個灰色的鉛筆。我們的解決方案是把鉛筆換成超鏈接的顏色，這樣用戶就可以很快找到它的位置。
一旦用戶點擊這個圖標，文字輸入框的旁邊會顯示出一個綠色的勾和一個紅色的關閉。從測試中得出，用戶很容易知道如何在點擊鉛筆后修改單元格的內容。
我們原來擔心在操作列之外放一個編輯操作，因此我們對此進行了一個測試。7/10個用戶直接選擇使用那個鉛筆圖標，即使他們看到了那個下拉菜單。用戶一致建議這個鉛筆應該使用藍色，因為有些人并沒有立刻注意到它。
用用戶的話來說：“灰色的編輯按鈕太弱了，很難發現，但是當你注意到它時，使用起來就非常簡單。我很喜歡它，非常棒?！?/p>
（最終的編輯模式）
行為召喚
如上所述，CTA的處理在所有原型中差異最大。有時候CTA放置在表格頂部，有時候放置成一個按鈕，有時候又是單元格中的一個按鈕、圖標，或是下拉菜單中的元素，到處都是。
既然用戶使用表格的目標之一是快速處理，我們必須讓用戶在進行處理時不需要瀏覽整個表格。它們必須被放置在一個固定的位置。同樣還有其他問題：CTA可以作為行末的一個文字鏈接嗎？還是在表格的頂部？它們需要用icon來表示嗎？如果多于4個操作的話該如何顯示？我們該如何保持其他欄的狀態？我們最終定下了一個規則來放置所有的操作：
a.表格每行只有一個操作：展示為圖標+標簽
b.表格每行有兩個操作：展示為文字鏈接
c.表格每行有多于2個操作：以下拉菜單的方式展示
我們直接展示了兩個操作，讓用戶可以快速地使用它，但是當操作多于2個時會占據很大一部分位置，所以我們將它們放在下拉菜單中。經過幾輪迭代后，我們主要爭論的一點就是是否要使用帶圖標的標簽，但是由于我們不太清楚未來有哪些潛在用例，所以我們決定使用圖標，也可以迫使設計師來用圖標來描繪一些難以理解的操作。
（編輯模式）
如前所述，唯一一個沒有放置在下拉菜單中的操作就是“編輯”。編輯使用帶鉛筆圖標的方式放置在對應的單元格內以允許內聯編輯。放置在單元格內給用戶設定了可以編輯單元格的預期，而不是讓他們認為整行都是可以編輯的，進而造成挫敗感。
同樣的，如何將一個操作應用到多行？單擊操作列，然后對多行數據進行操作將會是一個非常糟糕的體驗。我們借用了Gmail的模式，選中一行后，頂部會出現一個批量操作欄。不過Gmail上的操作欄視覺上表現比較弱，我們使用了一個更加顯眼的顏色變化來吸引用戶的注意力。
（批量操作）
表格定制
表格中會出現許多標題和列的數據，有時數據顯示受限于表格的寬度。在某些情況下，可以允許用戶去選擇他們想要看到的表格列。要做到這一點，我們必須讓選項更清晰，當用戶的選擇已經達到上限時，我們通過灰化選項來表示。
（表格定制）
單元格截斷
在有限的空間里，單元格中的內容長度容易出現問題。我們是否允許文本在單元格內包裝？最初，我們受到Virgil Pana在dribbble發布的作品的啟發：
（Virgil Pana在dribbble發布的作品）
這是一個很棒的解決方案，我們和開發討論了技術可行性。
最終我們了解到即便它是可以實現的，這個表格也將會包含太多復雜的算法，可能會導致加載過慢的問題。這項工作是否值得花費過多的精力？另外，如果還要考慮到定制表格的選項，復雜度又會增加多少？再次，這就是為什么開發人員提早參與至關重要。我們最終認為這不是一個關鍵任務，并不值得花費太多的力氣，我們最終提出了用浮層來展示所有信息來作為一個替代方案。
（用浮層顯示具體信息）
圖片的用法
雖然我們還在琢磨表格的細節，我們對斑馬紋的設計已經有了一定的喜好，這時一個同事帶來了一個我們沒有考慮到的用例。在產品的一個頁面中，一個需求是上傳一個logo到表格中，由于logo不是透明的，當它出現在灰色行上時整個頁面會變得很尷尬。
在這個情況下，我們不可能只是簡單地忽略它，我們必須想出一個解決方案。這就是一個很好的例子，說明簡單的才是最好的?，F在，我們決定加上上傳透明png格式logo的引導。幸運的是，這里上傳logo的用戶都是客戶履行小組的成員，他們比一般的用戶要更懂技術。
當我們以為我們終于把斑馬紋確定下來了，另外一個同事提出了一個用戶案例是在單元格內顯示警告指示器。整個單元格的背景顏色都填充了警示的顏色來引起用戶注意力。 盡管從美學角度來說，這并沒有改變這個表格，但是它確實會有一些后續的問題。應該使用怎樣的不透明度？我們是否想要讓開發人員特殊處理單個單元格上的顏色？為了簡化它，我們決定使用圖標。但是如果用戶不容易注意到這個警告，我們還是會把重點突出。
（警示的兩種處理方式）
已讀/未讀標識
我們探索了不同的方式，如使用彩色圓點和豎條來標記未讀項目。點完全混合到表中。為了使它看起來更引人注目，我們還給那個點附著的文字加粗了。然后我們的同事提出了需要注意的一點：復選框。這個點是放在復選框旁邊還是文字旁邊？
（未讀的早期處理方式）
這個點在美觀上以及功能性上都變成了一個不太好的方案，所以我們最終選擇了豎條。這個豎條簡單有效地表示這行是未讀的，而且同樣是一種常見的模式。
（未讀狀態）
擴展視圖
有時，表格不能容納太多的項目數據。在涵蓋大量應用數據的情況下，在數據表中擴展行是一種常見的模式。我們使用一個模式對相關的擴展內容進行分組：
（擴展視圖的一個例子）
展開的那一行是灰色的，與其他的行區分開。相關內容放置在它的內容區域中。
我們同樣受到了另一種模式的啟發，這個模式中，統一欄將行和擴展內容綁定在一起，這樣便使得這些內容看起來是有關聯的。
（擴展視圖的例子）
我們決定將兩種方案結合起來，我們把擴展行做成了藍色，并在左側添加統一欄。
（第一個方案）
（第二個方案）
第一種方案看起來太像一個選中狀態了。深藍色的欄像具有某個含義，并且我們之前已經使用這個豎條來表示未讀行了。我們現在如何區分未讀狀態和擴展狀態呢？為了避免混淆我們的用戶，將它們合并為一個統一欄？
（第三個方案）
最初我決定加大寬度同時改變顏色，但是加大寬度以后看起來比較突兀，同時還是很像未讀狀態。我們向團隊展示這個解決方案，最終他們提出了一個更好的方案：和未讀狀態使用同樣的寬度但是用灰色來表示。
（第四個方案）
視覺規范
邊距和間距對于視覺設計來說至關重要，需要標注給開發來確保最終實現的視覺完整性。我們創建了這個指南，這樣我們的團隊不管做的是什么產品都可以設計出具有一致性的表格。
（邊距和間距的標注文檔）
呈現并測試
這些表格收到了來自內部團隊的積極反饋。當然其中有許多我們還需要去改進的東西，但是許多組件都得到了批準，并交付開發。
但是即使我們得到了積極反饋，我們仍然想要驗證我們的假設：這對外部是否像對我們一樣？用戶是否知道下拉菜單的操作？編輯操作的例外是否令人困惑？分頁是否清晰？我們和用戶研究員Kiayni Spearman 和Michael Pate組成了一個團隊，通過UserTesting.com進行一些基礎的可用性測試。用戶研究員幫助我們設計了一個測試，提示用戶做這三件事：
- 讓用戶去執行一些操作
- 問用戶列表中有多少個項目，它們在哪個頁面上
- 讓用戶編輯某個人的郵箱地址
UserTesting.com上的10個視頻全部在發布后兩個小時完成。
用戶研究結果
關于在下拉菜單中尋找操作：
“盡管沒有一件刪除賬戶的按鈕，但是我認為還是很直觀，因為表格頂部的標題非常清楚地告訴我在哪里可以點擊來查看我可以對該條目執行操作的列表。我非常清楚如何繼續刪除這個條目，即便我是第一次使用這張表。”
“我（本該）意識到操作欄（并且猜測）其他的操作會放置在那里”
然而沒我們的測試表明分頁對參與者來說有一些混亂。但是，得益于我們團隊和參與這的真實的反饋，我們明確了我們需要做的方向，而不是原地停留。
主要收獲
我們從制定表格的標準和主要模式中學到了很多，在問題解決上，我們了解到：
- 提前見面并寫下目標，退一步思考一下為什么
- 多花一些時間定義問題，而不是解決問題
- 首先拋棄糟糕的想法，及早向大家展示你的想法，并分析推遲、批判、問題等。讓多方提前參與，避免在不可行的方案上浪費時間
- 將它分解成小的，更可行的組件并多討論，發布這些組件以及最終的交付成果
- 保持自我。因為我們在早期就定義了我們的目標，所以把注意力集中在這個問題上，放下對解決方案本身的任何情感依賴，這樣就更容易接受和實施反饋
第一次翻譯，請多指教。
譯者注：CTA（call to action）指的是網站中用于提示用戶點擊并且進入下一個轉化流程（conversion funnel，如支付、繼續閱讀等）的橫幅、按鈕、或某些類型的圖形和文字。它是入站營銷和許可營銷的必要組成部分，致力于吸引用戶進入引導流程，繼而將用戶轉化為顧客。
譯者： janedaring
原文：Havana Nguyen發布于Medium
鏈接：https://uxdesign.cc/designing-tables-for-reusability-490a3760533
本文由 @ janedaring 翻譯發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自unsplash，基于CC0協議
很實用
很贊