8個常見的交互細節問題

平時的工作中，經常會遇到一些不舒服但是又說不上理由的交互問題。本文作者從爭論的點出發，有理有據的說明這些問題，並給出了修改建議，當然作者也說了他的觀點並非就一定正確，只是希望能夠提供一些思路，但我相信大家應該還是能夠從作者的觀察中學到不少乾貨的。

背景介紹

在我為合作企業Mendix擔任用戶體驗顧問的那段時間中，我經常能遇到他們團隊內部創造出的一些優秀應用，我的工作也會涉及到幫助提升那些產品的用戶體驗。

最美好的時刻是當自己突然來了靈感做出一些創造性設計時，也能清晰的看到一些很常見的交互邏輯問題。

我所給出的解決方案也並非真理，要根據實際情況來辦，不要照搬我寫的東西，只是把我寫的內容當做是靈感就好了。

問題一：所有內容全部平鋪在一個頁面上

這些最常見的用戶體驗錯誤

剛開始工作的時候，你可能會遇到做一個功能眾多的小應用，當你想再添加一些特色功能之前，會發現已經被你弄的滿屏幕都是按鈕了。

別怕，我們都是這麼過來的。

（1）爭論的點

1. 更少的點擊；
2. 我可以在功能概覽上看到一切我想要的功能；
3. 用戶不喜歡滾動。

當我看到這個解決方案時，它讓我想起了瑞士軍刀的段子，所有的工具都打開了，但唯一使用的卻是開瓶器。

（2）認知負擔

讓所有選項全部展開似乎可以創建功能概覽，但問題是：人的大腦最多只能理解9個選項，而且老實說，95%的按鈕用戶並不經常使用。

（3）親近原則

另一個問題是按鈕應該與它們影響的數據放在一起，把所有按鈕都擺在一起便意味著失去了視覺上的關聯。

（4）用戶並不討厭滾動

「用戶討厭滾動」通常是在正確的時間沒有正確的上下文，然後通過在一個屏幕上使用儘可能多的信息，來幫助創建上下文來解決滾動問題的副作用。

「但是在我們的研究中，會發現只有10%的用戶會滾動到頁面底部」這似乎在說明90%的用戶不喜歡滾動。

其實問題的關鍵不在於滾動，而在於信息量。在頁面上提供更多的信息並不意味著用戶能消化，但是會更快的消耗掉用戶的精力而讓他們關掉頁面。

依據：

• 米勒定律（https://lawsofux.com/millers-law）
• 親近原則（https://lawsofux.com/law-of-proximity）

問題二：下拉菜單分類不清晰

所以你已經清理了界面，並把所有的按鈕都放到了下拉菜單中。

（1）爭論的點

1. 更多的焦點；
2. 減少混亂，更容易找到我想要的東西。

（2）平衡才是關鍵

把你做的界面想像成現實世界，如果你的一個頁面是藏在一堆抽屜中，則需要打開每個抽屜，直到找到所需的內容。這在數字界面中道理也一樣。

如果你的抽屜是合乎邏輯的，並且在正確的地方，這樣做就很好。在花園裡放一些園藝用品聽起來是很不錯的想法，但是你的燒烤用具是否也應該放進去呢?還是放在廚房裡？還是兩個都放？

好的平衡是需要反覆改進的，你多久用一次燒烤用具決定它是否應該放到棚屋還是廚房。

如果只有5個按鈕，可能下拉菜單都不需要，但是如果到了6個以上，這就需要仔細去分析了。

譯者註：這裡的問題，我理解是把按鈕放在一個大分類或是放在多個小分類，並沒有絕對的對錯，關鍵在於要平衡好。如果分類足夠清晰，則分類可能會更好，但如果分類比較模糊，則全放在一個選項中，也許也不錯。

問題三：當前位置不清晰

因為一致的設計系統和品牌風格，所有的頁面看起來都類似。很快，你就會感覺自己好像正漫步在一片森林中，不知道你以前是否看過這個頁面，或者這是否是一個具有類似狀態的不同頁面。

爭論的點：

1. 一致的視覺風格；
2. 設計系統驅動的設計；
3. 高效的頁面使用率。

試想一下這個場景，這是一個星期五的下午，你在一些社交媒體，同事和私人信息之間來回查看，並同時在做工作。你腦子裡的最後一件事是你剛才點擊的連結和你所在流程中的位置。

在每個頁面中考慮給用戶創建：

• 為頁面提供清晰的標題或頁面名稱；
• 如果你的頁面層級深度超過1級，則需要考慮採用麵包屑導航；
• 如果流程有多個步驟，則需要顯示這些步驟。

問題四：太長的內容寬度和太小的文字

希望充分利用頁面的另一個例子。

爭論的點：

1. 用戶討厭滾動；
2. 高效的頁面使用率。

網頁上的經驗告訴我們每行不要超過9個單詞。（譯者註：我並不贊同作者這個觀點，9個單詞太短了，作者說的可能是在很老的小屏幕上才會有如此規定，現在應該不會有每行這麼少的字數要求，我倒是覺得這裡的重點是每行文字不要過長就行）。

當你讀完一行時，你的眼睛需要找到下一行的開始，如果這行太長了，你的眼睛就很難做到這一點。

「但是看看每個頁面我們浪費了多少空間？」

比如：你現在正在閱讀這篇文章，你有注意到那些沒有利用上的空間嗎？

你猜怎麼著，所謂的浪費實際上也是一種投資，如果有很長的一行文本對你來說也沒問題，那說明這些文本對你來說是非常重要的（譯者註：我的理解是你會認真的去看這些文字而忽略掉文字的長短），如果不是這樣，還是儘可能的短一些。

1910的電子郵件的排版方法：（http://blog.weare1910.com/post/78113100010/a-typographic-approach-to-email）（譯者註：1910不是年份，是一個網站的名字）

問題五：在彈窗上再彈窗

為了節省空間，設計了一個帶有彈窗的按鈕，點擊按鈕會繼續彈出另一個窗口。

爭論的點：上下文更加連貫。

問題是，這樣會打破用戶在這個過程中的心理模型。如果他完成了第二個彈窗上的操作，他會回到原來的彈窗還是回到原來的界面？

解決辦法是：第一個彈窗做成一個完整的界面，或者把第二個彈窗做在第一個消息彈窗的裡面。

問題六：卡片嵌套卡片

卡片設計現在很流行，所以怎麼樣才能比單張卡片更有效率呢？

卡片嵌套卡片，頭腦風暴的時候就很容易想到。

爭論的點：嵌套的卡片可以創建好的視覺層級

用戶體驗設計師經常會探討視覺層級結構，元素在界面中的組織方式，被認為是對用戶來說最重要的。在這一過程中，我們引入了現實世界中的類似卡片一樣的模型元素。

在傳統的卡片組中，卡片的大小都是相等的。卡片被放置在其他卡片上或旁邊，以傳達某些狀態或關係。當你在另一張卡片內嵌上一張卡片時，用戶的心理模型就會開始崩潰。用戶會下意識地開始疑惑這與其他對象的關係，這個時候邏輯就開始變得混亂了。

解決的辦法其實也很簡單！不要把它們放在一起，而是把它們放在彼此附近，或者放置在一個版面區域內（好比在一張賭桌上打牌）。

問題七：一個頁面有太多的表單元素

我應該有一長串表單輸入嗎？也許可以分成多個步驟？或者有3列的表單輸入，所以它們都適合放在同一個界面上?

（1）爭論的點：用戶不喜歡滾動。

主要問題在於頁面數量或者表單數量，一次只能在界面中顯示多少表單。像按鈕一樣，應該儘可能減少到最小程度，這仍然需要考慮上下文和易用性。

（2）使用單列

最好的做法是把輸入表單維持在一列，這樣用戶的眼睛就能夠很自然地看下來，並且也能很方便的檢查每個輸入內容。

（3）邏輯流暢

有時，你的輸入欄位是用戶即將開始的旅程，或者對他們會造成嚴重的後果(比如：稅務單)。這是將欄位分割為多個頁面的最佳時機。

這給了你一些視覺空間來創造一些喘息的機會，並向用戶解釋他們在做什麼，以及為什麼它很重要。

（4）下拉菜單

如果真有1-5個選項，就不要將它們放在下拉菜單中。我知道那樣看起來可能會更加優雅，但是對用戶來說卻並不方便，採用單選按鈕會是一個很友好的方式。

UX Collective——設計更好的表格（https://uxdesign.cc/design-better-forms-96fadca0f49c?epik=0KSYeE_IWH4Bw）

Stackoverflow——單頁還是多頁？（https://ux.stackexchange.com/questions/36956/single-page-or-multi-page-forms）

問題八：按鈕規範不明確

頁面上的某些元素可以幫助你確定正在瀏覽的頁面，其他元素應該儘可能清晰一致。

爭論的點：但是蘋果/谷歌是這樣做的。

最常見的例子是：「接受」和「取消」按鈕，是放在左邊還是右邊。按經驗來說，當你在流程中前進時，繼續的那個按鈕應該是綠色的，放在右邊，並且按鈕上有一個文本，解釋它的功能，比如：「同意」，「繼續」或「購買」。

譯者註：這裡關於按鈕擺放的位置，有2點需要去注意的：

1. 流程前進的順序與閱讀習慣有關係，文中說的是從左往右閱讀的方式。但有些地區的閱讀順序是從右往左讀，比如：阿拉伯國家，那麼此時前進的方向應該在左邊；
2. 保持每個界面中的相同含義的按鈕順序一致性。

UX Collective——為按鈕選擇合適的文案（https://uxdesign.cc/the-microcopyist-cancellation-confirmation-conflagration-8a6047a4cf9）

快速回顧

• 不要超過9個按鈕；
• 把下拉菜單作為最後手段；
• 給每個頁面加一個標題；
• 當頁面層級超過1時，給它加一個麵包屑導航；
• 在多步驟操作中，顯示具體步驟；
• 每行不超過9個文字（譯者註：這條我不是很同意，見上文解釋）；
• 切勿在彈窗中再使用彈窗；
• 切勿卡片嵌套卡片；
• 儘可能使用一列表單；
• 注意按鈕的描述文字。

 

原文連結：https://blog.prototypr.io/common-ux-mistakes-made-by-business-developers-e837d0b31379

原文作者：Jason Teunissen

譯者：彩雲Sky，公眾號：彩雲譯設計

本文由 @彩雲Sky 翻譯發布於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議