iOS當中4種UI元素的可用性問題及最佳化建議

連續一個多星期，日子就突然變成這種，每天白茫茫一片刺眼的陽光，空氣又溼又熱難以呼吸，炎熱摧枯拉朽無法抵抗的，樣子了。怎樣都想去到一個更適宜人類生存的地方，也許是我出生的城市，也許是我向往著將來可以終老的城市或鄉鎮，無論哪裡，有朝一日離開這片魔境，便可以。

我說我愛LA，愛美國的一些城市，妹妹對我說，論精彩，這些地方可能還比不過上海；國內其他一二三線城市約莫也就不必說了。幸運的是，我並不需要也不熱愛那些精彩。這裡的精彩不屬於我，我也不屬於這裡。我就是一混合硬碟，母親屬於這裡倒是真的，步入老年可以葉落歸根也是幸福安心的事，只是我自己以後歸去哪裡還真是個問題。這樣的問題想著想著便會睏倦。

然後這周又是一篇來自Nielsen Norman Group的文章。供參考吧，這種文章背後的思維模式甚至是精神才是最該汲取的，內容本身反而是其次；這樣的東西看的越多，實踐當中具有代表性的產品案例經歷的越多，你越會發現，設計這種事，在很多時候，無明無暗，無是無非，有的只是特定的產品、特定的資源、特定的情境、特定的使用者群體，以及所有這些因素混雜在一起之後擺在面前的需要不斷權衡、爭取或妥協的各種可能性。下面進入正文。

那些大的軟體公司，譬如Apple、微軟、Google等等，通常會為第三方app設計師們提供一系列設計指南。這樣做的目的在於：

• 一方面，設計師和開發者可以比較輕鬆的上手打造在質量方面至少符合“基礎標準”的產品，而無需重新思考和驗證全新的設計模式及UI元素。

• 另一方面，如果某一平臺當中的所有產品都遵從統一的設計規則，那麼使用者也將受益於介面外觀與互動方式的一致性。

遵守設計指南，這幾乎是一條鐵打的規矩。但是在實際當中，“官方標準”未必能很好的適用於各種情況。我們不清楚為什麼有些元素會出現在設計指南當中，也許是因為官方所做的測試不夠徹底，或者說這些元素和模式是用來解決某一類設計問題的最基礎最具適用性的解決方案。

本文當中提到的4種UI元素都是Apple慣於在自家app中使用的，其中的一些也出現在了官方的設計規範當中；自然，不計其數的設計師也會跟從這些用法。而另一方面，我們(Nielsen Norman Group)在一次又一次的可用性測試當中也真真實實的發現了這些元素所導致的可用性問題。

說不定Apple的諸神會用雷劈我們，但我們仍然建議各位設計師在使用這些UI元素時多加考慮，或嘗試最佳化/替代方案，因為這些元素在可用性測試當中的表現確實存在問題：

• 頁碼指示符(小圓點)

• 導航欄裡的完成按鈕

• 加號(+)圖示

• 拖拽圖示

1.頁碼指示符(小圓點)

iOS的頁碼指示符，在形式上就是橫排的圓點，用來表示一系列可以透過橫滑瀏覽的分頁檢視。其中，代表當前檢視的圓點處於高亮狀態，其他的則是灰暗的半透明狀態。

iOS系統首屏，頁碼指示符用來表示頁面總數以及當前所在位置。我們時常見到這種透過系統首屏來演示頁碼指示符使用方式的範例，實際上，頁碼指示符能完美適用的介面環境並不多，而系統首屏正是其中之一，因為使用者明確的知道自己的手機裡裝有很多app以至於第一屏無法完整呈現，需要透過橫向滑動檢視更多。

很多app或網頁都會使用這種元素來暗示使用者可以透過橫向滑動來檢視同級的其他頁面，也有一些是將其用在介面中特定的區域來暗示其中存在更多內容。不能否認，這種形式的頁碼指示符在app和移動Web的介面設計當中都很流行，但是要知道，它同時也是使用者最容易忽略掉的介面元素之一。在我們所做的一系列可用性測試當中，使用者經常難以發現這些在尺寸上過於微小的圓點，進而錯失了那些可以透過橫滑來檢視到的內容或功能入口。所以， 我們認為圓點形式的頁碼指示符至少不能被用作關鍵功能和內容的唯一導航方式 。

雖然iOS允許你將這些圓點渲染成其他顏色，但想要使如此微小的元素一目瞭然的突顯在介面當中還是非常困難的，除非你能確保將其置於高對比度的純色背景上。很多產品會將圓點們放置在五顏六色的banner圖上，使這些本就難以被留意到元素不知不覺的融入到背景當中，進一步降低了可發現性。如果一定要這樣做，那麼必須確保圓點和背景色之間始終具有較高的對比度，最好是使用純色背景。

iOS的Zappos，在第一張底圖上，頁碼指示符已經很弱了，而在右側第二張底圖上，幾乎完全消失了。

有一部分產品則在iOS的基礎上進一步自由發揮，將圓點改為方形或其他形狀，佈局上也更加隨意。不妨設想，即便使用者已經習慣了iOS的小圓點模式，現在他們就算發現了介面中的這些小元素，還要猜想這些方塊會不會就是代表著以前的那些小圓點 - 可發現性沒有顯著提升，同時還造成了認知上的困難。如果要使用頁碼指示符，儘可能使用使用者已經熟悉的圓點模式，並將其居中的置於對應內容的下方。

Android中的Fab，借鑑了iOS模式的小圓點，但將其置於了內容的右側，相比於居中的位置，更難被發現。

即便使用者能夠注意到頁碼指示符，這裡還有一些潛在問題，譬如小圓點們可以讓使用者知道有多少同型別的資訊檢視以及當前所處位置，但無法提供任何與內容本身相關的資訊。此外，使用者對互動的控制權也非常弱，必須按照次序逐一瀏覽，無法直接跳轉。所以，如果在你的需求當中這些體驗要素比較重要，那麼小圓點恐怕不是你的最佳選擇。

鑑於小圓點頁碼指示符所存在的一些可用性問題，我們建議：

• 首先考慮你的內容是否適宜透過橫滑的方式依次瀏覽，還是可以透過更復雜同時也更靈活的其他導航方式進行架構。

• 對於橫滑瀏覽的內容，儘量採用右邊緣露出一部分內容的方式來加強對於“更多”的暗示，而不要單純依靠頁碼指示符。

2.導航欄裡的完成按鈕

iOS中很多代表“完成”操作的按鈕時常被置於導航欄當中右側的位置，包括表單介面的提交按鈕也是如此。如今這種模式也開始潛移默化的影響到一些Android平臺裡的app。

根據我們的可用性測試所得出的結論，不說跨平臺的影響力，單就iOS本身，我們也不建議將“完成”性質的按鈕放在這裡，原因很簡單，將最終操作放置在介面頂部，有悖於自上而下的資訊流向。使用者在填寫表單或編輯內容時，互動行為通常是由上至下的，當他們即將完成的時候，也會預期在結尾處看到結束處理的操作。多數情況下，當人們無法在結尾處找到這樣的功能時，便會產生迷惑並開始四處尋找。

在下面的案例當中(左側是Pinkberry，右側是Nordstorm)，使用者填寫完表單之後需要點選登入或下單按鈕。這樣的佈局就是我們所說的有悖於自上而下資訊流向的形式，使用者的全部注意力都隨著表單而逐漸下移，最終發現在結尾的地方沒有任何完成操作，剩下的就是茫然無措。要知道，即使是在手機這樣的小屏裝置上，四處尋找某種UI元素也是需要耗費很多額外的注意力成本的；將完成按鈕直接放置在內容底部是最符合直覺的做法。

當然，從另外一個方面講，將完成按鈕置於導航欄當中的模式也有其自身的優勢：因為導航欄是固定在頂部的，所以使用者在編輯內容時可以隨時點選到，而且當內容區域較長時，放置在頂部的按鈕也不會被鍵盤所遮擋。如果使用者確實無需完成全部內容的填寫便可以進行完成操作，那麼你可以考慮將完成按鈕固定在底部，並會隨著鍵盤的起落而相應的移動。這種方式的缺點是會佔用一定的縱向空間，但優點也是很明顯的：即符合直覺，又隨時保持可見，同時相比於頂部右端的位置來說，更易單手點選操作。

鑑於導航欄裡的完成按鈕所存在的一些可用性問題，我們建議： 將按鈕置於內容底部；如果內容較長，可以嘗試將按鈕位置固定，並使其不會被鍵盤遮擋，以便使用者可以隨時點選。

3.加號(+)圖示

見過的app越多，你越會發現，在不同的環境當中，加號圖示往往會代表各種不同的功能。當加號位於導航欄當中時，通常表示“新建”功能；如果被放在列表單元當中，要麼是表示將這條內容新增到某種分組當中，要麼是用來展開詳情。無論是在同一個app的不同介面，還是在不同的app之間，同一元素承載著不同的功能含義，這對於使用者的認知與記憶都是一種負擔。

加號圖示的可用性在很大程度上取決於它在介面當中所處的位置。當位於導航欄時，加號通常能夠表達準確的含義，即建立一條與主要內容相同性質的新內容。然而，當加號出現在主要內容當中時，多種含義的可能就會給使用者帶來迷惑。

舉個例子，Any.do曾經的一個版本當中，會在待辦事項分組標題右側放置加號圖示。在這個環境下，你不知道點選這個圖示是會展開其中的全部事項，還是會在這個分組中建立新事項。在最近的一個版本中，他們將加號放在了介面右上角，明確的用於建立新事項。

無論是Web還是移動app，位於介面內容當中的加號圖示通常用來表示該內容可以擴充套件檢視更多資訊，有時還會搭配箭頭圖示同時使用。透過加號來觸發其他型別的功能很可能破壞使用者所習慣的預期。例如，在LinkedIn的app當中，取決於所在位置的不同，巢狀在圓環當中的加號圖示代表著關注或是加入某小組的功能。在我們的可用性測試當中，很多使用者抱著檢視詳情的預期去點選該按鈕，卻發現自己關注了對方動態，進而感到莫名其妙。

取決於產品型別及目標使用者行為習慣的不同，你的app當中的加號圖示可能最適於表達某個特定的功能含義。無論怎樣，要儘量避免在app當中隨處使用，因為取決於所處位置的不同，使用者確實很容易將其理解為不同的含義，或是抱著一直以來習慣的認知進行操作而導致與預期不符的結果。

鑑於加號圖示所存在的一些可用性問題，我們建議：

• 導航欄是一個相對安全的位置，而在其他位置使用加號按鈕則需透過可用性測試來確保使用者能正確的理解你想表達的功能含義。

• 要徹底避免加號圖示帶來的潛在問題，不妨徹底避免使用它，取而代之的，透過箭頭來代表詳情擴充套件，透過簡單明確的文字按鈕來清晰準確的傳達其他功能含義。

4.拖拽圖示

和移動裝置上的很多其他圖示一樣，拖拽圖示也並不能很直觀的體現出背後的含義。我們發現很多使用者其實並不明白這個圖示代表著所在元素是可以被拖拽移動的，而且縱向排列的三條橫線也很容易讓人誤以為是某種選單圖示。實際上，這種形象隱喻的是可拖拽物體上的防滑條紋，好像你把手指放在上面就可以拖動整個物件而不至於打滑。通常，使用者需要長按這個圖示，使物件整體進入某種啟用狀態，然後拖拽到合適的位置。

在可用性測試當中，我們發現，使用者更傾向於點按物件本身進行拖拽，而不是去按住一個含義模稜兩可的小圖示。相比於列表單元這樣的物件，圖示在尺寸上太小了，如果要求使用者必須透過按住它來拖動整個單元，那麼互動成本的增加就是必然的(相關閱讀： )。此外，使用者也會認為一個單元整體只會觸發一種行為，也就是無論拖拽小圖示還是單元本身，都可以使其被拖動。

Yahoo! Finace使用了標準的iOS拖拽圖示，使用者長按該圖示可以使單元進入可拖動狀態。雖然列表單元本身是目標更大、更易操作、更符合直覺的物件，但使用者卻無法透過長按單元本身來達到觸發拖拽的目標。

此外，我們還是要強調一下拖拽圖示與我們所熟悉的漢堡包選單圖示真的過於相似了：

外形相同或過於相似的物件，所觸發的事件是截然不同的，這種情況會使人迷惑不安。雖然行業中關於漢堡包圖示的爭論愈發激烈，但越來越多的使用者已經開始習慣了“點選三根線的圖示展開導航選單”的模式。當他們發現行為結果和他們所習慣的、所預期的東西不一致時，就會產生挫敗與迷茫。

鑑於拖拽圖示所存在的一些可用性問題，我們建議：

• 至少允許使用者長按目標單元整體也能實現拖拽的目標，而不要只將互動區域限制在拖拽圖示上。

• 另一方面，對於漢堡包選單圖示，可以嘗試更清晰明確的表達方式，例如在三根線前面增加三個點，或是同時放出“選單”標題在圖示旁邊。

關於漢堡包選單圖示，推薦閱讀：

小結

背離“官方的”、“常見的”設計模式，總會讓人覺得不安，況且保持與大家相同的模式保持一致也能幫助使用者降低學習成本。但是，無論你決定遵從怎樣的設計規範，我們都建議你透過必要的可用性測試來驗證這些模式是否真的適用於自家產品及目標使用者。至少，在我們自己的研究過程當中，我們見到了很多使用者在本文提到的4個常見模式上遇到了足夠引發我們進行思考的可用性問題。

原文連結：