設計完美的功能對照表

不過，功能比較表不僅在它們的主要功能上很有幫助。 如果設計得當，它們可以幫助做出決策，而不僅僅是將產品規格並排放置。 他們還可以為原本過於技術性的產品規格表增加意義，解釋為什麼某個功能與客戶相關，或者某個產品如何比其他產品更好。

在仔細檢查了手風琴、時間和日期選擇器和滑塊之後，在本文中，我們將研究構成完美、易於訪問和有用的功能比較表的所有細節。 請注意，本文不一定是關於定價計劃，也不是關於數據可視化方法。 相反，它專門針對客戶想要確認他們的購買選擇或無法在多個預選項目之一之間進行選擇的情況。

在深入設計決策之前，我們需要正確理解用戶的目標、意圖和行為模式。

什麼時候功能比較有用？

在觀察一些電子商務項目中的客戶時，我發現比較功能對許多客戶來說似乎是多麼無關緊要，這很有啟發性。 用戶經常會說它使界面混亂，並且他們從不使用該功能。 原因很簡單：雖然我們傾向於經常購買小而低價的物品，但我們往往不那麼頻繁地購買大件的高價物品。 事實上，我們真正需要進行特徵比較的情況並不多。

沒有多少顧客會考慮比較幾本書或幾雙襪子。 然而，相對較少的客戶會在沒有徹底探索他們的選擇的情況下購買咖啡機或冰箱。 特徵比較對於“小”購買確實無關緊要，但對於“大”購買變得很重要。 事實上，當客戶一心想要大額購買，但又無法選擇購買哪種產品時，他們很可能最終完全不購買，陷入選擇麻痺狀態。 作為零售商，我們顯然希望避免這些死鎖情況，這就是特徵比較元素非常有用的地方，它可以簡化決策過程並過濾掉不符合相關標準的商品。

後者可以應用於非常不同的環境：我們可以比較位置、場地、眼鏡、汽車、行李、手錶、電視機甚至化學品。 但是，在本文的範圍內，我們將專注於電子商務零售商之間非常具體的功能比較。 我們將在這裡學到的課程可以應用於任何類型的比較環境，儘管細節可能會有所不同。

不管怎樣，最終，這一切都歸結為客戶將要進行什麼樣的購買。 正如 Joe Leech 在他關於購買決策的精彩網絡研討會中所說的那樣，在網上購物時，用戶會考慮“未考慮”或“考慮”購買。

未考慮的購買

未考慮的購買是我們在需要快速解決方案或跑腿時傾向於進行的快速、省力的購買。 每當我們需要一包電池、普通文具、“足夠好”的烘乾機或快速的周末度假時，我們實際上正在做的就是從我們的待辦事項清單上勾選一個框並繼續前進。 很少有人會對選擇電池或鉛筆感到興奮，因此我們不太可能為了購買完美的包裝而多次瀏覽不同的網站。 相反，我們傾向於快速購買此類商品，通常是在旅途中，略讀供應商評論並根據價格、運輸速度和便利性進行購物。

考慮購買

另一方面，考慮購買是緩慢、費力的購買，需要時間和考慮的購買。 當我們購買自行車、手錶、冰箱或健康保險時，我們會徹底探索我們的選擇，確保我們最終不會得到不夠好或不合適或需要更換的東西很快。 在這種情況下，我們往往會在很長一段時間內不斷探索可能的購買，經常瀏覽許多不同的零售商，比較價格，閱讀評論和檢查圖片。 我們甚至可能會詢問我們的朋友、同事和親人的意見。 最終，最終決定是基於預期的質量和服務，而不是便利性和速度，並且不一定僅受價格點的影響。

當然，一件物品越貴，就越需要考慮。 但經過深思熟慮的購買不一定很昂貴：任何具有特定屬性的物品，例如壽命、速度或質量，也必須徹底考慮。 這包括禮物、鮮花、葡萄酒和烈酒、衣服、抵押貸款和健康保險。 原因很明顯：很難對一包電池感到非常失望，但一件不舒服的禮物，或者錯誤的鮮花傳遞了錯誤的信息，甚至是一件不得不退回的不合身的襯衫，都可能是一件非常令人失望的事情。令人沮喪的經歷。

沒有多少人事先確切地知道他們想要或需要什麼，除非他們得到值得信賴的推薦。 因此，每一次深思熟慮的購買都需要大量的思考和考慮，比較不同的選擇並篩選出完美的選擇。 問題是比較在網絡上並不是一個特別有趣的活動。 經常缺少細節，價格不透明（您多久將商品添加到購物車並通過整個結帳直到付款，才看到真正的最終價格？）和型號（例如電器）是不一致。

這就是精心設計的功能比較可以增加銷售額並提高用戶滿意度的地方。 如果我們設法在猶豫不決的時刻（在他們離開網站或開始四處尋找之前）找到優柔寡斷的客戶，並巧妙地引導他們做出正確的決定，那麼我們正在努力提供更好的客戶體驗，同時也佔更大的利潤和更忠誠的業務客戶群。 畢竟，客戶在購買（通常）昂貴的商品時不必在其他網站上貨比三家。 這可能會在未來幾年為業務帶來成果。

在這一點上，特徵比較主要與考慮購買相關，這可能不是什麼大啟示。 它們在產品相對複雜的情況下特別有用——可能包括可能令人困惑或模棱兩可的細節。 數碼相機和電視就是很好的例子——為了對選擇進行明智的比較，通常需要了解這些設備的技術能力。 另一個例子是假期或商務旅行——任何需要許多小決定的事情，例如可用性、定價、方便的出發和到達時間、預算以及事先對活動的全面規劃。

究竟是什麼讓比較與客戶相關？ 好吧，如果它可以幫助用戶做出明智的選擇，那麼它就是相關的。 可以設計一個特徵比較來推動更多的客戶轉向“高利潤”的邊際銷售，但如果它們不合適或者如果客戶覺得他們多付了錢，那麼零售商將不得不處理大量的從長遠來看，退貨或用戶完全放棄它們。

當我們觀察和採訪用戶以了解特徵比較與他們的相關性時，我們發現它基本上歸結為一件事：看到選項之間的差異，或者快速過濾掉不必要的細節，使差異變得更加明顯. 不幸的是（並且令人驚訝），許多功能比較並不是特別擅長於此。

特徵比較的基石

如果我們想比較兩個或多個項目以找到更合適的，那麼最明顯的方法是什麼？ 對於衣服，我們會試穿並挑選感覺合適的那一件。 但是，如果試穿不是一種選擇呢？ 在線購買產品時，我們可以依靠我們過去的經驗、評級、專家評論、客戶評論和值得信賴的建議，將選擇範圍縮小到幾個候選人。

儘管如此，在某些時候，您可能會留下一些過於相似的物品——也許一件太貴了，另一件缺少重要的品質，第三件是朋友的朋友推薦的。 所以你會怎麼做？ 你列出所有選項，並排檢查它們的屬性，並消除選項，直到你有一個贏家。 （好吧，至少大多數人都這樣做。）

轉換為常見的界面模式，這自然需要有助於快速掃描選項的結構化佈局——可能是一個很好的比較表，其中包含產品的列和屬性的行。 一旦用戶選擇了產品並提示了比較視圖，我們就可以從所有選擇的產品中提取所有屬性並將它們列為表中的行。 應該很容易吧？ 是的，但這不一定是進行有意義比較的最佳方法。

並非所有屬性都是平等的

理想情況下，我們希望只顯示客戶關心的有意義的、可比較的屬性。 與其提取和排列所有產品規格，我們可以確定並突出顯示所有相關產品屬性，同時保持所有其他屬性可訪問。 這要求我們 (1) 找出用戶感興趣的內容，以及 (2) 擁有關於我們產品的一致、結構良好的數據。

雖然第一個要求只是在 UI 中正確地構建問題，但第二個要求是一個難以破解的難題。 在實踐中，擁有結構良好的元數據通常非常困難，這不是因為技術或設計限制，而是因為內容限制。

除非零售商使用專門的、積極維護的系統來收集、組織和清理其庫存中所有產品的元數據，否則會得到結構良好、完整和一致的屬性細節——至少關於僅屬於同一類別的產品——結果成為一項重大事業。 您當然可以管理相對較小的服裝店的元數據，但如果您作為零售商依賴來自第三方供應商的規格，那麼有意義的比較將需要相當大的努力。

休斯頓，我們有一個（內容）問題

這就提出了一個問題：如果其中一個缺少關鍵屬性，您將如何顯示兩個數碼相機的比較表？ 在這種情況下，將無法進行有意義的比較，從而使客戶也無法做出明智的決定。 面對這種情況，與其盲目地選擇其中一個選項，大多數客戶會完全放棄購買，因為對購買錯誤產品的擔憂完全超過了對產品的渴望。

康拉德在一個表格中列出了所有產品，每隔一行以背景顏色交替顯示。 與許多其他零售店一樣，元數據通常不完整且不一致，使用戶一無所知。 在上面的示例中，三個比較產品中的兩個沒有提供 HDMI 輸入的數量、重量、亮點和播放器尺寸。

當項目難以比較時也會發生同樣的情況——例如，當許多屬性的結構良好的數據旁邊出現嘈雜的格式錯誤的數據時。 投入足夠的時間也許可以發現產品之間的差異，但這需要太多的工作。 在可用性會話中，當客戶提示比較視圖並掃描行一兩秒鐘，然後在幾秒鐘後放棄頁面時，您可以看到這種模式本身。 而且，一旦他們在網站上有過這種體驗，他們會普遍認為網站上的特徵比較是“壞掉的”，並在以後的會話中完全忽略它。

那麼，如果某些信息丟失、不完整或不一致，我們該怎麼辦？ 與其按原樣顯示比較表，不如通知用戶由於缺少有關特定產品的某些數據而無法進行比較，然後將他們引導到相關頁面（可能是比較產品的獨立評論）或問他們有關與他們相關的屬性的問題，並建議“最佳”選項。

這些屬性不是世界末日

按屬性進行比較很重要，但僅從規格表中提取和重組數據對於不那麼精明的客戶可能並不是特別有用。 事實上，用用戶覺得更容易理解的數據來擴展甚至替換某些屬性可能會有所幫助——例如，用用戶日常生活中的實際示例替換技術術語？ 還是提取產品的優缺點？

正如 Nielsen Norman Group 所指出的，在亞馬遜上，技術細節並未按原樣顯示。 相反，比較表將技術屬性翻譯成普通消費者可以理解的語言。 界面文案很重要：這適用於屬性以及按鈕、標籤和縮略圖上的措辭。

對於每兩個比較項目，Imaging Resource 會在列表中提取產品的優缺點，以及各自的優缺點。 這可能不是比較屬性的最快方法，但默認情況下它很好地區分了質量，突出突出了選項之間的關鍵差異。 該網站還提供評論摘錄並建議其他相關比較。

Versus 更進一步，在條形圖中突出顯示所選產品的平均功能與其他產品的比較。 不僅將所有屬性顯示為表格，它們還顯示在列表視圖中，並帶有每個屬性的詳細說明。 更好的是，該網站通過突出顯示該類別中最佳產品的表現如何，將每個屬性置於上下文中。 額外的好處是，如果社區成員發現每一個屬性都相關，他們可以投票贊成。 這比表中的單個屬性值對客戶更有幫助。

Cool Blue 有一個很好的功能比較：一切都剛剛好。 它不僅默認突出顯示相似和不同的功能，還突出了每個產品的優缺點以及每個功能的優缺點。 該界面還細化了特定功能組和客戶評論的評級。

Flipkart 在大多數類別頁面和大多數產品頁面上提供特徵比較，並從評論中提取優點、缺點和亮點。 這使得功能比較變得更加相關，並且可能更容易做出購買決定。

通常情況下，單獨的詳細規格表可能不足以進行有意義的比較。 使用更多細節擴展比較，例如相關評論、有用的改寫以及直接比較的優缺點，可以大大幫助客戶做出艱難的決定。

通過分組屬性清理混亂

上述所有選項都提供了快速、可掃描的優缺點視圖，但根據產品的複雜性，您最終可能會在列表中排列出 70 到 80 個屬性。 遍歷所有這些以找到客戶最關心的那些需要相當多的工作。

提高屬性可掃描性的一種方法是將屬性分組到部分中，然後在單擊或點擊時顯示和折疊它們。 這就是手風琴指南發揮作用的地方：在太多的界面中，只有圖標充當切換； 當然，整個欄應該打開或折疊屬性組。 此外，自動完成搜索框或過濾器可以讓客戶跳轉到部分或選擇和取消選擇類別進行比較。

家得寶不只是列出所有屬性，而是將它們分組為“尺寸”、“詳細信息”和“保修/認證”。 它還突出了產品之間的差異，並具有精美的打印視圖（可通過一個小打印圖標訪問 - 讓我們看看您是否能找到它！）。

Sharp 允許客戶從列表中選擇感興趣的類別，甚至可以使用自動建議快速跳轉到特定類別。 右側的複選框也允許用戶突出顯示差異 - 儘管突出顯示並不總是在視覺上清晰。

為了進行功能比較，德國零售商店 Otto 不僅將所有屬性分組，而且將每個組變成可折疊和可擴展的部分。 某些部分還包含有關屬性的詳細信息，通過點擊或單擊提供。

Garmin 走得更遠。 它不僅僅是在頁面頂部顯示下拉菜單，而是在用戶滾動頁面時將其浮動在產品旁邊。 這稍微好一點。

Rtings.com 為整個表格擴展了一個帶有過濾功能的下拉列表。 如果客戶對特定的一組屬性感興趣，他們可以選擇他們感興趣的確切值。 這是特徵比較表通常不提供的粒度級別，對於冗長的比較視圖特別有用。

最終，帶有屬性部分選擇的浮動下拉列表足以進行任何比較。 一般來說，稍微更好的屬性組織將幫助用戶導航到興趣點，但能夠輕鬆地看到這些興趣點內的差異或相似之處也將很有用。

突出差異或相似之處......或兩者兼而有之？

因為能夠輕鬆看到差異是比較的中心目的之一，所以考慮添加一個切換按鈕（如上面 Sharp 的示例）以允許用戶在僅查看差異、僅查看相似性和查看所有可用屬性之間切換是有意義的.

事實上，當用戶訪問比較表並註意到“顯示差異”按鈕時，他們通常會先向下滾動查看整個表，看看比較會花費多少時間，然後才返回到那個閃亮的按鈕，按下它並探索更新的視圖。

事實上，該功能似乎被大量使用，原因是可以理解的：看到差異正是客戶實際上首先提示比較視圖的原因。 這意味著突出差異的選項應該非常突出。 但是你將如何設計它，你會包括哪些選項，以及交互會是什麼樣子？

例如，在 MediaMarkt 上，客戶可以選擇查看所有屬性或僅查看產品不同的屬性。 “僅顯示差異”按鈕位於產品縮略圖旁邊的左上角。 讓它更靠近桌子可能會使它更難被忽視。 這家德國零售店對產品行使用備用背景顏色，但對標題不使用。 許多產品有 10 到 15 組屬性，每組屬性都可以顯示和折疊。 此外，每個產品都有完整規格表的鏈接。

突出顯示差異的問題在於，只要一行中的一個表格單元格中的一個字符略有不同就足夠了，並且整行不會消失——即使所有其他列具有相同、相同的值。 然而，與其僅僅按原樣顯示行，實際突出顯示差異會更有用——也許將所有“相同”的單元格折疊成一個單元格並突出顯示一個不同的單元格。

然後問題來了：一旦選擇了“顯示差異”，相同的屬性應該完全消失，還是應該留在表格中，只突出顯示不同的屬性？ 這可能是個人喜好問題。 如果有 60–80 個屬性要比較，我們可能會刪除相似的行以便於掃描。 如果表較小，則可能不需要刪除行。

例如，伊萊克斯在左上角包含一個按鈕，用作切換開關。 狀態用可以打開或關閉的複選標記指示。 具有相同數據的行不會從表中刪除 - 相反，差異以淺藍色背景突出顯示。

BestBuy 包含很多精確的數字數據，例如身高“69.88 英寸”和“69.9 英寸”。 由於差異如此之小，大多數行將永遠不會被省略，從而使比較更加困難。

只看到差異是有用的，但用戶也會從只看到相似處受益嗎？ 事實上，提供這個選項並不是很常見，但它有一些很好的用例。 事實證明，一個重要的場景是當所選產品有太多差異而無法輕鬆瀏覽時。

這是一個例子。 假設客戶選擇了四款數碼相機進行比較，每款產品都有 60-80 個屬性。 在開始穿越數十個屬性的漫長旅程之前，一些客戶會嘗試根據“簡單”標準排除選項，例如價格或發布日期、“太弱”或“太貴”或“不是最新”質量. 顯然，在刪除這些項目的同時，他們會希望確保他們沒有刪除錯誤的項目。 在這種特殊情況下，看到相似之處可以讓用戶確認他們“仍在”關注“值得比較”或“值得投入時間”的產品。

發生這種情況的主要用例是當客戶比較幾個強大、相似的候選人時。 它們可能在十幾個屬性中有所不同，但所有 80 個屬性的列表太長，無法輕鬆比較。 通過選擇僅查看相似之處或僅查看不同之處，客戶可以將復雜性分解為兩部分。 在這種情況下，您會注意到客戶傾向於首先處理“更簡單”的任務：他們會首先研究相似之處（只是為了確保所有選項都是“可靠的”），然後專門研究差異。

您可能想知道是否有必要提供所有屬性的概述？ 畢竟，客戶會檢查相同點和不同點。 答案是“是的”。 客戶不想錯過重要的細節，因為他們想確定所有可用的屬性，他們也會尋找和檢查“所有屬性”選項，在會話期間至少掃描一次。

在設計方面，一個明顯的解決方案是使用一組相互排斥的按鈕，或者只使用一個按鈕或鏈接來改變內容並基本上起到切換的作用。

三星不僅允許客戶查看所有屬性、僅相似之處和唯一差異，還可以選擇哪些屬性是相關的並僅通過它們進行比較，而刪除其他所有內容。 所有屬性都分組到手風琴中，所有屬性都可以一鍵展開或折疊。

LG 的界面與三星的類似，但“比較”鏈接有點太小了，而且由於始終可以點擊不同的視圖，因此並不總是清楚您在看什麼。 此外，我還沒有弄清楚比較視圖中產品縮略圖上方的“鎖定”項目是什麼意思——它可能意味著首先顯示項目。

在實踐中，當遇到切換視圖的功能時，客戶往往會在所有可用選項之間切換很多。 看到差異和所有屬性最重要，但能夠看到所有相似之處雖然不是必需的，但可能是重申和支持。

顏色編碼以便於比較

為了突出差異，我們可以刪除相似或相同的行，但我們也可以使用顏色編碼來指示比較項目的不同之處，以及哪些表現更好。 一個明顯的方法是在表格單元格上使用某種顏色或圖案。 例如，Zipso 為每個選定屬性的每一行的片段著色。 雖然它對一些屬性很有幫助，但當選擇其中的許多屬性時，演示文稿很快就會變得難以比較。

Prisjakt 默認使用表格單元格的顏色編碼來突出顯示差異。 此外，客戶可以通過點擊或點擊相關行來突出顯示相關行（儘管在點擊時，差異在視覺上不再明顯）。 每個比較也有一個唯一的、可共享的 URL。

ProductChart 使用背景條來指示哪些候選人在某個屬性上表現更好。 條形的長度表示其中一個選項的性能有多好。 稍微突出顯示獲勝者，或提供總分並建議獲勝者，在這裡可能會有所幫助。

數碼相機數據庫用填充的彩色矩形顯示產品之間的差異，以指示差異的大小。 這對於高度技術性和詳細的比較很有用，但對於每種功能比較不一定如此。

如果您的特徵比較表可能包含大量數字數據，則在點擊或單擊時突出顯示行和列可能很有用，以便用戶始終知道他們正在查看正確的數據點。

顏色編碼是一種突出差異的簡單方法，但我們還需要提供一種可訪問的替代方案，也許在表格上方的摘要中詳細說明產品之間的差異。

永遠不會消失的東西：浮動標題

你以前可能遇到過這種情況。 如果您要比較三個標籤模糊的產品，其中要比較的屬性超過 50 個，您可能很難準確記住一列代表的產品。 要仔細檢查，您需要一直向上滾動到標題，然後一直向下滾動以繼續探索屬性。

使映射不那麼緊張的一種明顯方法是使用粘性列標題，在客戶向下滾動比較表時跟隨他們。 我們不一定需要在標題中保留所有詳細信息，但提供產品型號的名稱、評級和小縮略圖可能就足夠了。

當用戶比較產品時，索尼會在比較表上方浮動產品標籤和縮略圖。 這為客戶提供了屬性和產品之間非常清晰的映射。 比較一下，快速查看標題就足夠了——不需要額外的滾動！

Indesit 以稍微不同的方式解決了同樣的問題。 該界面將縮略圖保留在屏幕底部的浮動欄中，而不是頂部。 添加項目時，它們會顯示在底部的欄中。 To add the items though users need to hit the comparison icon tucked in the upper-right corner of the product — it might not be easy to identify. Ah, also the entire “Compare models” bar should act as a toggle — in the implementation, only the chevron icon triggers expansion and collapsing.

So, if a floating bar is in use, should it float above or below the table — or does it even matter? Keeping headings above the content seems slightly more natural, especially when the thumb is hovering over the contents of the comparison view on narrow screens. Users need to be more careful when scrolling the page on narrow screens — which is why the bar in the Indesit example disappears entirely on mobile. Keeping the bar above the table just seems a bit more reliable.

Obviously, it's going to be very difficult to display all selected products as columns at all times. A table view works well if you have two to three products to compare, but probably not so well if there are five products in the table. In that case, a common way to conduct the comparison would be by sliding horizontally.

Growing And Shrinking Those Tables

No conversation about tables can omit a close look into their responsive behavior across screens. A discussion of tables deserves a separate post, but there are a few common tricks to keep a table meaningful on narrow screens. Quite often, each table row will become a collapsed card, or headings will jump all over the place, or the table will be restructured to expose the data better, or the user can select which columns they want to see.

問題解決了？ 沒那麼快。 The feature comparison table is a beast of a special kind. The main purpose of the element is comparison: Keeping both attribute headings and product headings visible is important — after all, the customer wants to see the products they are comparing and the features they are comparing against. This means that for easy comparison on narrow screens, we need to float product headings, while keeping the attribute column locked as the user scrolls down the page. That doesn't leave us with a lot of space to display actual product details.

Sadly, almost every other retail website makes feature comparison unavailable on narrow screens. Selected products will often disappear altogether, the comparison feature will be hidden, and loading a shared comparison link will appear to broken. In fact, it proved to be quite a challenge to find even a handful of examples out there.

Some interfaces try to make the best of what they have. Crutchfield's interface, for example, is responsive, but that doesn't mean it's useful. On narrow views, items are displayed in a 2 × 2 grid, and so are product attributes. Because there is no visual relation to the actual product, it makes it very difficult to compare features.

ProductReportCard displays products in sets of three at a time. The attributes of each products are squeezed into a 33% column on narrow screens, making reading quite tiring, and comparison quite difficult.

Urban Ladder allows its customers to shortlist and compare items in the product grid. Once the user hits the “Compare” button, they're presnted with a quick overview of similar products which are auto-suggested. On narrow screens, users can compare only two items at a time.

One way to manage this problem would be to avoid a table view altogether. Instead, we could highlight similarities and differences in a list by default , allowing customers to switch between these views.

Alternatively, we could ask the user to choose the attributes that they care about most, and once the input is done, we could highlight relevant features, and perhaps even pull some data from reviews, displaying both of them in a list. Every relevant attribute row could become an expanded card, while all less relevant attributes could be displayed as collapsed cards below.

As always, limited space requires a more focused view and since differences are usually what matter the most, highlighting them and removing everything else seems quite reasonable.

Admittedly, with all of these options, we are losing the big-picture view that a table can provide. If you'd like to keep a table, usually you'll have at most one column to fill in with actual content — as another column has to be reserved for attribute headings. To make it work, you could provide a stepper navigation between products, so that the user is able to switch between products predictably. In the same way, sometimes floating arrows are used left and right, similar to a slider.

OBI 允許客戶添加任意數量的產品進行比較。 在比較視圖中，表格中產品之間的導航通過左上角的步進器進行。 不幸的是，功能比較不適用於狹窄的視圖。

或者，您還可以在頂部使用分段控件或多組合選擇器擴展表格，允許用戶從產品比較列表中選擇兩個或多個產品 - 並將它們並排顯示。 使用兩種產品，用戶最終會得到一個可讀性強、響應迅速的比較表，並且選擇更多的項目，他們會得到一個可滾動的區域或差異和相似之處的摘要。 然後用戶可以選擇他們希望看到的內容。

那該選什麼呢？ 如果功能比較表主要包含數字數據，那麼預先解釋產品的差異可能更容易。 如果不是這種情況，或者表格的內容不可預測，那麼帶有stepper navigation的選項或多組合選擇器可能會很好用。 如果產品很複雜，屬性描述會很多且冗長，那麼提取相關數據並突出顯示它，而不是讓用戶經歷幾十個屬性的旅程，可能是一個更好的選擇。

在談論組件的響應行為時，我們傾向於關注“常規”和“窄”屏幕，但我們也可以探索“寬”屏幕的調整。 如果我們確實有足夠的空間在寬屏幕上突出顯示功能比較，為什麼不充分利用它呢？ 例如，當用戶瀏覽類別頁面時，我們可以將功能比較顯示為右側的浮動窗格，而左側區域可以專用於該類別中突出顯示的產品。 當客戶添加一個項目進行比較時，它可能會立即出現在並排比較中。 在他關於“響應式升級”的文章中，Christian Holst 提到了許多適用於大屏幕電子商務用戶體驗的技術。 它們也與特徵比較非常相關。

移動東西直到它們粘住

在比較表出現之前究竟發生了什麼？ 客戶可能會登陸一個類別頁面，選擇一些要比較的項目，然後發現一個提示比較的按鈕。 此時，客戶可能（或可能不）知道有關某些選定項目的詳細信息。 同樣，比較的選擇順序可能（也可能不是）是隨機的。 在顯示比較結果時，一個安全的選擇是按選擇順序顯示列，因為任何不同的順序都可能導致混淆。

當他們處於比較過程中時，客戶將（希望）開始更清楚地看到事物，過濾掉那些明顯優於選定競爭對手的產品。 為了清除比較視圖，我們將允許客戶從比較中刪除產品，當然，通常在列（或浮動標題）的右上角用“x”表示。

事實證明，有時用戶會很快忽略其中一個選項，例如因為它無論如何都太貴了，但他們希望將該選項保留在比較視圖中以供參考 - 只是為了將其他候選人放在上下文中。 該“參考”選項最終可能會卡在表格中間，妨礙兩個或更多“真實”候選人之間的比較。

顯然，這些選項的最佳安排是首先並排顯示主要候選，然後是“參考”候選。 事實上，您甚至可以允許客戶降級或否決一些候選人，並將他們推到一邊，以不太突出的灰色顯示。

一個稍微更健壯的選項是允許用戶隨意拖動列。 一開始，當客戶在列表中添加了相當多的項目時，這將有所幫助，但隨後，例如，意識到價格差異太大，因此想要重新排列產品。 對於“參考”候選人，這也將有所幫助。 事實上，在採訪中，用戶有時會將產品欄與卡片、小冊子或便簽進行比較，以便他們可以四處移動，將重要的內容與不太重要的內容進行分組。 功能比較表中相同體驗的數字等價物將是可拖動的列。

例如，在 Digital Photography Review 中，用戶可以左右移動所選項目。 這是拖放的一個很好的可訪問替代方案。

SocialCompare 的本質要求用戶能夠隨意拖動列和行。 但是，像卡片一樣移動列可能對零售網站的客戶也有幫助。

重要的是要注意拖放（顯然）不可訪問，因此屏幕閱讀器用戶需要能夠訪問列標題中的導航。 例如，在這種情況下，您可以將select下拉菜單或一組單選按鈕作為後備。

但是，如果在詳細比較之後，客戶對比較視圖中呈現的所有選項都不滿意怎麼辦？ 除了能夠從列表中刪除項目之外，能夠將相關項目添加到比較視圖中也很重要——“相關”在這裡很重要。 在大多數情況下，“添加”按鈕只會將客戶返回到類別頁面，在那裡他們會被要求添加更多項目以進行比較。 相反，我們可以建議可能符合要求的產品，也許通過顯示與所選項目相似的產品。

在 Car Showroom 上，客戶可以通過鍵入模型參考並使用自動建議來添加新項目。 另請注意，該界面在比較中提供導航——方便快速跳轉到相關功能。

第二意見很重要，可共享的 URL 也很重要

因為特徵比較主要與需要時間的購買相關，所以購買越重要，客戶就越有可能在很長一段時間內探索購買商品的想法。 我們通過觀察購物者註意到的一件事是，他們會時不時地在有疑問的時候截取比較表的屏幕截圖（或一系列屏幕截圖），並將其存儲“以供將來參考”，直到他們已經做出決定。 好吧，這不是全部事實，因為存儲該屏幕截圖的主要原因之一是將其發送給對技術細節有更好理解的朋友和同事，並徵求他們的第二意見。

事實上，對許多人來說，第二意見很重要——即使是來自對產品所屬類別不太了解的密友。 那個珍貴的截圖最終會在 Facebook 聊天和 Skype 聊天、電子郵件附件和 WhatsApp 群組中徘徊。 如果您的數據告訴您，您的許多客戶在購買商品之前需要第二意見（電子產品或電器肯定會出現這種情況），則可以“保存比較以供以後或分享”，並通過友好和鼓勵複製。 這意味著每個比較都應該有一個唯一的 URL，包含所有或選定的屬性、展開和折疊的屬性組以及產品的順序。

不要失去那個選擇

眾所周知，許多客戶濫用他們的購物車或願望清單來保持他們下次訪問網站時選擇的產品完好無損（通常是在之後不久）。 同樣，將比較表持久存儲（可能在 localStorage 或 Service Worker 中）一段時間是一個好主意。 事實上，如果比較產品在意外關閉標籤後消失，沒有客戶會感到高興。

最終，一旦用戶在幾天（或幾週）後訪問該頁面，您可以打開一個小消息欄，說明他們最近查看的項目和比較的項目仍然可用，並可以選擇“關閉”它。 如果用戶選擇探索該比較，他們可以從消息欄中進行。 如果他們瀏覽一個類別並選擇其他產品進行比較，顯然比較視圖應該被新選擇的產品覆蓋。

那些微小的交互細節

與功能比較表的交互可能看起來很不言自明，但在用戶看到比較之前必須做出許多微小的決定。

在哪裡可以進行比較？

一方面，顯然必須以某種方式指示、推廣或展示比較功能——但具體在哪裡？ 有很多選擇。 它可以出現在主頁、類別列表或產品頁面上。 它也可以在購物車頁面或搜索結果頁面上找到。 在大多數電子商務網站上，比較選項僅在類別頁面上可見，這通常是為了不分散客戶對購買渠道的注意力。 但是，它總是最好的解決方案嗎？

好吧，我們應該首先問自己，客戶什麼時候想首先比較商品？ 一個常見的用例是當他們正在查看類似的選項但無法決定選擇哪一個時。 這通常不是主頁（太早）或購物車頁面（太晚）的情況，但絕對是類別頁面和（通常）產品頁面上的情況。

最重要的是，在觀察客戶瀏覽類別頁面時，可以發現一種有趣的行為模式。 在探索購買選項時，大量用戶會在單獨的選項卡中打開每個潛在的候選產品，並首先對每個候選產品進行徹底檢查，只有當候選產品明顯不夠好時才關閉選項卡。 現在，這些客戶可能會找到一個強有力的候選人並直接結賬，或者（更常見的是）他們可能傾向於幾個選項。

在後一種情況下，能夠在產品頁面上添加用於比較的項目顯然可以節省產品頁面和類別頁面之間那些煩人的往返。 但是，我們不僅會節省點擊或點擊——更重要的是，我們會避免死鎖，即客戶猶豫不決且無法繼續結賬、完全放棄購買的情況。 如果客戶對選項猶豫不決，他們肯定不會結賬； 如果他們這樣做，您可以預期高額退款成本的風險。 在某種程度上，功能比較是一種簡單、有用的方法，可以幫助客戶做出正確的決定，從而讓他們留在網站上。

另一個常見用例是，當客戶訪問網站時已經考慮了強大的選項，但正在尋找每個選項的更詳細細節。 在這種情況下，客戶可能會直接在搜索字段中搜索這些產品，通常會輸入他們在實體零售店中記下的晦澀型號。 如果使用搜索無法找到該設備，一些客戶仍會嘗試在類別頁面上找到它，但如果他們的第一次嘗試沒有帶來預期的結果，他們將完全放棄該網站。 與前面的案例類似，在這裡我們可以通過建議潛在客戶可能想要的產品來引導潛在客戶，並使他們更容易做出決定。 也許我們甚至可以提供比實體店更具競爭力的價格和送貨方式。 同樣，在搜索結果中添加比較選擇也可能是一個不錯的選擇。

不過，還有另一種選擇。 我們還可以突出顯示特徵比較作為全局導航的一部分。 如果您的產品範圍非常有限，每個產品都針對特定的受眾，那麼清楚地傳達每種產品的設計目標群體可能會很有用。

例如，柯尼卡美能達在主導航中提供了單獨的功能比較鏈接。 不幸的是，它只是並排視圖中所有產品的所有規格列表。 也許解釋每種產品的優勢以及最適合誰會更有幫助。 儘管如此，客戶仍可以導出和打印結果，以便於掃描和閱讀。

Vizio 在主導航中突出地集成了功能比較。 可以選擇所有產品進行比較，但每個導航部分還包含一個“比較尺寸/型號”鏈接，其中包含整個產品系列，所有產品都分為幾組，並帶有用於選擇相關產品的過濾器。 屬性也按組分解，並在表格視圖中顯示為手風琴，而產品始終在浮動欄中保持可見。

令人驚訝的是，亞馬遜沒有在類別頁面上顯示功能比較作為選項。 事實上，在產品頁面上也很難注意到。 但是，亞馬遜不允許客戶選擇他們想要比較的產品，而是只允許他們“與類似產品進行比較”。 默認情況下，只有六個屬性會顯示在移動設備上：產品標題及其縮略圖、客戶評分、價格、運輸信息和零售商。 在輕擊或點擊時，這些屬性會逐漸公開。

不要誤會我的意思：當然，該網站的主要目標不是將盡可能多的人帶到比較視圖中，而是將他們帶到結賬處——提供真正滿足他們需求的商品。 因為比較可以幫助避免死鎖，請嘗試為產品頁面、類別頁面和搜索結果啟用“添加到比較”，然後監控轉換。 如果您的庫存中只有少數產品，那麼清楚地標記和定位每組客戶可能是一個更好（和更簡單）的選擇。

孤獨複選框的生活，或如何表示比較

一旦我們知道功能比較將出現在哪些頁面上，我們應該問自己用戶將如何實際添加項目進行比較。 這要求我們非常仔細地研究如何指示特徵以及用戶如何與之交互的微觀細節。

一些設計師選擇使用帶有標籤的鏈接或按鈕（例如，“添加到比較”），而其他設計師則使用圖標（加號或自定義“比較”圖標）來表示比較。 不過，一個更常見的選項似乎是一個不錯的帶有 label 的複選框。 複選框自然地傳達了這一點以及如何選擇和取消選擇項目，並且使用適當的標籤，它可以明確地傳達功能。

現在，您可能會問，您會將復選框放在哪裡？ 坦率地說，如果你環顧電子商務網站，你會發現它幾乎無處不在——有時位於標題上方，有時位於縮略圖下方，有時位於評論旁邊的右下角，而且通常位於價格上方，很難錯過的地方。 誠然，我們無法發現任何顯著差異。 但是，有一點值得注意：與純文本鏈接相比，帶有復選框的選項似乎始終使功能比較更加明顯和易於查找。

一旦用戶選擇了一個項目進行比較，確認選擇就很重要——一個複選框就可以很好地做到這一點，但我們也可以更改措辭（例如，從“添加到比較”到“從比較中刪除”）或更改背景顏色（略微突出顯示）或淡入標籤或標誌（“Shortlisted”）或彈出框。 我們還必須指出屏幕閱讀器的狀態變化。

每個選擇都應該很容易一鍵取消選擇，而無需重置整個選擇。 不幸的是，後者並不少見，因為一些網站選擇禁用複選框以防止雙重選擇，實際上使得無法在不提示比較視圖的情況下將產品從比較中刪除。

顯然，我們還需要在某處放置一個“比較”按鈕，以便客戶可以輕鬆地轉到比較視圖。 現在，如果沒有或只有一個項目入圍進行比較，那麼這種觀點就沒有意義。 因此，與其在沒有足夠的項目進行比較時顯示禁用的、灰顯的“比較”按鈕，我們可以僅在列表中至少有兩個項目時才顯示它——也許內聯在那些“添加到比較”旁邊” 客戶選擇的所有候選人的複選框或鏈接。

例如，索尼首先對一個類別中的所有產品使用文本標籤“選擇比較”，如果選擇了一個項目，它將將該項目上的複選框標籤更改為“選擇兩個或更多進行比較”。 當再添加一項進行比較時，標籤將更改為“已選擇”，並且“立即比較”鏈接顯示在所有選定產品的內聯中。

事實上，在實踐中，那個“花哨”的比較按鈕不太可能很花哨，否則它會與主要按鈕爭奪注意力，例如“添加到購物車”。 因此，通常情況下，它是一個微妙的第三按鈕，不會引起注意但很明顯，靠近比較複選框。 儘管如此，一旦添加了新項目以進行比較，我們仍然可以通過微妙的過渡或動畫輕輕突出它一秒鐘。

等一下！ 您可能會想：好吧，如果功能比較如此重要，為什麼不在燈箱中顯示確認信息，提示客戶選擇直接進行比較或繼續瀏覽網站？ 好吧，這個選項的問題在於它會大量中斷流程。 它不是將注意力集中在產品上，而是將客戶的注意力引導到確認消息上，每個新添加的項目都必須響應該確認消息。

當然，我們不知道客戶是否會添加兩個或四個或更多項目進行比較，但必須擺脫燈箱以繼續瀏覽產品似乎過分且完全沒有必要。 使用內嵌的“比較”按鈕，我們可以充分利用這兩種選擇：如果用戶想要繼續瀏覽，他們會無縫地進行。 如果他們想比較，他們也可以很容易地比較。 重點始終放在最重要的事情上：產品。

然而，這並不是我們能做的最好的。 我們在可用性會議中一直注意到的一個問題是，當客戶探索他們的選項並添加項目進行比較時，最終他們準備好提示比較視圖，但經常找不到提示它的按鈕。 事實上，他們最終不得不重新查找他們選擇的產品，因為那是“現在比較”按鈕所在的位置。 這在具有一長串分散產品的分頁類別中尤其困難。

我們可以通過在頁面底部顯示一個半透明的比較覆蓋來解決這個問題。 當客戶添加第一個項目進行比較時，覆蓋可能會出現，而當選擇被清除時可能會消失。 通過將屏幕的一部分用於比較，我們重新獲得了足夠的空間來巧妙地確認用戶的操作並告知他們接下來的步驟，而不會中斷流程。

Home Depot 在底部使用 60 像素高的比較疊加層來突出顯示所選產品的縮略圖。 我們用來引導用戶進行選擇的疊加層——例如，通過解釋需要多少項目進行比較。 客戶不必在類別頁面上搜索所選項目，但他們可以直接從疊加層中取消選擇選項。 這也是無處不在的“比較”按鈕所在的位置。

伊萊克斯在 75 像素高的底部欄中顯示有關選定項目的通知。 這可能有點太微妙而無法快速理解。 它沒有更改“顯示差異”或“顯示所有屬性”的文本，而是使用用戶可以打開和關閉的偽複選框。

Appliances Connection 在底部使用了一個稍微不那麼微妙的 40 像素高條，帶有一個清晰的鏈接，指示比較和訪問最近查看的項目。 比較視圖從上到下滑動，用戶也可以切換到最近查看的項目。

顯示和隱藏相似特徵的設計略微偏離，隱藏在右上角。 此外，客戶可以添加“庫存 ID 或 SKU”進行比較——但沒有多少客戶知道這意味著什麼。

Abcam 實現底部欄的方式略有不同，它是一個帶有垂直列表中排列的項目的手風琴。 不幸的是，一旦用戶處於比較模式，就不可能刪除項目或清除選擇。

Delta 僅在懸停時顯示“添加到比較”以及其他重要細節，例如價格。 與前面的示例不同，“添加到比較”會在屏幕頂部提示疊加，客戶可以在其中添加更多項目進行比較。

事實上，覆蓋似乎是一個很常見的解決方案，事實上，它可以在很多方面有所幫助。 例如，如果只有一件商品入圍，我們可以使用該空間來推薦類似的可比商品，甚至是其他客戶經常查看的商品（“建議類似或更好的選擇”）。

我們還可以對相似的項目進行分組，並用入圍的產品來補充比較列表。 有什麼不同？ 與其提示客戶選擇一種產品，然後選擇該類型的特定項目並進行比較，我們可以讓客戶添加不同類型的產品，在後台對它們進行分組，並讓它們在以後的任何時候都可以訪問——不一定僅用於比較。 將其視為一種擴展的收藏夾列表或願望清單，每個選擇都有一個標籤，甚至可能是一個可共享的 URL。

數碼攝影評論就是這樣做的。 用戶可以為候選清單“標記”任何項目，然後稍後比較特定類別中的項目。 這是彈性、寬容設計的一個很好的例子：即使客戶選擇電池和筆記本電腦進行比較，它們也永遠不會出現在並排比較中，因為它們會被單獨分組。 每個項目都可以單獨刪除，或者客戶也可以刪除整個組。

雖然實現起來稍微複雜一些，但這幾乎是一個絕對的解決方案，似乎運作良好。 或者，在頁面底部停靠一個“比較”欄肯定也是一個可靠的解決方案。

可以添加多少項目進行比較？

雖然有些界面非常嚴格，一次只允許比較 2 個項目，但更常見的是允許最多 4-5 個項目進行比較——通常是因為比較視圖中的空間限制。 誠然，列表中超過 5 個項目的比較變得非常複雜，列被隱藏並且“顯示差異”變得不那麼有用。 但是，如果客戶最終選擇比較更多商品怎麼辦？

好吧，除了一個特定的例外，沒有多少客戶可能會這樣做。 一些客戶傾向於誤用購物車和功能比較作為心願單，“保存物品以備後用”作為參考。 如果他們選擇保存大量項目，我們當然可以讓他們使用步進器瀏覽產品，但也許默認情況下我們可以重塑表格並提取亮點、優點和缺點。 這可能比完全不允許添加一個項目來比較煩人。

並排比較的轉瞬即逝

最終，在點擊這些複選框或鏈接後，客戶有望選擇並排查看入圍選項的比較。 這種比較通常是一個短命的物種：只要它服務於它的目的，它就會被使用，可能會與朋友和同事分享，但不久之後就會消失在遺忘中。 現在，比較可能以不同的方式出現：

1. 在同一頁面上，作為整頁覆蓋；
2. 在一個單獨的新頁面上，集成在網站的佈局中；
3. 在單獨的新頁面上，獨立；
4. 在用戶當前所在的選項卡之外打開的單獨選項卡或窗口中。

什麼是最好的？ 在大多數情況下，第二個選項可能難以有意義地實現，只是因為特徵比較需要大量空間來實現屬性的快速比較。 第一個和第三個選項通常更容易實現，但第一個可能會顯得稍微快一些，因為不涉及頁面之間的導航。 但是，它還需要根據比較狀態正確實施 URL 更改。 使用獨立頁面，這個問題會更容易解決。 作為替代方案，您可以建議“保存比較”並生成可以共享的鏈接。

第四個選項取決於您在無休止的討論中是否應該默認在新選項卡中打開鏈接。 這可能是一個偏好問題，但通常我們必須有一個很好的理由來打開現有窗口之外的窗口。 雖然它可能對 PDF 文件或任何可能導致輸入數據丟失的頁面有意義，但對於比較視圖來說可能不夠重要。

理想情況下，您可以同時提供這兩個選項——鏈接可以直接指向同一選項卡中的比較視圖，並且可以使用類似於維基百科的外部鏈接圖標來指示要在單獨的選項卡中打開的視圖。

略有不同的功能比較，或以正確的方式提出正確的問題

最後，我們只是想幫助用戶快速找到相關的可比屬性。 有什麼比首先要求用戶選擇對他們最重要的屬性更好的方法來找到它們？

比賽得分比較

例如，我們可以通過查看出現在所選產品評論中的質量來自動提取其中一些屬性，並在並排比較上方的小面板中提出建議——就像用戶可以確認或確認的標籤一樣添加。

一旦定義了相關屬性，我們就可以計算所有選定產品的匹配分數（基於評論和規格），如果它們的平均值遠低於預期，建議使用具有更高分數的替代產品。

得分最高的選項可以被建議為“推薦購買”或獲勝者，最終購買該產品的客戶的百分比，甚至可能來自外部專業評論的分數。 在那裡，我們可以更顯眼地顯示購買商品或在附近商店取貨的選項。 總而言之，我們甚至可以用一個可愛的“戰鬥”加載指示器來補充比較，以傳達我們正在“努力”尋找最佳選擇。

十大評論設法在並排比較中顯示 10 種產品。 每個產品都有一個按特定功能組細分的評級，但也有一個總分。 獲勝者以“金獎”突出顯示，在窄屏幕上，它的列是固定的，而其他產品則與之進行比較。 這是一個稍微固執己見的設計，但也許從用戶的角度檢測獲勝的候選人也稍微容易一些。

矩陣比較視圖

在進行比較時，我們自然會想到特徵比較表，但過濾視圖或可視視圖可能是比較的更好選擇——尤其是對於復雜的比較。 例如，產品圖表使用產品的矩陣表示，價格與顯示器的屏幕尺寸相對應。 特徵和屬性可以作為左側的過濾器進行調整，候選越少，縮略圖越大。 這不是每個網站都可以選擇的，但是在表格佈局範圍之外看到比較很有趣。

功能比較可以，但對客戶來說不一定是一項複雜的任務。 我們可以通過根據客戶的喜好提出更好的選擇來處理一些繁重的工作。 不幸的是，我還沒有在真正的電子商務界面中找到這個概念的任何例子。

無縫集成比較

但是，如果我們完全放棄進行專門的功能比較的想法，而改用更集成的方法呢？ Customer's experiences reflected in reviews are often more valuable than product specs, so what if we let customers explore suggestions based on keywords extracted from reviews?

In his article on UX Breakdown of Customer Reviews, Raviteja Govindaraju suggested a couple of options of how it could look.

A product page could display extracted review keywords upon tap or click. On a category page, a product comparison would extend “common” filters with sorting by these keywords. Finally, instead of a feature comparison table, the customer could select the features they care about most and the overview would provide a list of “best” options for them.

In the same way, if a customer is looking for a set of products rather than just one standalone product, we could provide “recommended” options in a contextual preview. Based on measurements of an apartment, for example, we could suggest electronics and furniture that might work well. The feature might be particularly useful for the fashion industry as well.

These solutions basically provide a slightly extended filtering option, but it shows how a feature comparison can go beyond a “traditional” side-by-side comparison. The better and smarter the filtering options, the less critical a side-by-side feature comparison could be.

Accessible Markup

While many of us would consider the table element to mark up a comparison table, in accessibility terms, sometimes that might not be the best idea. The comparison could be just an unordered list ( li ) with headings — for instance, an h2 for the title of each product and h3 subheadings for the features of each product. Screen readers provide shortcuts for navigating between list items and headings, making it easier to jump back and forth to compare.

That way, we could basically create cards, collapsed or not by default, and then progressively enhance the list towards a tabular view for easier visual scanning. Highlghting differences would then mean just rearranging cards based on customer's preferences. Still, with labels and headings, a table might be a good option as well.

As Leonie Watson, an accessibility engineer and W3C Web Platform WG co-chair, put it, “casting your eyes between two data sources is relatively easy to do, but a screen reader doesn't have any really good way to emulate that behavior”. According to Leonie, “if there is a single comparison table (where the data to be compared is in different columns/rows), then the most important thing is that the table has proper markup. Without properly marked up row/column headers, it is hard to understand the context for the data in an individual table cell.

Screen readers have keys for moving up/down through columns, and left/right through rows. When a screen reader moves focus left/right into a table cell, the column header is automatically announced before the content of the cell. Similarly, when screen reader focus moves up/down into a cell, the row header is announced before the cell content.

If the data sources for comparison are in different places/tables, then things get a bit harder. You have to remember the data from one source long enough to be able to navigate to the data source for comparison, and frankly that's a cognitive burden most people will struggle with.

A more general purpose solution is to offer customers choices of how the data is presented — for example, to choose to view all data in a single table, or to select certain objects for comparison.”

Feature Comparison Design Checklist

呸！ That was quite a journey. Below you'll find all of the design considerations one has to keep in mind when designing a feature comparison table. You thought it was easy? 再想一想。

Now, below is a list of features that a good comparison is likely to have. We covered most of them in the beginning of this article, but they are worth having in one place after all:

• Every column contains the price (or price graph), a link to the standalone product page, ratings, the number of reviews, a thumbnail, the product's model name, and a price-matching tooltip.
• For every product, useful reviews, with major advantages and disadvantages as keywords, are extracted and highlighted above the comparison.
• Attributes are consistent and have comparable meta data; they are grouped, and some of them are collapsed by default.
• If there isn't enough meaningful meta data to compare against, explain that to the customer and suggest third-party reviews instead. Irrelevant tables are frustrating.
• The customer can switch to seeing only differences, only similarities or all attributes.
• The customer can reset their selection and return back to the products (perhaps with breadcrumb navigation at the top).
• The customer can add new products to the comparison (for example, if they are unsatisfied with the results of a comparison).
• Columns and rows are highlighted upon hover or tap.
• The customer can rearrange columns by dragging or moving them left and right.
• Every action provides confirmation or feedback.
• Customers can generate a shareable link for comparison (for example, "Save comparison as…").
• If the user spends too much time in the comparison view, a window with information for hotline support or chat is displayed.
• Items are stored persistently after page refresh or abandonment.
• The feature comparison is responsive, bringing focus to the differences and the advantages and disadvantages of products.

Questions and Considerations

And here are the questions the team will have to consider when designing and implementing a comparison table.

• 你如何表明這種比較是可能的？
• 添加第一項進行比較時會發生什麼？
• 當只選擇一項時，您是否禁用了比較選項？
• 選擇項目後，您是否更改鏈接或突出顯示所選產品，或顯示比較欄，或顯示燈箱？
• 用戶如何取消選擇選定的選項？
• 如果只添加了一項進行比較，我們應該建議產品進行比較還是讓用戶“找到相似的產品”？
• 選擇項目後，您是否提供視覺反饋以重申和讓用戶放心他們的選擇。 （例如，“不錯的選擇！這是該類別中排名前 10 的相機之一！”）
• 客戶可以添加多少項目進行比較（通常是三到五個）？ 如果沒有選擇或選擇一項，比較會發生什麼情況。 超過五個項目怎麼辦？
• 在比較項目時，我們是否使用動畫或過渡來指示比較（例如戰鬥動畫）？
• 我們是否顯示價格（或價格發展）、單個產品頁面的鏈接、評級、評論、縮略圖、產品型號名稱和價格匹配工具提示？
• 用戶可以切換到僅查看差異、僅相似性或所有屬性嗎？
• 我們是否默認分組和折疊屬性？
• 我們是否跟踪屬性是否一致並具有可比較的元數據？ 否則，看到差異將毫無意義。
• 我們是否在懸停或點擊時突出顯示列和行？
• 用戶可以左右移動列嗎？
• 如果用戶將不相關類別中的項目（例如，筆記本電腦與電池）進行比較怎麼辦？
• 我們如何允許用戶添加更多項目進行比較？
• 我們如何允許用戶從比較中刪除項目？
• 我們應該動態跟踪比較列表中有多少項目，如果沒有（“哦，沒有可比較的！這裡有一些建議。”）或一個（“Boo-yah！你有一個贏家）提示消息！”）還是兩個（“所以，你現在只有兩個候選人。”）？
• 我們應該要求客戶選擇他們最關心的東西嗎？
• 我們是否會根據用戶最相關的屬性在選擇進行比較的產品中推荐一個“贏家”？
• 每個動作是否都有視覺和/或聽覺反饋來指示變化？
• 我們是否提供了用於比較的可共享鏈接（例如，“將比較另存為...”）？
• 如果用戶在比較視圖中花費了太多時間，我們是否應該提示一個帶有熱線支持或聊天信息的窗口？
• 頁面刷新或放棄後，比較的項目是否會持久存儲？
• 我們是否包含電子郵件訂閱的“通知降價”選項？
• 特徵比較是否可訪問，編碼為無序列表？
• 我們如何使特徵比較具有響應性？

更多資源

• “比較表”，尼爾森諾曼集團，
• Vimeo 上的高清功能比較實現。

敬請關注！

這篇文章是關於設計模式的新系列的一部分，在你真正的 Smashing Magazine 上。 我們將每兩到三週在本系列中發布一篇文章。 不要錯過下一個，關於構建器和配置器。 啊，對涵蓋所有模式（包括上述模式）的（印刷）書感興趣？ 在評論中也讓我們知道——也許我們可以考慮將所有這些模式組合成一本書並在 Smashing Magazine 上發布。 繼續搖滾！

非常感謝 Heydon Pickering、Leonie Watson、Simon Minter、Penny Kirby、Marta Moskwa、Sumit Paul 在本文發表前為本文提供反饋。