擔心UI不專業、不貼近用戶？手機遊戲UI設計思路分享

基本原則

UI設計服務於玩法設計

我把這個原則放在製作UI的第一條，是要時刻提醒項目的每一個人——玩法設計服務於用戶，而UI設計服務於玩法設計。這條原則可能在嘴上說說的時候非常振奮，但實際製作過程中，我們通常會忘記它。之所以說是「服務於」，首先必須有服務精神——即不改變「上游」的需求，同時更好的表達作為「下游」的特色，讓「上游」舒服。

但很可惜，我們絕大多數遊戲的UI製作中，都會違反這條原則，最常見的例子就是：原本玩法設計每個角色4個被動技能，最後發現UI「塞」不下了，3條剛好，於是要求玩法做出改變，變成3個被動技能。這樣的思想是不允許的，UI服務於玩法，因此在這裡玩法即是法律，不可改變。當遇到問題的時候，我們應該去做的是整理思路，重新研究重新設計，來解決問題，而不是自以為簡單或者最快的去改變問題本身。

克魯格的可用性定律

這是開始設計後應被當做信條的3個定律，克魯格的可用性3定律是：

1.別讓我想（Don"t make me think）：這是任何一個軟體中，好的UI設計的基準。一個界面應該是讓用戶非常容易理解的，者往往建立於一些約定俗成之上。「除非有更好的選擇，否則就遵從標準。」——交互設計之父Alan Cooper。

作為一個手機遊戲的UI，我們可以偶爾使用市面上流行的UI設計方式（但他不應該僅僅是某一款成功遊戲的，而應該出現在絕大多數遊戲，形成一個規範），但是，手機標準的一些UI控制項和交互方式才是我們真正的基準，不要因為是一個遊戲，所以就覺得它和手機其他應用之間完全不同，在用戶層，控制項的習慣是由手機養成的，而不是手機遊戲養成的——沒有人真的因為要玩遊戲而購買手機。

除了一些「從未見過」的設計可以make me think以外，還有：

Confused：讓人困惑的，通常是因為所設計的內容帶有欺騙性、二義性或者含糊不清的，讓用戶感覺不知道該不該做出這個交互，但是這種「不知所措」卻不是因為在思考策略或者做決定而形成的。

「我」選中了誰？confused！

Surprised：選擇的結果讓人驚訝，通常是因為用戶的慣性思維做了一個選擇，結果卻發現與想像的根本不一樣（違反了「約定俗成」）所致。這種「違反」包括且不限於：一個令人驚訝的UI控制項，一個按下後反饋與提示（icon或者文字）所暗示的完全不符的按鈕……

如果藍色的是一個上下拖動的列表，往上拖你甚至可以看到第4條、第5條內容，這真是一個surprise！

2.點擊次數多不要緊，但必須每次都有意義：很多時候，我們會強調「方便」這個概念，而所謂的「方便」，直白的說就是「在更少的點擊次數里完成更多的事情」。但事實上這並不是真正的方便，所謂的方便，並不在乎你要點擊多少次按鈕，只需要每一次點擊都有它的意義。

3.去掉一半的文字，把剩下來的再砍掉一半：界面上不應該有太多的文字，除非這個界面就是為了用來表現文字的，比如閱讀書籍的界面。一個好的界面中文字（含數字）佔據整個界面的面積不會超過25%，最好是10%左右。我們設計一個UI，尤其是遊戲的UI，應當更多地考慮使用遊戲化的元素去做到這個事情：比如屬性標題相比文字Caption，icon會更合適；比如比起一張報表，雷達圖或柱狀圖會更合適；再比如比起「33%」或「355/1200」這樣的百分比數字，一根進度條會更遊戲化。

席克定律（Hick"s Law）

一個人面臨的選擇越多，則做出決定的時間越長。比起2個選項，人做5個選項會花更久的時間，這對於遊戲整體節奏的把握來說非常重要——相比從一個有60個任務的列表裡選出任務，先從8個章節中選出一個，然後再從這個章節下的7到8個任務中選出一個會更合適，在這點上國游的推圖做得很好。

同時看到過多的選擇不僅讓人不適，還會讓人放棄選擇。哥倫比亞大學商學院教授希娜?艾揚格(Sheena Iyengar)在《當選擇讓人失去動力》(When Choice is Demotivating)的論文中指出，選擇較少時消費者更容易購買果醬。當面對24種不同果醬時，60%的消費者會停下來試吃果醬，彈只有3%的人會買。而面對6種不同果醬時，40%的人會停下來試吃，卻有30%人最終購買。當選擇看起來太困難了，人會選擇不做選擇。

所以，不要給你的用戶過多的選擇，當選擇太多了，可以考慮把它「包一層」。

接近法則（The Law of Proximity）

格式塔（Gestalt）心理學：當東西距離很近的時候，意識會認為它們是相關的。

用戶下意識的就會認為上圖中的區域被分為3塊，每一塊都有上下2個部分。因此如果當左下角的「按鈕」（下半部分）與中間的「面板」（上半部分）相關聯的時候，無論它是否關聯左邊的「面板」，都會讓人覺得不適應。

奧卡姆剃刀（Occam"s Razor）

即簡單有效原理，代表性的話語就是「如無必要，勿增實體」。我們通常在「設計」過程中總喜歡做加法，並且不斷地用「更方便」「更全面」來說服自己，但是對於一個設計師來說，做減法是最考驗功底的。

當你為你的設計尤其是界面做了過多的加法之後，他非但不會如你所想的更加方便，反而還會變得無法使用——你更難發現界面想「說」些什麼；同時還將徹底打擊你產品的調性，每一個功能的流程，它所經歷的界面以及每一步驟界面的內容，都是有「語氣」的。

奧卡姆剃刀原則是一個普通用戶與設計師的分水嶺，掌握好它之後才有資格稱作一個設計師。因此作為一個設計師，在任何設計中，不要忘記「做減法」。

設計過程

真正地去理解一個玩法（和它的流程）

理解玩法中的調性

在真正開始設計一個玩法的UI之前，最重要的事情是去了解「上游」，即這個玩法的核心調性，包括且不限於：

這個玩法是玩什麼的？是一個玩家努力的回饋或者驗證玩法（如戰場、競技場還有各種「收菜」）還是一個玩家安排策略的玩法（如天賦、技能加點）？

它應該給出玩家什麼樣的感覺？輕鬆的還是嚴肅的？

它與眾不同之處在哪兒？首先相信設計的這個玩法應該是獨特的，即使是同一個玩法放在不同節奏的遊戲中，它也可以是獨特的。

它為遊戲的整體帶來了什麼樣的節奏變化，以及它自己的節奏應該是如何的？通常缺乏設計能力的設計中，設計師會把正在設計的模塊都當做遊戲最重要、最核心的模塊，並費盡心思把它設計得像遊戲的核心玩法一樣。但事實上每一個模塊都有自己的節奏，努力設計好它的態度是對的，但是不能偏激地去設計，還是要注意這個玩法的度。

在這一步的時候，最好和所有參與的人員，尤其是參與設計的人進行更多的交流，達成儘可能的共識，百分百的共識是不可能的，每個人都有自己的想法和經歷，所以每個人看同一件事情的角度總是會有差異的。但是「理解」絕對不應該是「這不就是xxxx么？」這樣的。

設想應用情景

在設計完或者大致理解了玩法設計之後，就要來設想一下用戶的應用情景。這裡最忌諱的是把自己代表用戶——「我玩的時候會這樣，然後那樣」或者「玩家只要這樣玩，就能那樣」，這樣的想法很玩家，並不適合設計師。作為設計師要想的是一個普通的用戶，在我們給他這些界面之後，他會怎麼使用，比如餓了么：

1.用戶打開餓了么，是因為想點外賣吃。

2.用戶進來之後既然是想點吃的，那最重要的就是什麼類型的吃的，正餐？下午茶？水果？不同的個體在不同的情況下會有不同的想法，所以「我會如何」這個概念就不合適。所以設計師應該給出用戶選擇這些的入口。

3.當用戶選好分類之後，會有2種可能：用戶會優先選擇店鋪（比如老吃一家店了，或者根據對應想吃的東西找名牌），或者用戶非常渴望吃某個東西，比如特別想來杯絲襪奶茶。所以應該有品類和店鋪可供用戶選擇。

就這樣一個引導用戶到菜單的「玩法」的應用情景就產生出來了，之後就該進入詳細的選擇內容和返回再選擇過程了，選擇完之後下單、追蹤進度、貨到後反饋一個閉環一氣呵成。

思考用戶的應用情景，最重要的是思考：用戶在什麼時候為什麼會進入這個界面，他到底想怎麼幹什麼。這當中的每一步都是有自己意義的，步驟的先後通常也應該是一個不可逆關係，如果你依然覺得先哪一步都可以，說明還沒有定清除這個「玩法」的調性——設想一個Fifa或者實況足球類型的遊戲：如果步驟是先選球隊，再選球衣，再布陣。則說明選球隊是慎重的事情，你應該先考慮清楚，當然這不代表選球衣也如此慎重，只是最後一步布陣也是慎重的事情，所以把選球衣獨立出來。但如果選球隊和選球衣同步，或者選球衣和布陣同步，他給出的感覺就是這一步的隨意性會更高，甚至會帶來錯誤的體驗，想一想用戶選球隊的時候關注的應該是什麼？應該是這個球隊的屬性（如進攻力等）。球衣顏色是否讓用戶喜歡，並不是一個強到能和屬性平級的東西，而是在接受了屬性之後的一個調劑。所以需要分2次選擇，當你把這兩步放在一起做的時候，就會給出一個錯誤的暗示：球隊屬性+球衣顏色（樣式等）是選擇球隊的依據。當然在這裡你還要用「克魯特的可用性第二定律」來「說服自己」——並不是說多出幾步操作就不方便了，因為這裡的每一步都是必要的——這個過程明確了玩法的調性。

列出整個交互過程的流程圖

當應用情景思考完之後，基本上整個流程就出現了，不妨把他記下來，因為這只是一個理想的流程。在確定這個理想的流程之後，就要開始細分每一步的操作流程，即每一個流程中的「事」，當然流程中大多的「塊」都應該本就是一件事。

一個MOBA遊戲中，我們會先選擇模式，然後選擇英雄，最後開始遊戲。而選擇英雄的過程還能進一步細分（假如沒有排位模式）為選擇具體那個英雄、選擇設定的Build（如天賦、符文之類），然後選擇英雄的皮膚，這裡我們就要看哪些應該是一體的，哪些應該是分步驟的，選擇用誰和build組成了「選英雄策略」，所以他們其實是一體的（同一件「事」），而選擇皮膚，則是對選定的英雄進行一個錦上添花，所以分開到下一步。

羅列出需要顯示的信息和與用戶的交互內容

這個界面解決什麼事情？

當確定完流程之後，我們要開始確定多少個UI了。每一個UI應該只解決一件「事情」（即一個UI一個主題），而不應該有過多的事情要去做，以避免一個UI有過多主題。所以我們要從流程中找出，到底有些什麼事情，然後針對每一件事情做一個UI。

比如遊戲的裝備系統玩法中，玩家可以裝備（使用）獲得的裝備（道具），可以強化裝備（道具），可以賣出裝備（道具），但這就是三件事，互不相干，所以你應該有3個對應的界面，並且確保他們的可辨識度，畢竟這3件事情雖然有著相似的操作，但有著截然不同的操作結果。

該不該在「選擇裝備」這個界面里設置賣出和強化功能以方便用戶操作？首先賣出是肯定不能要的：「我」是來選擇一個裝備穿上的，至少「我」希望它和對應的裝備（道具）都還是「我」的。「你」（設計師）卻給我一個按鈕讓裝備（道具）可能變得不是「我」的，這就是徒增心智負擔，所以賣出是一定不能要的！那麼再來看看強化是否需要？這取決於強化玩法的調性，假如強化本身是一個區別於裝備的策略玩法，「我」要強化一個裝備（道具）需要合理的分配我的資源（比如強化石等道具，還有金幣等等），是一個慎重選擇的過程，那麼它就不該出現在這裡，因為這裡解決的是「選擇裝備的策略」，但如果強化只是花點錢升級（前提是錢是最常見的貨幣，因此形不成策略，只是一個積累的貨幣的轉化過程）那麼它可以出現在這裡，成為「選擇裝備」的一個「輔助策略」——不同的強化玩法調性，帶來不同的設計方向，正是取決於強化和裝備能不能算是「同一件事」。

哪些信息幫助解決這個事情

可以簡單的羅列出遊戲中所有對於這件「事」有幫助的信息，所謂有幫助的信息，可以簡單地分析為：

這個信息和這件事情的元素是有關的：道具的icon、名字、類型、品質等級代表了一個裝備（道具）「是什麼裝備」，所以對於任何道具有關的界面，它們都可能是有用的信息。

這個信息能幫助「我」決策這件「事」：對於選擇裝備的界面來說，每一件裝備（道具）的屬性（比如攻擊力、防禦力什麼的）都是這樣的信息；但是裝備（道具）的價格肯定不是——因為對於通常的RPG遊戲來說價格不會影響我是否選擇穿上它，除非這也是遊戲的一個特殊規則。

「我」很想知道這個信息：一些信息它可能並不是直接對於解決「事」有用的，但是這些信息在這個應用情境下會給「我」一定的幫助，或者從心理上給我一些暗示等。例如：商城打折物品的原價、餓了么中「店長推薦」。

要注意的是，在這裡我們只需要思考需要列出的信息，而不要考慮如何表現它。相對的也不應該去思考一些「美化用」的UI元素。

幹掉不需要的信息

在整理出需要的信息之後，我們要拿出「奧卡姆剃刀」，把對於這件事情不重要的信息幹掉了，往往在這些信息中不那麼重要的信息有以下特性：

對這件「事」的這個過程不相干的信息：有很多信息看似對於這件「事」很重要，但是放在這個過程的這一環節，它就不是必要的信息了。我們設想一個裝備（道具）玩法，每一件裝備（道具）都有被動技能（類似MHW），配置被動技能甚至產生Build是這個裝備的核心玩法之一，因此了解配完裝備會有什麼被動技能、這些被動技能因為當前配裝所生效的效果都可能是必要的信息，但是在「選擇裝備」這件事情上，這個被動技能到底是什麼效果、它當前生效的程度其實都不重要，因為用戶更在意的是「我」配了多少個技能，到多少級（或者百分之多少的程度），具體這個技能什麼效果和這個級別的具體生效程度是進一步（另一個界面）的事情，所以當然可以在這個UI中被幹掉。

界面中不必要的「誘惑」：一些信息對應的元素添加之後，反而會引起用戶的好奇心，讓用戶期望進行「偏題」的操作，進而引發出一些與整個流程看似相關實則格格不入的流程和界面。比如在選擇英雄的列表中列出這個英雄技能的icon，原本用戶可能早已熟悉了這個英雄了，但是當你列出了這些技能icon（且僅有icon）後，用戶會想看看這個icon（不熟悉這個界面），或者icon對應的技能（熟悉界面後）的信息，這就是錯誤地「誘惑」了用戶，讓他產生了不不該有的、「偏題」的想法。

讓人想更多（策略）的信息：很多玩法本身是有策略的，所以提供出信息，但是有些信息也會間接地產生更多的策略，但是這些策略實際上與這件事情本身並不符合，那麼它就不應該出現在這個界面，而應該是另一個界面。設想一下D3中技能界面，如果出現在技能名下方的不是當前所選的符文，而是列出了所有符文高亮了選中的那個會發生什麼？這也類似「界面中不必要的誘惑」，因為「我」在技能界面中應該看到的是「我」當前的技能方案，這裡的策略是：「我應該換掉哪個」而不是「我要把哪個換成哪個」。

帶來心智負擔的信息：當「我」正在商城裡瀏覽各種時裝皮膚，配置到我的角色身上，看著「我」選的小姐姐角色變得更漂亮，並陶醉其中的時候，「你」（設計師）卻列給我看當前的時裝總共要多少錢，甚至「我」還差多少錢可以買下來。這就是典型的「不必要的心智負擔」，畢竟「我」正在欣賞的是美感，是美好的東西，最後這些美好也許會打動我去買下，請「你」（設計師）在「我」真的決定要買的時候，再告訴「我」還差什麼，而不是隨時隨地都告訴「我」。

排布界面

當確定完一個界面需要的信息之後，我們差不多也就可以確定這個界面的交互了（即用戶可以進行的操作），畢竟一個界面解決一件「事」。

根據重要級排序信息

首先我們應該為篩選出來的所有信息元素和交互排個序，列出它們對這件「事」的重要級，這裡一定存在先後關係——即沒有兩個信息（或交互）是等價的，不然說明信息或者交互還存在一定的問題（即使是「是」或「否」的選擇，也應該有一個更重要的，即設計師期望用戶去點的）。排序的依據可以是：

更接近這件「事」主題的：比如足球遊戲中選擇一個球隊的界面中，球隊是第一的，因為它是玩家最重要的選擇依據和交互，一切都圍繞著「選擇球隊」展開；其次才是球隊的實力，相比之下球隊實力信息本身也是一個非常重要的「選擇球隊」的依據信息，是玩家做出決定的根本因素，但它並不是交互的第一焦點。

更需要成為用戶視覺焦點的：比如一個「更換裝備」界面中，有每一件可選的裝備（道具），也有當前的角色屬性。這兩個信息都是用戶做出決策的關鍵信息，在「更接近這件事」上兩者的地位相當，但是作為設計師，更希望讓用戶看到的應該是每一件裝備的屬性（及其帶來的變化），因為這個玩法的策略點是——在比較之後決定選哪個裝備（道具）。其次才是裝備後的變化結果，即角色屬性。

除此之外，排序還有一個重要的工作就是「分塊」，即把哪些信息分成一塊（解決這件「事」的一個「點」或者說「問題」），當然，塊越少說明設計的越好。

根據排序安排元素

選擇界面元素即選擇UI使用的元件（控制項、component）。這個過程不僅考驗設計師對美的感官，同時還會有幾個要點：

能用圖形的不用文字（含數字）：這一條也正是克魯格的第三定律，既然是一個遊戲UI，那麼能採用圖形元素敘事的就一定不用文字，即使必須用文字，也應當考慮配合圖形。最常見的就是進度條、雷達圖配合屬性數值。純文字的UI對於遊戲是不合適的，當然對於讀書軟體還是不可避免的。當然最常見的例子還有一個就是用顏色來表達裝備品質，而不是傻傻地寫出「優秀」「精良」之類的文字。這一條即使不是做遊戲，也要儘可能地靠攏。

不用windows控制項：既然是一個手機上的軟體（只不過分類是遊戲而已），那麼就不該採用windows的控制項。不論是從產品調性或者約定俗成的角度來看，Combobox、RadioGroup都是特別不允許的。而實際設計中，包括一些彈出hint框什麼的，嚴格來說都是windows控制項，除非是完全不可避免，不然不應該設計，尤其是錯誤地認為這可以「更方便」的情況下。Windows控制項並不能帶來更方便或者更好的表現，能帶來的只是更不舒服的操作，除非你的產品是一個「端轉手」或者「山寨端游」的產品，並且一些細節必須使用這些控制項，才能體現出那種「原汁原味」，比如王者榮耀的很多UI設計其實是為了表現出這是手機版LoL，所以才用了一些windows的設計。

風格統一化：每一個界面的風格都應該是一體的，這個推薦參考一些類似Material Design的設計模板。當然光參考模板效果也不好，因為很多初級設計師會為了「草草了事」之類的原因，隨手放一個與整體感格格不入的控制項（組）在界面上。

根據元素設計布局

當選擇完元素之後，我們就可以開始為這些元件選擇他們應該出現的區域了，這步的思路非常簡單直白——越重要的塊，它的中心點越「接近」整個屏幕的中心，當然這裡的「接近」指的是兩點（屏幕中心和元件中心）間距/元件對角線長度來算的；同時越重要的塊，面積也應該更大。當然這也會依賴於採用的控制項，所以這步只是一個概念，而不是絕對的。

另外，這裡尤其要注意的是，相近功能的東西，應該儘可能湊在一起——接近法則。

根據布局調整內容

之後就是對整個界面的布局，這裡會開始微調一些控制項的尺寸，並且微調它們的位置（注意都是「微調」）。手機UI推薦使用扁平風格的，這樣也可以順便讓界面看起來不是windows的。所以有這樣幾個要點：

做對齊線，讓元素之間、尤其是相關的元素之間對齊，對齊是一種美感，也是一種關聯性的很好體現。

假如你要用列表，那麼列表應該貫穿整個屏幕（橫或者豎），好的列表其拖動方向順應屏幕長邊（比如橫屏就是橫著拖）；其元素寬高比相反於列表（橫拖的列表每一個元素應當是豎長的）；單行/列元素個數不應該超過2，推薦為1。

不要擔心按鈕太大，而應該擔心按鈕讓人誤解它的作用，太小的按鈕不僅看起來像是windows的，它的關聯對象也會不同——接近法則。

注意平衡，不要讓一側UI顯得很重（元素太多、太密）而讓整個屏幕彷彿會朝著一邊倒下去。

黃金分割很好，不過也不要被套死。只能說儘可能讓元素，尤其是看起來像卡牌的那些元素接近（而不是完全符合）黃金分割比例。

根據內容驗算節奏

我們的UI設計差不多就完成了，但是「行百里者半於九十」，這裡開始，我們就要驗證UI設計的好不好，首先就是自己得驗證一下：

通過「試試看」來對比：其實當我們設計的過程中，我們就會遇到一些糾結，比如某個元素是否換一個表現方式會更好？再比如換一個圖標會不會效果就不同？不要空想這些問題，試一試，對比一下，然後再選擇。

設計每一種可能出現的情況而不要空想：很多UI中的元素在使用重複的、相同的元素的時候會很好，比如列表中的道具，都是用同一個icon、同一個名字、同一個品質顏色的時候很棒，但是如果換成實際的會不會還這樣？甚至可能會看起來很花？還有就是當列表元素很多的時候看起來很好，但是只有1個元素會不會失衡？這些與其猜測，不如直接多扣點圖來看看「最後的效果」再做定論。

記得看看交互的節奏：UI設計的同時還要考慮UI的動畫表現，也要考慮用戶操作的UE，這個操作依然不是「方便」與否，而是看整個過程佔用的時間，是否符合這個界面應有的節奏，如果太拖沓或者太快，也是會摧毀掉一個好的UI設計的。但是節奏這個設計本身沒有規律可循，只有結合設計師的靈性和對遊戲整體調性把握才能得出這個結論。

看「用戶」的「反饋」

當做完一個UI設計之後，我們應該拿給別人看，把他們當做用戶。對我的Team而言，我就是他們的「用戶」，在他們完成設計後就會首先拿給我看。作為他們的「用戶」，我會發表我的感受與我的指導，但是絕大多數用戶並不具備專業性，所以要學會自己去提煉用戶真正的反饋。

拿給你的「用戶」看，而不是說給你的「用戶」聽

你需要做的是把你的UI拿給你的用戶看，然後不做出任何的解釋，假如是一份策劃案，最好不要帶任何說明文字。讓你的「用戶」自己去理解，假如有什麼不理解的，那隻能說明設計有問題。這也是很多優秀團隊採用one page設計模式的一個核心原因——一切問題盡在不言中。

聽、分析、反思，而不是解釋

把UI拿給你的用戶，看他的反應。他的表情、舉止、和下意識提出的問題就是對你UI的反饋（當然也有人帶著找茬的心態看UI，學會自己過濾就好了）。在這一步，你應該去發現哪些原因讓用戶感到困惑，哪些表現讓用戶不能理解。千萬不能對UI進行解答，尤其是當你的「用戶」問你的時候，你也要假裝自己是另外一個不知情的群眾，不要把設計時候的心思告訴他，因為這樣他的困惑會被你誤導而消失，但是並不是所有用戶都有機會聽你說的。

「對症下藥」

解決設計問題要對症下藥，而不是哪兒不對改哪兒。甚至在必要的時候徹底刪除已經設計好的界面，從0開始重新整理重新設計也是必要的。比如有時候你的用戶發出這樣的驚訝——「這個按鈕竟然不是控制這個變化的？」這個問題真的僅僅只是按鈕的位置、尺寸不對嗎？具體問題還是需要具體分析之後才做出解決方案。最重要一點：不要怕辛苦！設計UI耗費大量時間和精力是必須的，因為設計UI，就是你在教你的遊戲如何跟玩家暢快地交流，甚至對他們講述遊戲的故事。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！