前言-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上通过调整顺序，简化操作的方式进行迅速的调整后再进行测试，数据就可以告诉我们正确答案了。

最后，我们同样来对优化阶段的技巧做一个梳理总结：