文丨Ring
騰訊互動娛樂 遊戲策劃
前言-MMO手遊的UI怎麼做
在進入正題之前，我們先來談一談標題中存在的兩個定語——手遊與MMO。
首先是手遊所帶來的的侷限——單屏承載信息有限、操作方式單一、手指操作視線遮擋、屏幕及文字大小限制等等；而和輕度手遊相比，MMO品類作為中、重度遊戲，其UI設計又面臨着系統規則繁瑣、系統之間關聯複雜、模塊數量大等難題。而當這兩個難題結合到一起彼此限制時，又構成了一個十分複雜而且彼此矛盾的問題集合體。作為UI設計師，往往就會在探索的過程中直面如下暴擊：
拿《一人之下手遊》的系統開發過程來舉例，像是最簡單的揹包系統，從2017年至今，經過了數十次的功能迭代和細節調整，直到遊戲上線運營，該系統也沒有停止功能和細節的優化。
而看到上面三張橫跨三年的開發效果圖，細心的同學可能會發現除了貼圖細節的變化，整個界面的佈局似乎並沒有發生巨大的調整。那為何經歷了數十次的功能優化和細節調整，卻仍然能保持最初的框架呢？
本文就用這個項目開發過程中採用的一套整體的UI開發流程，嘗試來給出這個問題的答案。
從零開始的三個階段
標題處的“從零開始”，代表着我們製作遊戲時沒有明確目標作為參考，遊戲本身和UI製作一樣，無法去從某個具體的目標身上尋求答案。這並不是流水線上的拼裝，而是要像孕育生命一般去摸索答案。我將研發過程中整體的UI製作分為三個階段：原型量產優化。
● 原型階段：在此階段，設計師要做的是設定標準，建立規則，為之後的量產階段提供依據。
● 量產階段：有了原型為依託，我們就可以對UI進行擴大化生產，並在此階段完成量產流程，解決過程中出現的問題。
● 優化階段：在完成量產，到了優化這一階段，我們要做的便是調優先前制定的標題，突出遊戲項目本身的優勢，並對整個UI設計進行多輪的測試驗證。
無論是做UI，還是做整體的系統開發，其實都可以概括為這三個階段。而既然我們強調地是從零開始，那麼最初的原型階段便是最為重要的，需要設計師傾注最多的心力。
一、UI的原型階段
首先，我們要明確一個概念，什麼叫做UI的原型？
很明顯，既然是從零開始，它就不能是一個借鑑甚至複製來的樣本；而它也不能是一個臨時拼湊的縫合怪，東借鑑一個揹包系統，西借鑑一個聊天框，這樣做出來的UI只會讓遊戲的整體交互邏輯混亂不堪。如果要給原型下定義，我認為它得是一個清晰明確，而且質量符合預期的可量產標準。比如圖上最初水滴造型的史萊姆（Slime），圓眼睛、較小的瞳孔和傻笑的造型，這幾個要素便是後來延伸出的史萊姆家族特徵。原型便是如此，通過一個明確的標準，可以進行多次的複製，擴展應用到遊戲當中的任何一個地方。
在《一人之下手遊》中，揹包系統的佈局設計便可以沿用至技能系統中的炁靈界面。同理，其他系統及界面的UI設計也都是從最初的原型延伸而出的。絕大多數情況下，由於不同系統會由多人來負責，連帶UI設計也是如此，所以原型作為可量產的標準，便極為重要。
確認了原型的概念，我們來進入正題：如何製作UI原型？
首先，我認為在常規遊戲開發過程中，有一個很普遍的思路誤區，就是先規劃幾個比較重要的系統，裝備、技能等等，先進行探索試錯，把幾個關鍵系統做完後再來總結原型的標準。實際上，放在MMO手遊，特別是在結構原創性比較強的遊戲中，我認為這種做法是不可取的。
開頭我們就強調了，MMO+手遊構成的是一個十分複雜而又彼此矛盾的問題集合體。面對複雜的問題，我們需要有條理地解決它。第一步，梳理整個遊戲的結構。這其實也是研發最初期每個團隊都會做的事情，將遊戲的基本架構、玩法、內容、經濟系統進行梳理。而做完第一步之後，我們要做的下一步是制定規則。與一般遊戲進行UI設計的過程不太一樣，MMO手遊的原型階段從試做原型提取規則轉變為制定規則試做原型。至於原因，我們回頭再提。下面，我們就將三個步驟進行拆解，逐一説明。
（一）梳理結構
梳理整個遊戲的結構這一步，對於UI設計師而言有兩件事，第一是梳理核心系統結構，簡單點説就是理清系統之間的關係；第二是明確關聯繫統通用模塊，也就是找到它們的共同點。
● 梳理核心系統結構關係-搞清關係
在《一人之下手遊》中，我們一開始便對核心系統進行了梳理，像是彼此關聯的系統便是MMO遊戲的核心。而像是商城、好友、公會的周邊系統，它們同樣重要，但是由於系統之間相對獨立，所以在原型階段的優先級便比彼此關聯的核心繫統低。
● 明確關聯繫統通用模塊-找到共同點
而當我們理清核心系統之間的關係後，便可以明確關聯繫統之間的通用模塊，也就是進一步梳理系統之間的關聯點，為後續制定規則提供基礎。上圖便是《一人之下手遊》中對於通用模塊的梳理，比如揹包系統中的兩個模塊在三個系統中都是共有的，而整理這些信息就是製作原型時的依據。
（二）制定規則
當我們明確完遊戲的整體結構後，便可以開始第二步：制定規則。這裏同樣可以劃分為兩點，一個是設計核心通用模塊，另一個是制定整體UI的規範框架。
為何我們區別於一般的遊戲UI設計流程，優先制定模塊和框架呢？一是架構複雜的MMO手遊意味着系統和運營組人數較多，當每個人都需要負責某一模塊時，UI的量產就必須要有規則，而明確規則的關鍵就落在通用模塊和整體規範的制定上。二是在製作原型之前，我們需要對遊戲中所有系統的複雜程度有所瞭解，比如一件裝備在遊戲中可以進行穿戴、分解、丟棄、修理等等這些操作，而在MMO遊戲中基本上還包括強化、染色等等操作，如果我們選擇略過制定規則的步驟，先着手開始為某個系統製作原型，這不難，但當你完成之後，你會發現這個原型很難移植到其他系統之中，或者很容易遺漏。所以只有前置了整體的規範，才能夠保證通用模塊應用在不同的系統中能夠產生對應的作用。
● 設計核心通用模塊
在講如何設計通用模塊之前，我們首先要明確通用模塊的概念，如果用比較通俗的比喻來形容，通用模塊之於UI設計便是樂高的積木塊，生物DNA的鹼基。再複雜的樂高積木都是由基礎的模塊組成，再複雜的DNA圖譜都是由最基礎的數個鹼基組合而成。
那麼設計通用模塊，從個人的經驗出發，有兩個原則可供大家借鑑。
第一個是結構靈活。換而言之，就是通用模塊需要可以被拆散、重組到任意系統之中，比如在《一人之下手遊》之中，我們將裝備欄設計成為斜向排列的菱形格子，而不是傳統UI裏圍繞着角色身體排列的數個方形格子，一是為了將裝備位和揹包的正方形格子做出明確的區分，二是為了在數量上可以自由增減組合來增加靈活性，作為通用模塊能夠在炁靈、銘文、時裝等系統中進行重組排列。事實也證明了這樣設計在後續對裝備位數量進行調整時大大減少了修改的時間成本。
第二個原則則是擴展性強，我們可以看上圖的右側部分，雖然都是角色展示的通用模塊，但是在不同系統出現時的側重點是不同的，比如説獲得新角色時，我們突出的是立繪和品質這兩個信息；在養成界面中，我們需要展示的信息就應該做相應的擴展，比如裝備、好感度等信息；而在出戰界面，顯示的便成了被動技能。一個通用模塊需要考慮的有很多、邊框、角標和信息的位置、以及它們各自的規則。只有在前期將這些制定好，後期才能免去需要不必要的調整重做。
● 制定整體UI的規範框架
在確認完通用模塊之後，我們的第二步就是設定整體的規則。總的來説，我們可以將它劃分為三個層面，底層規則；佈局框架以及視覺規範。
首先看下底層規則。它就像是建築的白皮書，由國家規定的，行業內對建築的制度規範，每個建築師都需要對它有清晰的認知並且無條件遵守。同理，UI的底層規則也是如此，它明確的是可做/不可做的規則，對製作原型與其後的量產會有很大的幫助。
如上圖所示，底層規則可分為兩種，整體原則與細節規則。整體原則代表全屏、彈窗界面的使用，衝突處理，以及每個項目都需要根據自身特點選擇的基礎圖形語言等等大方向的確立；而細節規則便涉及到一些基礎的設計語言取向（並無對錯，而是單純的選擇），按鈕狀態、信息排序、展示、跳轉等一系列細化的規範，初期便確立下來有助於整個團隊更早地遵循它們，為量產階段鋪做準備。
第二層是佈局框架，就好像一個建築的結構框架，明確了建築的層數、大小和基礎的佈局關係。UI佈局框架包含了垂直框架與水平框架，明確UI的佈局框架便是確定UI設計模式、信息的佈局排列以及邏輯順序。在不同的底層規則下，會產生不同的佈局框架。需要根據項目的整體需求來制定合適自己的佈局框架。在明確佈局框架指導下，所有UI的交互邏輯都會變得統一，不會讓遊戲的整體學習成本無謂提升。
第三層規範很好理解，就是美術向的規範。整體UI製作的前期就要和美術組/美術中心的同事進行溝通，確定下相關的信息，包括元件尺寸、字體字號、色彩使用等等規範，以免量產的時候出現無標準可參考或者標準混亂的問題。
（三）試做原型
在完成了前期的所有準備工作之後，有了佈局、用色等一系列規範，以及確定的通用模塊之後，我們便可以開始試做原型了。
● 選擇合適的系統
首先是選擇一個合適的目標系統來試做原型，很多遊戲在一開始都會選擇揹包系統來試做，原因自然是一般來説這個系統中包含的通用模塊最多，與其他系統的聯繫也最多。但是，具體問題具體分析，實際上還是在一開始先對自身項目的框架進行過梳理後再選用通用模塊最多的系統最為穩妥。而在《一人之下手遊》的揹包系統中，因為糅合了裝備和物品兩個大類，所以便選為了原型目標。
選擇完目標，接下來便是對揹包系統的基礎功能做一個梳理將界面上需要展示的信息全部羅列出來。
● 根據規範將模塊組裝成原型
選好原型目標後，我們便可以開始根據此前確定的佈局規範，將做好的通用模塊填充進界面之中，下圖便是一開始根據規範完成的大致佈局。
但是我們很快就會發現上圖的佈局是無法實裝的，因為在使用通用模塊的前提下，界面塞不下那麼多內容。遊戲中的裝備種類多達14件，裝備位佔據的區域會十分大，而物品欄更不必説，再加上還有角色屬性信息、時裝等等元素，我們就知道初版的佈局是需要調整的。而這也是之前強調先做模塊再做原型的原因，因為通用模塊已經確定，我們在佈局階段便可以儘早地發現問題，進行調整。如果不考慮模塊的通用性直接去做原型，很容易強行將諸多信息和內容塞在原型中，直接導致這個原型上模塊尺寸缺乏通用性，無法複用到其他系統中，最終同一個模塊在不同界面採用了多個尺寸的設計，無疑會對整體的資源維護和界面統一性帶來巨大的災難。
根據佈局規範和通用模塊來綜合考慮，我們便可以將各個元素進行優先級的取捨，裝備是優先級高的，那麼無法放置的時裝便可以用通用頁籤切換來展示；佈局上包含太多屬性信息不美觀，便可以進行摺疊，物品道具列表必須展示，那麼相應的各種操作也需要帶上。
理清佈局後，我們便可以開始細化原型，將通用模塊進行填充，在實際的界面上對模塊的位置和大小進行確認，並按照此前定下的規範將文字、按鈕等等具體細節進行展示説明。這也是為什麼一直強調規則先行的原因，否則等到原型做出來，才發現文案的長度限制放到其他系統行不通，那麼就得全部重新進行調整，事倍功半。
填充完了以後，我們便可以與美術童鞋合作，將原型進行視覺設計與展示。在這一步，我們的初版原型便算是完成了，可以放到遊戲中進行測試，再根據需求進行迭代。
研發過程中，UI肯定免不了修改。比如在功能測試過程中，我們便發現倉庫這個功能實用性不是很強，玩家更關注的是物品的分類，所以我們便針對性地進行了調整，將倉庫頁籤去除，然後將與之關聯的信息點也進行補充調整，比如圖標、文字顯示等等細節。而在進行過設計迭代，美術側的最終方案出爐後，我們的原型製作便基本完成了。它在交互和整體功能完善的前提下，無論是整體佈局還是紅點、不可用、顏色等細節都符合基礎的規範，達到了原型應有的標準。
在三年的迭代過程中，由於原型的製作從一開始便強調結構簡單，留出了足夠的調整空間，所以即使在後期我們又在裝備位中增加了藥劑，整體的框架也不需要大改，需要相應調整的只有美術和細節側的效果。選擇合適的標準模塊，制定和遵循基礎的底層規則和框架，讓一個系統穿越了三年多的開發時間，無數次迭代，卻依然能看到它一開始的樣子。
[ 最終上線版本展示 ]
我們花了很長時間來講述原型階段是因為它對於整體的UI製作師最重要的，後面的過程相對來説可能有的只是根據不同項目進行細節的變動。最後再提一下原型階段做設計的同學經常會遇到的一些困難。
如上圖所列，我們經常碰到的問題有三類，第一種是由於界面包含模塊過多所導致的擁擠問題，這是我們可以用過優先級的排序來對信息點進行取捨與摺疊。第二種是複雜操作導致的交互混亂，這裏我們可以將整個交互流程先進行梳理和拆分，比如傳統創建賬號的頁面都會要求一次性輸入大量信息，而現在創建帳號的步驟基本都會拆分為輸入賬號輸入密碼確認密碼輸入驗證碼勾選用户條款等多個部分來降低單個界面的複雜度；在相關聯的步驟中進行視覺關聯的強化也是一種方法，比如點擊一個圖標後與它相關聯的按鈕也會隨之亮起、對應的信息和底板高亮顯示等等。第三種則是操作步驟太多的難題，我們可以根據對玩家行為的引導，削減不必要的操作，比如提供默認篩選、信息自動填充、便捷操作等選項。
當然，如果通過以上的努力還是無法解決問題，建議大家可以在團隊內部進行溝通探討，看是否系統本身包含的模塊梳理着手、簡化系統所承載的功能。誠如我們之前所説，手遊不可避免的存在一些硬性侷限，“我全都要”是不現實的，我們能做的只有最優化的取捨。
最後，我們來對原型階段的一些技巧進行下總結：
缺乏整體規劃是手遊MMOUI製作的大忌，特別是原創度較高的手遊MMO，前期全面而詳細的整體規劃可以有效減少後期量產和優化的成本；
以模塊化的角度去梳理核心系統，有利於明確所有核心繫統之間的聯繫，預先發現結構上可能存在的問題；
明確而詳細的規則是原型製作和UI量產的基礎，也會讓設計方案變得十分直觀；
不要試圖在一個複雜系統中，通過單個界面解決所有問題。
二、UI的量產階段
在完成了最艱難的原型製作階段後，我們便可以進入下一階段——UI量產階段。
雖然已經有了原型作為參考，但隨着量產階段的深入，各種問題就會開始不斷湧現：
首先是和原型關聯緊密的系統界面製作，如果我們在前面原型階段所定下的規範沒有被團隊中每一個策劃好好執行，那麼量產出的產品將會和原型相去甚遠，你想要的史萊姆就可能變成波利或者岡布奧。
然後在製作一些和其他系統關聯有限、但功能複雜重要度又很高的系統時，容易遇到無從下手的問題：因為沒有任何現有系統能給出你想要的答案，你的量產之路遇到了攔路虎。
還有在製作一些全新的原創玩法時，你設計了多個可行的UI解決方案卻難以做出取捨，每個似乎都有各自的利弊，這時候又要如何去做抉擇呢？
這三類問題其實是從淺水區到深水區的漸進，接下來我們就來看它們的解決方法。
（一）關聯界面的量產——自我複製
首先是第一類，針對與原型相關聯界面的量產。既然選擇揹包系統作為原型，那麼與它共享通用模塊的技能、增強、轉移等等界面都可以參考原型與先前制定的規範進行設計，就比如細胞基因的自我複製，我們要防止的是在這個過程中忽視了原型與規範兩重參考，讓關聯界面產生了基因突變，那前面的準備工作便白費了。
這就要求設計團隊在進行量產工作時做到兩點，第一是貫徹規則，大到風格佈局，小到字號圖標，都要遵循一開始所設定的規範，防止走偏，這樣子量產才會是從史萊姆變成史萊姆家族；第二是確保一致性，相同功能的模塊在不同系統中的展示需要保持一致，比如在揹包、倉庫、炁靈、銘文等系統中出現的物品欄模塊雖然功能各異，但整體尺寸和位置都完全一致，堅持這種一致性遊戲整體的UI設計才能保持足夠的統一感。
（二）獨立系統的量產——參考整合
第二類是針對先對獨立且重要系統的界面量產。《一人之下手遊》作為我的第一個MMO手遊項目，在製作過程中我也碰到了交易系統這個相對陌生的挑戰：在交易系統中具體要展示哪些信息，提供哪些功能和這些功能的關聯方式，我很難立即給出一個明確的方案。
當感到無從下手時，我們能做的就是尋找任何與之相似的參考，看看市面上的優秀作品在對應系統上是怎麼設計的。當然，參考的意義在於幫助你理清設計思路，明確那些模糊的問題，而不是讓你直接生搬硬套過來。你需要做的是在尋求參考的過程中解構這些參考目標的方案，尋找到你需要的答案，然後將這些答案結合你制定的模塊和標準，設計出你自己的解決方案。
在製作《一人之下手遊》的交易系統時，我首先將當時流行的MMO手遊的交易系統進行過逐一的分析，明確它們在設計上的側重點、它們所包含的功能模塊都有哪些、這些模塊之間的聯繫是如何的，然後逐步將交易系統中的模塊進行了梳理，再根據《一人之下手遊》本身的項目需求，將需要展示的模塊確定了下來。
在這之後，便是將根據需求將這些功能模塊整合到一個界面當，根據規範與原型進行對應地設計，來完善整個界面。和製作基礎原型一樣，已經明確了模塊和模塊之間的關係，接下來要做的工作也只不過是根據基礎模塊和規則將它們組裝起來而已。
（三）全新界面的量產——關鍵抉擇
最後一類問題發生在我們想要打造一個相對原創系統的時候。這時先前的原型無法提供參考，那麼如何在不同的設計中進行抉擇變成了關鍵。
還是《一人之下手遊》的案例，當時要做一個多異人蔘與的團戰系統，我設計了兩套截然不同的方案，一個側重點在於關卡之間的連接與差異、另一個則側重於對Boss的展示，而它們的優缺點也很明顯，卻很難説孰優孰劣。碰到這種左右為難的情況時，我們很難根據設計本身的專業性來評判，此時便需要換一個角度來進行判斷。
我們可以拿大家熟知的精靈寶可夢為例來看這個問題：作為主角之一的皮卡丘是純電系寶可夢，從初始的皮丘到最終的雷丘都是如此，主要技能集中在電繫上。而與之相對的是伊布，伊布是普通屬性，通過用不同的石頭可以進化為不同的屬性。在未來方向未知的情況下，先選擇伊布，等到未來方向明確的情況下再進行有針對的進化，比選擇皮卡丘而言有更好的適應性。
而當我們在面臨一個兩難的選擇，而又無法找到市場驗證過的成熟方案做參考的情況下，我們最佳的選擇是同伊布一般，擁有較高適應性的方案。而在團戰系統的案例中，顯然右側的方案是較優的，原因就在於這個方案可以靈活地通過配置實現多樣的內容結構，這意味着設計的擴展性與兼容性都要優於左側方案。雖然有自己無法克服的缺點，但卻更利於這個系統本身的自我優化，節省設計和開發成本。總而言之，當面對一個原創設計時，方案本身專業性的優劣評判是一個方向，但方案的可調整空間也是十分重要的考量標準。
章節的最後來對量產階段的一些技巧進行下總結：
快速的量產需要對UI規則足夠的貫徹，保持共通模塊的一致性；
參考其他遊戲的系統和界面的時候，不要生搬硬套。將參考目標按模塊分解、整理和篩選後，根據UI規則進行重新制作；
設計原創系統的時候要儘量選擇更加靈活的方案，來適應接下來的調整和優化（因為這無法避免）。
三、UI的優化階段
現在，我們進入最後一個階段——UI的優化階段，也是最花時間的一個階段。每一個遊戲項目的UI都會在優化階段經歷多次的迭代，為了弄明白優化階段要做的事情，我們先明確一下進行持續優化的根源。
首先我們進行優化的根源來自於競爭，無論品類熱門與否，都存在同類競品之間的較量，熱門品類你面臨的是在無數競品中脱穎而出的壓力，冷門品類，只要你不是這個品類裏的唯一，你同樣得面臨着存量競爭的難題。你做的不如對手，就會遭到淘汰，唯一能做的就是不斷優化自身變得更強。
其次遊戲項目本身研發週期也會導致UI會進行持續的優化。一個MMO品類的項目從立項到完成研發上線時間是以年為單位的，主要原因就是內容研發的週期十分漫長。相對而言，遊戲系統的設計則相對較短。在內容開發的漫長過程中，系統則會不斷的進行測試和調整，伴隨着的優化也是在所難免的。
而隨着開發的推進，市場上不斷湧現的作品會持續刷新遊戲的質量標準和設計取向，在隨着時間的推移而不斷更新換代，這就意味着你完成的設計可能放到1-2年後就很難達到對應的質量標準，滿足用户的功能要求。那麼調整和翻新便是必須的。
就如《一人之下手遊》的揹包系統，在3年的時間裏，由於變化的市場與項目需求，進行了一輪輪的迭代，原先的4個功能模塊被刪除，同時又新增了6個功能操作，看似變化不大的系統實則發生了翻天覆地的變化。
講完我們必須做優化的根源，我們來看下做優化的路徑，大致可以分為三個過程：底層優化、競爭優勢、測試和驗證。
遊戲市場中，不同遊戲通過不斷探索和學習吸收他人的經驗來持續提升自己身的競爭力，以面對整個市場競爭的壓力。而在MMO這個品類中，做到處處完美近乎不可能的，有的遊戲強在PVP系統、有的遊戲強在PVE，有的休閒玩法做得好，只有明確了自身的競爭優勢才能在殘酷而複雜的市場環境下尋找到自己的生態位並且存活下來。而在項目上線前，我們需要通過測試和驗證來儘可能確保項目能夠在上線後獲得更多玩家羣體的認可。
（一）底層優化
首先我們來講底層優化，底層優化源自於項目自身的不斷探索，這就需要我們在開發過程中不斷的總結和歸納之前經驗的同時，還要不斷審視自身的缺陷和短板來進行不斷的修復。
以《一人之下手遊》的UI設計過程為例，揹包系統作為原型，裏面含有多個通用模塊可以移植到其他系統之中，但這多個系統的設計中肯定有各自的獨立模塊，所以在底層優化過程中，我們首先要做的便是從已經制作的系統中總結出新的規則，將新設計的模塊提煉沉澱出來，順勢進行進一步的優化。
我們之前一直強調原型階段所確立的規則需要在量產階段遵循，而如同建築的白皮書一樣，所有規則都會有其時間的侷限性，一份10年前的白皮書顯然不可能適用於現在。而到了優化階段也是如此，規則需要遵守，但這不代表它不可以被改變。
在《一人之下手遊》中，原先在制定異人的原畫圖標時採用的是兩套規則，但是後來我們在製作過程中便發現，如果能夠使用同一套資源，就可以節省整體的資源製作時間、降低添加和更換資源時涉及到的工作、更可以縮小下載包的體量。在技術允許的情況下，我們選擇通過將異人的原畫進行錨點設置來切割生成圖標，共享一套資源。而當一個界面進行了資源的改動後，自然可以優化原來的規則便將其擴展到其他相同的界面進行修改，保持整體UI的一致性。只要之前一直遵循了規則，在優化規則後進行的修改也會十分簡單。
但需要注意的是，基礎規則的改變需要謹慎進行，避免與其他原有規則產生衝突，如操作按鈕的位置之類基礎規則應當儘量避免變動，而如我們剛才所舉例地表現性的規則調整則可以不斷地進行優化。
（二）競爭優勢
接下來我們講競爭優勢，MMO手遊面對的是一個複雜且多變的市場，確認自己的競爭優勢十分重要。
舉個例子，上圖是19年上線的四個遊戲，它們各自的UI設計就有不同的取捨，《妖尾》手遊是回合制的戰鬥，節奏上較慢對應的給玩家也提供了更多交流空間，整個遊戲UI佔據的空間很大戰鬥中也能呼出整個聊天界面，讓遊戲操作變得更加方便，且玩家交流變得十分容易。《狐妖小紅娘》整體的場景可以看成一種3D的橫版卷軸，視角較低整個場景充滿層級感，製作上也十分精美。這樣的設計導致屏幕下方基本都是行走區域，而上方都是優美的場景，主界面採用了上方空曠，下方緊密的設計，讓自身優勢得到了很好的發揮。可以看出每個遊戲的界面都會根據自身產品的優勢，在設計上發生一些變化。
我們甚至發現，有的產品甚至為了突出自身產品優勢，犧牲了界面的操作便捷程度，就是為了強化自身的競爭優勢。雖然單從UI角度出發，這樣做會帶來一些問題，但為了產品本身的特點突出，有時候就需要做出一些取捨。
當然有人可能會説，難道不能在保證產品自身優勢的情況下，兼顧界面操作的便捷性呢？
這裏涉及到一個有趣的概念。經濟學中有一個不可能三角理論，用於描述資本自由流動、貨幣政策獨立和匯率穩定三者之間的特殊關係。UI設計也存在一個不可能三角理論，功能全面、界面簡潔和交互便捷這三者無法同時達成，必須至少捨去其中一個。在很多MMO手遊中，遊戲世界體量相較其他類型手遊而言一般都很大，所以很多功能入口一般會選擇分散在不同的NPC身上，犧牲部分功能使用的便捷性來保持整體界面的簡潔和功能的全面性，更多側重於帶給玩家強代入感。
為了突出自身產品的優勢，對於UI進行合理的取捨，是難免的，只不過在做出取捨後，根據不可能三角理論，強化因為取捨而更容易達成的目標才能更好的發揮取捨帶來的益處。
（三）測試和驗證
當我們完成了底層優化與自身競爭優勢的確立，接下來肯定是將你的遊戲交給玩家測試進行驗證，也是每個遊戲項目必經的一步。作為設計師，你認為專業的、對的設計不等於用户希望看到的設計。需要通過收集反饋和數據，來驗證玩家對設計的接受度。
通過玩家參與的測試，主要收集的有效內容無非是用户的反饋和實際的用户數據，這一點上和遊戲其他方面的測試並無區別。
對於系統界面的測試方法無外乎CE訪談和小範圍測試兩種。如果是單人玩法，我們多數會採用CE訪談的方式，特別是對於原創度比較高的玩法，交互邏輯是否易懂十分重要、CE訪談可以讓你近距離觀察用户接觸到系統時第一時間的使用情況，聽到他們對界面的第一印象，這些都可以幫助我們在早期定位到界面存在的各類細節問題。而對於多人玩法，則必須讓用户處於真實的遊戲環境中彼此隔離，通過遊玩的過程不斷交互來發現問題所在，所以我們只能通過小範圍的測試一段時間後，才能獲得用户方面有效的反饋意見，這是面對面CE試玩無法達成的。
除了用户主觀的反饋意見之外，用户在遊戲測試過程中產生的數據也能的體現一些UI設計可能存在的問題。當然，數據所顯示出來的問題不見得就一定是UI造成的，比如一個界面中有四個平行選項，而當其中一個使用的幾率明顯高於其他操作時，既可能是由於UI排布順序造成的問題，也可能是玩家認知或者平衡性本身的問題。此時在UI上通過調整順序，簡化操作的方式進行迅速的調整後再進行測試，數據就可以告訴我們正確答案了。
最後，我們同樣來對優化階段的技巧做一個梳理總結：
UI的規則需要在製作過程中不斷的優化和完善；
需要根據產品自身優點和特色去做出選擇和取捨，切忌盲目跟風，選擇和產品特性不符的方向；
玩家的反饋和測試的數據可以驗證設計和選擇的效果；
只有對不斷的優化和調整有足夠的預期和準備，才能將這些改動帶來的時間成本有效的降低。
結語
今天我們所提出的MMO手遊的UI設計理念是一個供大家參考的框架，也許各個項目都有不同的方法論，但是十分確定的是MMO手遊要求的是設計師一定要具備全局觀的視野，才能夠在漫長的研發週期中減少反覆修改的成本、把握項目的核心優勢，並在不斷迭代的優化過程中將其最大化發揮。
