編者按：本文原載於遊戲邦，作者Jake Simpson
好友曾向我展示了最新的iPhone和iPad版《極品飛車》。遊戲的渲染效果令人印象深刻，是款蓄勢待發的優秀遊戲。但是，遊戲的前端是典型的UI設計偏差案例。但界面中有大量的屬性數據等內容，它在玩家沒有時間做決定時提供了過多的內容。這些內容能夠顯著改變他們的遊戲體驗，但卻在玩家往往感受不到變化的時候呈現。
極品飛車(from itunes.apple.com)
這促使我開始思考UI設計的黃金法則。以下是我認為創造最佳體驗應當使用的UI設計方法。坦誠地說，這些規則只是通用做法，並不完全適用於你的UI設計中的所有情況。
1、開始遊戲所需按鈕點擊不超過3次。 id可以在網絡遊戲（如《雷神之鎚3》）中實現這點，所以你也可以做到。玩家不希望遊戲不斷地向他們呈現需要他們去理解甚至會影響到遊戲的數據。玩遊戲是他們的首要想法。你不可在15分鐘的首次遊戲體驗前添加長達20分鐘的內容介紹，這會讓玩家抓狂。
2、隱藏複雜性。 “高級”標籤的作用就在於此。在將玩家引入遊戲玩法體驗時，所有當前不相關（遊戲邦注：比如任何默認且不太可能改變）的內容都需要被隱藏到其他對話框中。這種想法不是說要移除遊戲的複雜性（這也算是種恰當的做法），而是不需要立即呈現這些複雜內容。當然，你可以允許玩家改變參數，但是不必要求甚至強迫他們查看能夠改變哪些參數。那些想要做這件事情的人自然會找到可以幫助他們實現目標的選項，但是要記住的是，試圖改變參數的玩家比例不足50%。對於50%以上的玩家，你只要呈現無需他們更改的選項和功能，因為過多的選擇只會讓他們備感困惑。
3、在同一個地方向玩家呈現所有信息。保持信息呈現位置的一致性。你需要引導玩家查看某個地方而且只需查看這個地方就能夠獲得所有遊戲信息。當然，信息呈現方面有個技巧，就是對信息內容進行過濾，這樣玩家就無需去注意過多來自遊戲或其他玩家的信息，信息量過大可能會導致玩家丟失關鍵信息。但這是信息的過濾層面，留待以後作深入探討。必須注意，如果你只是高亮顯示錯誤或遺漏的輸入內容，也算未遵守這個規則。當你在網頁頁面中填寫表格時，它們經常採用的就是這種方法，這當然是允許的。但是，如果你要這麼做，不要只使用文字顏色來暗示錯誤，這會給色盲用戶帶來不便。你需要做的是反向高亮文字內容，所以不要只將不當文字顯示成紅色，還要將背景顯示為紅色。這樣，即便是色盲用戶，也能夠領會到輸入錯誤。
4、過濾信息，呈現含義。能夠呈現信息固然很好，但是你分享的信息越多就越好嗎？從某種程度上來說，情況確實如此。但是，如果信息大量湧向用戶，他們就會感到反感。 “你確定要這麼做？”等重複性信息會成為垃圾信息，會被用戶忽視或直接點擊，而垃圾信息過多會使用戶忽略重要信息。設定重複性對話框的呈現冷卻時間是種不錯的做法，比如3次呈現某個對話框後，在預設的時間內不再呈現該對話框，可以將預設時間設定為上次對話框呈現的5分鐘時間內。通過這種方法，用戶就無需不斷點擊相同的對話框，也就不會受這些信息煩擾。
允許用戶過濾某些信息類型也是個不錯的做法。比如，允許用戶忽略來自腳本系統的警告或信息。這需要對信息進行恰當分類，這樣系統才能識別其屬於哪個類別。雖然麻煩，但卻是可以採納的做法。
而且，在某個地方保存所獲得信息的列表（指未經過過濾的所有信息），同時確保用戶知道這個地方。這樣，如果他們需要這些信息，可以隨時查看。
對於信息的呈現，還有點值得一提：將他們所做出改變的含義告知用戶很重要，尤其是工具。如果用戶在虛幻編輯器中點擊“所有內容使用動態光照”按鈕，那麼需要告知他們此等做法會對幀率產生的影響。使用在屏幕上通過顯示文本來解釋每個按鍵作用的傳統方法往往是不夠的，因為內容或其他設置的不同經常導致某種控制產生的影響發生變化。如果只是2000 poly場景中的單個對象，那麼設置“所有內容使用動態光照”不會產生負面影響，只有當在10000 poly世界中渲染400個對象時，負面效果才會明顯。所以從根本上來說，我的觀點是要對控制改變可能引發的其他改變進行內部分析，將其與可能對用戶產生極大改變的其他影響方法相比較。再次強調，注意對話框和信息的呈現次數也是必要之舉，因為總是會出現某些特殊事例，使得應用認為用戶提出的是非意願行為要求，因此而不斷發出警告。
5、保持所有UI呈現內容一致性是關鍵。有些做法是顯而易見的，比如應用中可以使用單選按鈕或複選框，但是不可融合使用這兩者，在所有對話框中，保持所使用文字類型、字體和大小的一致。但是，還有些更為精緻的東西。比如，如果你需要在工具中提供路徑，保持使用瀏覽器按鈕，不要期望用戶會直接輸入路徑。 XCode便是個絕佳的反例。還有個不錯的做法，使用滾動欄而不是要求用戶輸入數值，但可以仍支持用戶使用數值輸入方法。
數據輸入最重要的部分之一是從一開始就避免用戶輸入不良或衝突性數據。應用程序中有許多代碼可以處理不良數據，但是從一開始就杜絕不良數據的輸入是個更好的方法。這正是使用預設下拉菜單的原因所在，因為你就可以確保程序不會獲得拼寫錯誤的單詞以及不良的數據。
6、如果能夠實現無需用戶輸入內容的話，就採用這種方法，這是第5點的擴展。預設下拉菜單標籤或者在需要用戶輸入的地方提供默認文本，這樣如果用戶不願意的話，就無需自己動手輸入任何文本。所有東西都應當有默認選項。
7、可以設置通過多渠道查看相同對話框，Windows XP在這一點上做得很好，允許用戶通過多種途徑打開相同的控制對話框。這樣做是可以接受的。應當注意，在使用這種方法時，應當保證對話框本身的一致性。無論你通過何種渠道打開對話框，它們都是完全相同的，包括外觀、表現和功能。
8、控制設置於相同且唯一的地方，這是第6點的擴展。同種控制只應當存在於單個對話框中，而且不可設置外觀看似相同但功能不同的控制，這會讓用戶在理解上遭遇困境。同樣，XCode在這個方面做得很不好。
9、對話框深度不可超過3層。如果你製作的是RPG遊戲的話，或許可以設置4層。對話框深度設置的底線是，不可讓用戶對他們所處的位置、正在做的事情以及原因感到困惑。你還需要在對話框樹中呈現他們所處的位置，添加後退鍵固然不錯，但是一個小的對話框樹指示器會顯得更好，可以參照Windows系統資源管理器的做法。
10、對話框切換。對話框切換時間最好在150毫秒內完成，最多只能是200毫秒。如何切換以及切換的精美程度都無關緊要，用戶想要的是短暫的響應時間，尤其當他們通過UI對話框樹導航的時候。華麗但漫長的切換就像是在跟用戶開玩笑。用戶剛開始或許會覺得設計很酷，但是一段時間後就會感到厭煩，你要做的只是讓整個過程更快就可以了。
11、任何能夠在視覺上影響其他內容的事物都應當即時變更。如果你不知道光照或服飾改變對角色以及其他內容的影響，那麼就應當即時呈現這些內容，這樣用戶就能夠看到他們改變設置後的效果。有時候，這一點可能無法實現，因為單項設置的改變會影響到其他內容（遊戲邦注：比如在腳本值的修改中，只有修改另一個後才能使之生效）。但在可以實現這種即時呈現的內容上，你最好這麼做。
12、讓所有內容均可配置和保存。允許用戶修改每個窗口的大小以及位置，並將其保存。設置默認選項是很簡單的事情，但是確保應用程序能夠保存所有用戶做出的改變。記住，對話框佈局能夠給用戶節省大量時間。
13、區別呈現信息和可變更數據。用戶無法改變的信息應當以特定的方法呈現，讓用戶明白這些是靜態信息。可變更信息應當以略微不同的字體、顏色或大小呈現，或者以某種用戶可以顯而易見感受到這些是可變更內容的方法呈現。這個方面跟第2點息息相關，如果用戶意識到某些數據是可變更的，他們就會尋找更改的方法，開始探索你的對話框UI結構。
14、對PC開發者而言，你需要查看打開對話框時內容是否真正呈現在屏幕上。許多情況下，用戶會改變他們的顯示器設置，隨後忽然發現他們已保存的對話框從屏幕上消失。你需要查看是否出現這種情況。我不止一次碰到這種問題。
15、最後這點可能也是最具爭議性的規則：你設計的目標是為了滿足數據變更流動，還是為了滿足數據聚集？簡單介紹下背景知識，針對數據變更流動的設計意味著你會將許多不相似的數據聚集在單個屏幕、對話框和UI版塊上，按照用戶需要展開的流程來排序，這樣用戶可以從中選擇他們需要前往的步驟，比如輸入名稱、選擇文字類型、選擇遊戲類型、選擇服務器和進入遊戲等。這些元素都是不同“類型”的數據。多數遊戲會將它們分離成多個屏幕，添加許多額外的按鍵和信息，供用戶用來修改體驗，但實際上多數用戶不會去使用。另一種是“相似數據”分組方法，每個屏幕都圍繞特定功能設計，用戶可以從中做出選擇。數據流動屏幕會將用戶必須選擇或改變的所有具體功能放在一個屏幕中，讓他們可以同時看到要求，做出選擇然後繼續前進。一種重在呈現選項，另一種重在簡化過程使用戶能夠快速抵達想到的地方。
對於這個問題，我的個人看法是兩種方法都是合理的。我偏向於呈現數據流動方法作為默認方式，因為多數人都會使用這種方法，尤其是首次使用應用程序的用戶。等用戶熟悉應用程序後，可以讓他們使用另一種方法，因為他們需要更快地找到自己想要的內容。這一點與第2點緊密聯繫，複雜性可以存在，但不是必要因素。
以上就是UI設計的15項黃金規則，可以幫助你傳達更友好的用戶體驗。
來源：http://leiphone.com/15gold-priciple.html
特別注意：本站所有轉載文章言論不代表本站觀點，本站所提供的攝影照片，插畫，設計作品，如需使用，請與原作者聯繫，文章轉自alibuybuy