英文原文：altdevblogaday，翻譯：遊戲邦
好友曾向我展示了最新的iPhone和iPad版《極品飛車》。遊戲的渲染效果令人印象深刻，是款蓄勢待發的優秀遊戲。但是，遊戲的前端是典型的 UI設計偏差案例。但介面中有大量的屬性資料等內容，它在玩家沒有時間做決定時提供了過多的內容。這些內容能夠顯著改變他們的遊戲體驗，但卻在玩家往往感 受不到變化的時候呈現。
這促使我開始思考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點緊密聯絡，複雜性可以存在，但不是必要因素。