好的用户界面-界面设计的一些技巧 - 博客 - 伯乐在线
& 好的用户界面-界面设计的一些技巧
| 标签： ,
如此我已记不得是什么时候发现的了，但在看完的那一刻便想将之翻译，分享给大家自己也受用。
时间过了很久，来到了2014年，终于静下心来花了大把时间连同图片一起译成了中文。像我这样业余的翻译六级分数只够及格的程序员，不敢说做到，但求意思到位。
1 尽量使用单列而不是多列布局
单列布局能够让对全局有更好的掌控。同时用户也可以一目了然内容。而多列而已则会有分散用户注意力的风险使你的主旨无法很好表达。最好的做法是用一个有逻辑的叙述来引导用户并且在文末给出你的操作按钮。
2 放出礼品往往更具诱惑力
给用户一份精美小礼品这样的友好举动再好不过了。具体来讲，送出礼品也是之有效的获得客户忠诚度的战术，这是建立在人们互惠准则上的。而这样做所带来的好处也是显而易见的，会让你在往后的活动进展（不管是推销，产品更新还是再次搞活动）中更加顺利。
3 合并重复的功能而使界面简洁
在整个产品开发期间我们会有意无意地创建很多模块，版面或者元素，而它们的功能可能有些是重叠的。此种情况表明界面已经过度设计了。时刻警惕这些冗余的功能模块，它无用且降低了电脑性能。此外，界面上模块越多，用户的学习成本就越大。所以请考虑重构你的界面使它足够精简。
4 客户的评价好过自吹自擂
在获得项目机会或提高项目转化率时客户的好评是一种极为有效的手段。当潜在客户看到其他人对你的服务给予好评时，项目机会会大增。所以试着提供一些含金量高的证据证明这些好评是真实可信的。
5 频繁展示你的主旨来加深印象
多次重复主旨口号这种方法适用于界面很长或者分页的情况。首先你肯定不想满屏刷出相同的信息，这样会让人生厌。但当页面足够长的时候这些重复就显示自然多了并且也不显得拥挤。所在在页面顶部放一个按钮然后在页面底部再适当放个突出的按钮的做法没有什么不妥。这样当用户到达页面底部在思考接下来该做什么的时候，你提供的按钮就可以获得一个潜在的合同或者即使用户不需要你的服务这个按钮也可以起到过滤的作用。
6 将选项与按钮区分开来
诸如颜色，层次及模块间的对比这些视觉上的设计可以很好地帮助用户使用产品：他时刻知道当前所处的页面以及可以转到哪些页面。要传达这样一个好的界面，你就需要将可点击的元素（比如连接，按钮），可选择的元素（比如单选多选框）以及普通的文字明显区分开来。在下图的例子中，我将点击操作的元素设置为蓝色，选中的当前元素为黑色。这样适当的设计可以让用户很方面地在产品的各模块间切换。但千万不要把这三种元素设计得混乱不堪。
7 给出推荐而不是让用户来选择
当展示许多项服务时，给出一个重磅的推荐项是个不错的做法，尽管推荐的设置无法满足所有用户。这么做是有理论依据的，已经揭示了这么一种现象：当面临的选择越多时，用户就越难做出决定。所以你可以高亮某个选项来帮助用户做出选择。
8 给出撤销操作来代替确定操作
假设你刚点击了一个连接或者按钮，撤销操作可以让操作流畅自然，这也符合人类的本能。而每次操作都弹一个确定框则好像是在质问用户你明白不明白这个操作会产生什么后果。我还是更习惯假设用户每次操作都是正确的，其实只有极少数情况下才会发生误操作。所以，为了防止误操作而设计的确认窗口其实是不人性化的，用户每次操作都需要进行毫无意义的确定。所以请考虑在你的产品里实现撤销操作来增加用户的操作友好度吧。
9 指出产品适用人群而不是做成全年龄
你是想把产品做成大众化的呢还是有精确的适用人群？在产品定位上你需要更精确些。通过不断了解目标客户的需求及标准，你能把产品做得更好得到更多与客户交流的机会，并且让客户觉得你很专业，在这方面是独家提供的优质服务。把产品定位得精确的风险就是可能缩小了目标潜在客户的范围，也使自身变得不那么全能。但这种做得更专业的精神却反过来会赢得信任，权威。
（贴士：喜欢下图中可爱的小人物造型么？去了解吧）
10 试着直接果断而不要唯唯诺诺
你可以通过不确定而颤抖的声音来表达传递自己的意思，当然也可以通过很自信的方式表达。如果你在界面中的表述用语多以问号结束，比如”也许”，”可能”，”感兴趣？” 或者”想要试试么？”，那么你完全还可以把语气变得更坚定一些。不过万事无绝对，或许适当放松措词让用户有自行思考的余地也是可以的。
11 界面要有鲜明对比让人容易区分
把主要功能区从界面中突出显示出来效果会好很多。使你的主要口号醒目有很多种方法。通过明暗色调的对比来突显。通过为元素添加阴影渐变等效果让界面富有层次感来张显主题。最后，你甚至可以在色相环上专门选择互补色（比如黄色与紫色）来设计你的界面，以达到突出重心的目的。综合所有这些，最后得到的界面会使你的主要意图与界面其他元素有明显的区分，得到完美的呈现。
12 指明产地
指明你的地区，所提供的服务，产品来自哪里意义重大，同时也将与客户的沟通引入了一个更具体带有地域特色的场景中。指出具体来自哪里，国家，省分及城市，也是一种在进行自我介绍或产品展示时被常常提及的。当你在界面设计中实现这点时，让人觉得非常友好。同时指明区域也会隐形提高产品的声誉，好上加好。
13 精简表单内容
人生性就懒惰，在填写表单时也是同样的道理，没人愿意填写一大堆表单字段。表单中每个字段都会有失去用户的风险。不是每个人打字都很快速的，并且在移动设备上进行输入更是相当麻烦的事情。问下自己表单中是不是每个字段都必需，然后尽量减少表单中的字段。如果你确实需要一大堆信息让用户填写，试着将它们分散在不同页面，在表单提交后还可以继续补充。过多字段很容易让整个表单显示臃肿，当然想简洁也很容易，只放少数字段。
14 暴露选项而不要将操作隐藏
你使用的任何一个下拉框都会对用户造成信息的隐藏而需要额外的操作才能显示。如果这些信息是贯穿整个操作所必需的，那你最好把它展示出来做得更显而易见一点。下拉框最好用在选择日期，省份等约定俗成的地方。对于程序中重要的选项最好还是不要做成下拉形式。
15 把界面做得环环相扣要好过直白的排版
一个平淡无奇行文无疑会让用户失去兴趣而继续阅读。是的，单列滚动的长页面是不错的，但是我们应该适当地设置一些小节，并且环环相扣，来提高用户的兴趣使其继续阅读。但需要注意的是节与节之间的留白不要太大。
16 不要放太多链接分散用户注意力
为了满足各式用户的需求，在页面上放些链接链到这里链到那里是常见的做法。如果你的主要目的是想让用户点击页面最后那个下载按扭什么的话，就需要三思了。因为用户可能点击了其他链接离开页面了。所以你需要注意页面的链接数量，最好将用于导航与用于操作的链接用样式区分开。尽量移除页面不需要的链接会让用户点击到你的功能按钮。
17 将操作的状态或者进度呈现出来
现如今大多界面当中已经呈现了各色样式的进度条或者标明状态的图标，比如邮件有已读或未读的状态，电子帐单有支付或未支付的状态。而在界面上呈现这样的状态对于用户来说是很有必要的。这样用户就可以知道某些操作是否成功，接下来准备进行怎样的操作。
18 不要让用户觉得是在完成任务
试想界面上有这样两个按钮：一个是”获取折扣”，另一个是”立即注册”。我敢打赌大多数人会点击第一个，因为第二个按扭让人感觉不到有利可图，并且”注册”让人联想到填不完的表单。也就是说让用户感受到获利的按钮更有可能被点击。这种让用户感到好处的文字信息也可放在按钮旁边，不一定要做为按钮的标题。当然，正常的按钮还是有用处的，一般用于重复性操作频繁的地方。
19 让操作直观而不是让人觉得找不到上下文
不用说直接在元素身上进行操作是更直观明了的方式。比如在一个列表中，我们想让用户对每个条目进行操作那么就把按钮放到当前条目上，而不要把放到列表之外。再比如就是直接点击元素就进入编辑状态（比如页面上的地址信息点击后可以进行编辑）。这种方式比传统的选中再点击相应的按钮进行操作要简洁省事得多。当然，对于一般性的操作本身就不需要有什么上下文的，就没必要这么做了，比如页面上的前进，后退按扭。
20 尽量显示全部内容而不要额外页面
在一个足够大的宽屏界面上最好还是直接给出表单，这比点击按钮再弹出表单要好很多。首先减少了点击操作，流程变得简洁也节省了时间。其次，直接呈现出表单可以让用户知道表单有多长，其实也是在告诉用户注册花不了多少时间。当然，这条规则适合注册表单非常简单的情况。
21 让界面平滑显示而不要死板地呈现
用户进行操作过程中，界面上的元素会经常出现，隐藏，打开，关闭，放大缩小移位等。给这些元素增加些自然的动画，淡入淡出效果不但美观，也更符合实际，本来元素尺寸位置的变化就是一个需要时间的动画过程。但要注意动画时间不要设置过长，那样会让想尽快完成操作的用户不耐烦。
22 循序渐进的引导而不要直接让用户注册
与其让用户马上注册，何不让用户先进行一些体验式的操作呢。这个体验过程可以展示程序的功能，特性等。一旦用户通过简单几步的操作了解了程序的价值所在，那么它会更愿意填写注册表单的。这种循序渐进的引导可以尽量推迟用户注册的时间但又可以让用户在没注册的情况下进行个性化设置等简单操作。
23 过多边框会让界面四分五裂
过程边框会喧宾夺主。不用说，边框确实在划分区域进行版块设置时有很大的作用，但同时其明显的线条也会吸引走用户的注意力。为了达到划分版块又不转移用户注意力的目的，在排版时可以将界面上不同区域的元素通过空白进行分组，用上不同的背景色，将文字对齐方式进行统一，还有就是为不同区域设置不同的样式。当使用所见即所得的界面设计工具时，我们经常在界面上方便地拖出很多区块来，这些区块多了就会显得杂乱无章。所以我们又会到处放些横线来分界。一个更好的做法是将区块垂直对齐，这样做不会让那些多余的线条来扰乱视觉。
24 展示产品带来的好处而不要罗列产品特性
市场就是这样的，用户永远只关心自身利益而产品特性对他们来说倒不是那么重要。只有利益才更直观地体现出使用产品所带来的价值。Chris Guillebeau在他的著作《100美元起家》中指出，相比压力，冲突，烦心事和未知的未来，人们在乎得更多的是爱，金钱，认同感和自由支配的空闲时间。所以我相信在展示产品特性时回归到利益上是必要的。
25 不要把产品设计得过于依赖于数据
界面上经常需要呈现不同数量的数据，从0，1，10，100到10000+等。这里存在个普遍的问题就是：在程序最开始使用的0条数据到过度到有数据之前，该如何进行显示界面。这也是我们经常忽视了的地方。当程序初始没有数据时，用户看到的就是一片空白，此时用户可能不知道该进行哪些操作。利用好没有数据的初始界面可以让用户学习和熟悉如何使用程序，在程序中创建数据。力臻完美永远是我们追求的目标，界面设计也不例外。
26 默认将用户引入
将界面做成默认用户选中想要使用你的产品，意味首如果用户真的需要使用，那么可以直接点击确定而不需要额外点选了。当然，也有另一种做法就是默认不选中服务，用户需要的话可以手动点选。前者这种设计更好的原因有两点。一是用户不需要额外点选，非常省事，因为默认设置为用户需要我们的产品或服务。二是这种做法某种程度上是在向用户推荐产品，暗示了其他人都选择了我们。当然，将界面设计成默认选择的样子多少存在点争议，有点强迫用户的感觉。如果你想道德一点，你可以要么把让用户选择的文字写得模棱两可，要么使用双重否定这样不那么直白的描述，这两种方式都可以让用户觉得没有那么强的感觉是被强迫选择使用产品的。
27 界面设计得一致，不要增加用户的学习成本
自从Donald Norman的一系列著作面世后，界面设计中尽量保持一致性成了一个普遍遵循的准则。在设计中保持一致性可以减少用户的学习成本，用户不需要学习新的操作。当我们点击按钮，或者进行拖拽操作，我们期望这样的操作在整个程序的各个界面都是一致的，会得到相似的结果出来。反之我们需要新情境下重新学习某种操作会产生何种结果。可以在很多方面下功夫来实现一个一致的界面，包括颜色，方向，元素的表现形式，位置，大小，形状等。不过在让界面变得一致之前，记住一点，适当的打破整体的一致性也是可取的。这偶尔的不一致性的设计用在你需要强调的地方可以起到很大的作用。所以世事无绝对，我们应遵从一致的设计准则，但适当地打破这种常规。
28 使用较贴切的默认值会减少操作
适当的默认值和预先填充好的表单字段可以大量减少用户的工作量。在节省用户宝贵的时间上面，这是种非常常见的做法，可以帮助用户快速填完表单或者注册信息。
29 遵从一些约定而不要去重新设计
界面设计中遵从约定的准则跟之前的界面一致性准则很相似。如果我们遵从了界面设计中的一些约定，用户用起来会很方便。相反，不一致和没有遵从约定的设计则会提高学习成本。有了界面设计中这些约定，我们想都不用想就知道界面右上角（大多数情况下）的叉叉是关闭程序用的，或者点击一个按钮后我们能够预测到将会发生什么。当然，约定是会过时的，随着时间的推移，同样的操作也有可能被赋予新的含义。但要记住，当你在界面中打破这些常规时一定要目的明确，并且出发点是好的。
30 让用户觉得可以避免失去而不是获得
我们喜欢成功，没有谁愿意失败。根据心理学得到的可靠结论，人们一般更顷向于避免失去拥有的东西而不是获得新的利益。这一结论也适用于产品的设计和推广中。试着说明你的产品会帮助客户维护他的利益，保持健康，社会地位等要好过告诉客户这个产品会带来一些他未曾拥有的东西。比如保险公司，它是在销售我们出事之后可以得到的大笔赔偿呢还是在强调可以帮助我们避免失去拥有的财产？
31 具有层次的图形化展示优于直白的文字描述
具有层次的设计可以将界面上重要的部分与不次要部分区分开来。要让界面层次分明，可以在这些方面做文章：对齐方式，间距，颜色，缩进，字体大小，元素尺寸等。当所有这些调整运用得适当时，可以提高整个界面的可读性。相比在一个很直白的界面上用户一眼就可以从上瞟到底的设计，这样分明的设计也可以让用户放慢速度来慢慢阅读。这样也使界面更有特色一些。就好比一次旅行，你可以乘坐高铁快速到达景区（从页面顶部瞟到底部），但你也可以慢行以欣赏沿途风光。所以层次分明的设计让眼睛有可以停留的地方，而不是对着空白单调的一个屏幕。
32 将有关联的功能分组而不是杂乱无章
将各个功能项分组合并起来可以提高程序的可用性。有点常识的人都知道刀子和叉子，或者打开文件和关闭文件是放在一起的。将功能相近的元素放在一起也符合逻辑，符合我们平时的认知。
33 使用内联的验证消息而不是提交后再验证
在处理表单时，最好立即检测出用户所填写内容是否符合要求然后给出验证消息。这样错误一出现能就能得到改正。相反，提交后再检查表单会给出错误消息，会让用户感到乏力又要重复之前的工作。
34 放宽对用户输入的要求
对用户输入的数据，尽量放宽限制，包括格式，大小写什么的。这样做可以更人性化一点，也使得界面更加友好。一个再恬当不过的例子就是让用户输入电话号码的时候，用户有很多种输入方式，带括号的，带破折号的，带空格的，带区号和不带区号的等等。如果你在代码中来处理这些格式的问题，代价也只是你一个人多写几行代码而以，却可以减少无数用户的工作量。
35 让用户感觉需要快速做出响应而不是毫无时间观念
适当的紧迫感是个有效的战术可以让用户立即做出决定而不是等上个十天半个月。重要的是这种战术屡试不爽，因为它暗示了资源的紧缺或者活动的时间有限，今天可以买，但明天可能就无法这么低价了。另一方面，这一战术也让用户感到会错失一次大好的机会，再一次，应用了人们害怕失去的本性。当然，这种战术会被一些人嗤之以鼻，认为是不耿直的做法。不过，这只是种战术而以，并且在保持合法性的前提下应用也无伤大雅。所以请不要为了营销而在界面上制造紧迫的假象。
36 使用饥饿营销
物以稀为贵。饥饿营销给出的信息就是东西不多，只剩几件，明天再来，可能没了。你去比较一下批发与限量版的东西他们的价格差距有多大就知道了。回过头来看，那些批发商或者大零售商，他们也使用饥饿营销，以获得更好的销量。但在软件行业，我们经常会忘记有饥饿营销这回事。因为数字产品是可以很容易拷贝复制的，不存在缺货的情况。其实，在界面设计中，也可以将其运用起来与现实中的资源紧缺进行联系。想想一次网上研讨会的门票，想想你一个月可以服务的人数限制，这些信息都可以告知用户是有限的。
37 让用户选择而不是重新填写
这一界面设计中的经典准则是有心理学依据的，相比要让某人回想想某样东西，从一堆东西中认出某样东西会更容易些。辨识出一样东西只需要我们稍微回忆一下，通过一些线索就可以完成。而回想则需要我们全面搜索自己的大脑。也许这也是为什么试卷上选择题会比简答题做得快的原因。所以试着在界面上展示一些用户之前涉及到的信息让他们进行选择，而不是让他们想半天然后自己填写。
38 让点击更轻松
像链接，表单的输入框还有按钮等，如果尺寸做得大一点则点击起来更方便容易些。根据，使用像鼠标这样的外设来点击需要一些时间，特别是元素比较小的情况下，时间会更多。鉴于此，最好还是把你的表单输入框，按钮等做大点。抑或者你可以保持原有的设计不变，只是把元素可点击区域（也就是热区）增大。这样的一个典型例子是手机设备上的文本链接和导航菜单，它们文字不一定很大但背景是拉伸的，在很宽范围内点击都有效。
为作者带来更多读者；为读者筛选优质内容；专注IT互联网。
汇集优质的Python技术文章和资源。人生苦短，我用Python！
JavaScript, CSS, HTML5 这里有前端的技术干货！
关注安卓移动开发业界动态，分享技术文章和优秀工具资源。
关注iOS移动开发业界动态，分享技术文章和优秀工具资源。
为作者带来更多读者；为读者筛选优质内容；专注IT互联网。
由数百名译者组成，立志翻译传播优秀的外文技术干货。
一个专门为IT单身男女服务的征婚传播平台。
收录优秀的工具资源，覆盖开发、设计、产品和管理等。
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线博客团队正试图以我们微薄的力量，把优秀的原创/译文分享给读者，做一个小而精的精选博客，为“快餐”添加一些“营养”元素。
欢迎关注更多频道
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选博客文章
– JavaScript, HTML5, CSS
– 专注Android技术分享
– 专注iOS技术分享
– 专注Java技术分享
– 专注Python技术分享
（加好友请注明来意）
网站使用问题
请在询问或者反馈
& 2015 伯乐在线
赞助云主机， 赞助云存储游戏设计课程之创造优秀的用户界面（17）
发布时间： 16:07:04
作者：Ian Schreiber
什么是用户界面？
通常，我们总是会将用户界面（UI）与软件应用联系在一起。这个术语指的是软件中与用户具有直接交互作用的内容。它包含着用户可以随时获取的一些选择，这些选择如何显示于电脑屏幕上以及用户与电脑间的相互作用（通过鼠标/键盘，游戏手柄等）。一般来说，电子游戏的用户界面分为2个部分：输入界面（即玩家如何控制游戏）和输出界面（游戏如何向玩家传达他们行动的结果以及游戏状态的其它方面）。（、、、、、、、）
如果你制作的是非数字游戏？它们是否也拥有游戏界面？当然，特别因为这种游戏缺少电脑对于游戏规则的控制，你更需要把握好它们的游戏界面。如果玩家并不理解非数字游戏规则，他们便会选择停止游戏。作为游戏设计者，你最不希望看到的便是你那精心雕琢的游戏机制和游戏体验因为界面问题而毁于一旦吧。
在非数字游戏中，用户界面是指游戏组件本身，它们既可以推动玩家与游戏进行互动（通过操控游戏组件）也可以用于接收反馈（通过观察游戏状态）。所以我们今天真正要讨论的话题是关于设计最后的游戏组件。
UI_simCity()
用户界面设计
如何才能凸显你的用户界面？从两个方面进行分析：
容易使用。如果你已经知道了自己想要做什么，那么用户界面能否帮助你更加快速且轻松地完成预期任务？
容易学习。如果你是一款游戏的新玩家，你是否能够轻易地从用户界面获得相关信息，并了解自己能够在游戏中做些什么？
但是通常情况下我们很难同时权衡这两方面。举个例子来说，电脑上有一个特殊的“热键”设置（Shift/Art/Ctrl/Cmd组合键等）能够帮助我们更快速且更容易地执行一些普通任务，如保存文件或者在不同应用之间做切换。但是如果热键是完成任务的唯一方法（就像一些早久的文字处理器缺少菜单选项），那么用户便很难在第一时间学习并了解该应用。
在桌面游戏的信息表达方面，你也常常能够看到这种权衡点。对于资深游戏玩家来说，图表，附录，关键词，特殊标志以及图标等能够帮助他们更好地了解游戏状态，但是对于那些根本不了解这些标志的新手玩家来说，只会因此更加疑惑。你也可以用普通写法去描述这些内容，以此让新玩家能够对此一目了然，但是因此也会浪费那些已经掌握游戏规则的玩家的时间，强迫他们反复地吸收自己已经掌握的内容。
有时候，你也可以同时包含这两方面内容。现代软件应用便同时包含了热键和菜单选项，有些甚至还有“初学者”模式，即隐藏了一些高级功能让菜单显得更加简单，并让用户更容易了解软件。纸牌游戏《万智牌：旅法师对决》虽然包含了关键词，但是也通过插入式方法向那些有疑惑的玩家解释了这些关键词的意思。
好好考虑你的游戏机制以及玩家在遵循这些机制时需要做些什么。如何做更好地强调措辞表达而不会让新手玩家感到疑惑？或者如何做才能让资深玩家感受到更加流畅的游戏体验而不再只是反复记录一些内容或执行一些自动步骤的体验。
2个可用性模式
计算机应用的可用性有两个相关概念：用户模式和程序模式。用户模式是指用户（也就是玩家）对于计算机运作的看法。而程序模式便是指软件如何正常运转。（在非数字游戏中，“程序模式”是指设计者制定好的真正游戏规则，而用户模式则是用户对于这些规则的理解。）
问题就在这里。程序模式永远是对的。而如果用户模式和程序模式相互一致，也就没有问题。但是如果两者出现了分歧，那么当玩家尝试着去做一些事并有所期待时，往往只能得到相悖的结果。这种情况要是出现在电脑游戏中，将会挫败玩家的斗志，从而让评论者认为这只是一种“拙劣的游戏控制”。
在桌面游戏中，如果用户模式和“程序”模式相违背，玩家可能会因此违反游戏规则而错误地进行游戏。有时候这会让玩家感觉到自己正在进行一种低等的游戏体验，因为游戏的某些方面已经失去了平衡。而有时候虽然玩家也会觉得游戏体验很棒，但是后来，当他们与其他玩家一起“正确”玩游戏时，他们之间便会出现关于规则的分歧。
user model(from otal.umd)
改变用户模式
我们经常能够在游戏测试中遇到用户/程序模式不协调的情况。就像是：在每一个测试小组中，总是会有些玩家在第一次接触游戏时出现一些错误。这就是不符合“容易学习”规则而造成的问题。
但是更严重的问题还是来自于违背“容易使用”规则的用户界面。就像是：一个或多个玩家总是会不小心违反游戏规则。你明确地向他们指明了要点，他们也相对地改正了自己的行为。但是当再次面对相同问题时他们却会因为忘记，而一次又一次地犯下相同错误。然后反复向你道歉，最终让玩家变成了一个“愚蠢”的角色？这应该不是你想要看到的吧。
在这种情况下，最理想的解决方法便是改变用户模式。也就是你需要因此改变玩家的期望值或行动以匹配游戏中的“正确”模式。但是不幸的是，这通常很难实现。因为人类是习惯性的动物。我们创建了与周遭世界相联系的心理模式，并牢牢依赖于这种模式。而改变模式是一个相对缓慢的过程，需要我们投入更多的努力，但是却很少人愿意在游戏中投入这种努力。
为了在我的课程中讲授这点内容，我列举了战斗机的设计故事。很久以前，有个军队注意到一种特别的飞机引发飞行员意外弹射（游戏邦注：即飞行员弹射椅会随机激活危害飞行员的安全）的频率远远高于其它类型的飞机。按照军用飞机的成本计算，这种情况的发生会引起高额的成本损失，所以军队便迅速召集了工程师以找出问题所在，但是最终却仍未识别任何可能的机械或电力问题。最后，有人提出从意外发生弹射的飞行员所训练的飞机身上找问题。而结果也证明这是一个非常棒的主意！因为所有在训练飞机上接受实战培训的飞行员所控制的节流阀和弹射椅都跟实战飞机上的设置完全相反。所以当这些飞行员在驾驶这种新飞机时，他们原来关于飞机操纵的心理模式已经牢牢根植于心中，新飞机的培训内容也很难改变这种模式。
识别用户模式
好吧，既然我们无法改变用户模式，那么当你发现用户模式与游戏相互矛盾时，你就应该改变游戏界面以适应用户模式，或者因此触发一个完全不同的新用户模式。但是，你如何能够第一时间掌握游戏的用户模式？
最快捷的方法便是主动询问。寻找一些正在玩一款与你的游戏类似的游戏的玩家。询问他们如何看待游戏的进程（或者他们将如何完成游戏任务，或者他们有何应对方法）。当你多问一些人之后，很快就能够得到明确的一致意见了。
另外一个识别用户模式的简单方法便是进行游戏测试。观察玩家何时玩游戏，记录他们何时开始出错等。
最后，如果你的游戏模式仍然趋于矛盾，你就应该好好考虑是那一环出了问题。只有在一切条件都出于相互平衡的状态下，玩家才能顺畅地玩游戏。
这是谁的责任呢？
有时候你会感到好奇，为何很多人会把可用性问题归咎于游戏设计者。毕竟，如果你创造了一款优秀的游戏，并设定了合理的游戏规则，玩家就有必要好好阅读并遵守这些规则。为何他们违背了游戏规则却变成了你的错？有些人真的很没有游戏天赋，或者说并未认真地玩游戏，而为何作为聪明的设计者你却需要为这些人的错误负责呢？
好吧，我需要澄清的是，首先，这并非玩家的错。他们也许是从别人那学习到如何玩游戏，或者他们处于一个容易分心的环境，所以很难一心一意地阅读游戏规则。他们可能根本就未接触到游戏规则，因为他们可能购买的是二手游戏，而已经略过了规则环节。可能规则的陈述并不是使用他们所了解的第一语言等等。如此可以解释为何如此多聪明，理性的玩家经常会违背规则的原因。所以千万不要贬低这些玩家的价值，你应该多投入点时间帮助他们更好地阅读游戏规则。
其次，很多可用性问题看似是用户（玩家）的错，但却往往都是用户界面引发的问题，但是却可以进行修改。如果你的游戏更加容易操作，玩家也不会容易犯错了。作为设计者，你应该为你的游戏可用性负责，如此你将发现玩家会更加快速地掌握游戏，犯更少的错误，并且拥有更棒的游戏体验。
创建优秀的用户界面
既然我们知晓了如何识别糟糕的用户界面，我们又该如何创作出优秀的用户界面呢？一般来说，优秀的用户界面包含两方面内容：
符合用户的期待；
即时给予用户反馈信息。
如果游戏未符合用户的期待，那就是我们上述提到的用户模式与游戏模式出现了分歧。还有一种设计用户界面的方法：即时给予玩家反馈，让他们知道自己做的到底是对还是错（并且能够第一时间意识到自己做错了以及错误的原因）。
以下是从另一个角度去看待优秀用户界面：
让玩家更容易做对事；
让玩家难以做错事。
举个例子来说：假设你有一款拥有许多符号的桌面游戏。也许你只有一套标记去记录玩家的得分，并在棋盘周围设置分数轨道。也许游戏棋盘中有一张划分了不同区域的地图，而玩家在不同区域都安插了自己的军队。也许这里还有一个可进行采购和销售的全球市场，并且拥有一个市价清单以区分不同类型的产品。
虽然我们总是很容易混淆不同游戏数位，但是如果每一个符号都拥有不同的大小和形状，并且每一个符号所处的空间都有与之相对应的形状，情况又是怎样？如此，我们便能够更加明确地判断小符号必然行走在小规模的分数轨道上，星形产品标记必然归属于星形产品价格轨道，以此类推。
玩家要如何记得在每个轨道上调整不同产品的价值？在轨道右边的棋盘上明确写明规则总结能够帮助玩家更好地记忆。如何解决战斗问题？在军队位置中印上单位强度，统计值以及能力信息，而余下规则也会总结于棋盘上或者参考卡片上，再或者可以通过游戏前玩家间相互告知的方法解决。
当你开始设计用户界面时，可以参考以下过程：
首先，制作一份任务清单，帮玩家理清游戏路线，让他们能够更加轻松地面对游戏任务。
其次，特别留意那些常见任务，即玩家会频繁遇见的任务。而因为复杂任务的出现频率较低，所以不用特别在意。
反复进行游戏测试。
颜色的使用
合理使用的话，颜色能够帮助你更好地向玩家传达信息。这是一种非常有效的方法：颜色无需占据额外的游戏组件空间，因为组件本身就存在着，你需要做的只是为其上色。以下是游戏中颜色使用的一些小窍门：
人类的眼睛最容易捕捉到的两种颜色是红色和绿色，其次便是蓝色。所以这几种颜色总是较为突出，能够轻易地吸引人们的注意；但是如果你使用过分明亮的色彩则很容易造成玩家的视觉疲劳。
但是不要单纯地依赖于颜色，因为在你的用户中肯定也不乏色盲者。除了使用不同颜色，你还可以通过改变颜色强度（例如黑白两色也能给你带来不一样的效果）或者使用不同形状等方法去区分不同物体。
qrossfire-symbols(from joshblog.net)
利用色彩的一致性。如果你在游戏中使用同一种颜色去描绘多种物体，那么就说明这些物体之间具有关联性。例如我玩过的桌面游戏中，有五种不同的资源，而每一种都有独自的颜色；每一位玩家也拥有属于自己的颜色，并且玩家的颜色会与资源的颜色出现重合，但是相同颜色玩家和资源之间并不存在连系。如此设置会让玩家感到疑惑，他们会想当然地认为一个颜色的玩家必然拥有同种颜色的资源，但是事实却并非如此。
更多用户界面设计技巧
排名不分先后：
如果可能的话，采取自动操作或清除那些不包含任何有趣决策的任务。在电子游戏中玩家每次的点击或键盘按压，或者在桌面游戏中的掷骰子或翻转卡片都需要受到一些有趣动机的影响。如果玩家首先接收到的是一些维护任务而在后来才能感受到决策乐趣，你便需要思考如何做才能让简化这些无聊的流程了。
使用视觉隐喻。如此我们更能看清它们分别代表了什么。如果你的玩家控制的是一些代表人的角色，你可以使用一些人型棋子，总比使用木质方块好多了。不同的棋子会让玩家对游戏拥有不同的看法。
同样地，如果你在游戏中使用图标去代表特定的能力，也尽可能地选择类似于其代表形象的图标。
与同类型游戏保持一致。在角色扮演游戏中，红心代表生命值，蓝色水滴代表魔力。为何要这么做？因为其它游戏就是这么做的，而你的玩家也会想当然地如此理解你的游戏。
不要想着“这个太晦涩了，我们可以在手册中详细解释。”记住，你的玩家不一定拥有手册，或者不一定会去看手册的内容。所以你需要尽可能地让用户界面足够一目了然，然玩家根本不需要借助手册的帮助。
创造一个优秀的用户界面是一种不同于核心系统设计的技巧，但是却是个值得我们深入学习的技巧。你需要记住，用户界面设计是一个非常广阔的领域，而我们在本篇文章中讨论到的还只是一点皮毛。
（本文为游戏邦/编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）
Level 17: User Interfaces
If you have made it to this point, your game is hopefully coming along nicely and you are approaching the final stages of design. You may still have temptations to mess around with the mechanics, especially given the short time period allotted for the Design Project, but at this point I want you to settle on something that is at least “good enough” so that you can experience the later stages of design.
Once your mechanics are complete and the game is playable, balanced, and meets your design goals, the last thing to do is figure out how to construct the final version. This is not simply a matter of drawing up some art for your cards and board and sending it off to the printer. There are some considerations to be made concerning the user interface of your game, and those considerations are what we will talk about today.
Readings / Viewings
Read the following:
Challenges for Game Designers, Chapter 16 (Creating a User Interface)
Cooperation and Engagement, a Google tech talk by game designer Matt Leacock. This video actually ties together a lot of the concepts we’ve talked about in this course, from difficulty levels and flow states to the iterative process to game narrative, and it should serve to solidify those concepts using the concrete example of Pandemic, one of the best-selling hobby games of last year. But what I really want you to pay attention to is how Matt presents his iterative work on the design of the game components themselves, such as how he determined the shape, orientation and color of the cards. The actual talk is only 30 minutes long, although there are an extra 20 minutes at the end from audience Q&A.
What is a User Interface?
Normally, we think of the term user interface (or UI) as it applies to software applications. This term refers to the parts of the software that interact directly with a human. It covers things like what options are available to the user at any given time, how those options are presented on the computer screen, as well as the physical interactions (mouse/keyboard, game pad, etc.). In general, with video games, the UI is divided into two parts: the input (that is, how the player gives commands to the game) and output (how the game communicates the results of those actions and other aspects of the game state to the player).
What if you’re making a non-digital game? Is there a UI? Of course there is – and if anything, it is more important to get it right, since you don’t have a computer automatically enforcing the game rules. If the players don’t understand the rules of a non-digital game, the only recourse is often to stop playing. As the game’s designer, the last thing you want is for your brilliant mechanics and carefully-crafted play experience to be ruined because of an interface issue.
In non-digital games, the UI is the game components themselves, since they are both how you interact with the game (through manipulating the game bits) and receive feedback (by viewing the game state). So what we are really talking about today is designing your final components.
User Interface Design
What makes one UI better than another? We generally talk of two things:
Ease-of-use. If you already know what you want to do, how fast and easy is it to perform your desired task correctly?
Ease-of-learning. If you are new to the game, how easy is it to figure out what you are allowed to do and what information is available to you?
In practice, there is often a tradeoff between these two. For example, on computers, the presence of special “hotkeys” (Shift/Alt/Ctrl/Cmd key combinations and the like) saves time by making it fast and easy to perform common tasks like saving a file or switching between applications. But if these are the only way to perform that task (as is the case with some older word processors that lacked menus), it makes the applications difficult to learn for the first time.
In board games, you often see this tradeoff with how information is presented. Charts, tables, keywords, special symbols and icons – all of these make it much easier for an experienced player to get a quick summary of the game state, but they can be confusing and intimidating to the novice player who does not know what these things mean. The alternative, writing everything out in longhand, makes it much easier for a new player to see immediately what everything does… but it also makes the game take longer for players who already know the rules and do not need them repeated in full on every card.
Sometimes you can include both. Modern software applications include hotkeys and menu items, and some even have a “beginner” mode that hides advanced functionality to keep the menus simple, making the software much easier to learn. Card games like Magic: the Gathering include keywords, but then explain those keywords in parentheses for players who do not know what the keyword means.
Look at all the mechanics in your game, and what players must do in order to follow them. Are there any cases where your wording could be clearer for first-time players? Are there situations where experienced players of your game feel like they are doing excessive book-keeping or note-taking, or performing multiple automatic steps, where it would be possible to streamline the experience?
The Two Models of Usability
In usability for computer applications, there are two related concepts: the user model and the program model. The user model is how the user (i.e. the player) thinks that things should work. The program model is how the software actually works. (In non-digital games, you can think of the “program model” as the actual rules of the game as intended by the designer, and the user model is what the players think the rules are.)
Here’s the thing. The program model is always right. If the user model and program model match one another, there is no problem. If the two are different, the player is going to do something, they’ll expect one thing to happen, but another thing happens instead. With computer games, this leads to frustration, and reviewers will say the game has “poor play control” (often without fully understanding why).
In board games, if the player model and the “program” model are different, the players will just play the game incorrectly. Sometimes, this means the players will have a suboptimal experience, because some aspects of the game will feel unbalanced. Other times, the players will have a perfectly good time, but when they later play the game with other players who are playing the game the “right” way there will be rules arguments.
Changing the User Model
It is common to see a user/program model mismatch during playtesting. Here is what it looks like: with every playtest group, the players always do one particular thing wrong the first time around. This suggests an ease-of-learning problem.
A more serious case is an ease-of-use problem with the UI of your game. It looks like this: one or more players accidentally do something wrong in the rules. You point it out to them, and they correct their behavior. But then they forget, and they do it wrong again on the next turn. And the next. And the next. And your players apologize to you for continuing to get it wrong, and they feel like idiots.
In cases like this, it would be ideal to change the user model. That is, you’d like to change your players’ expectations or actions in order to match the “correct” model of the game itself. Unfortunately, in practice, this is effectively impossible to do. People are creatures of habit. We build up elaborate mental models of the world around us, and we rely on those models greatly. Changing a model is a slow process that requires great effort on the part of a person, and most people are not going to put that kind of effort into your game.
To illustrate this in my classroom courses, I tell the story of the design of a fighter jet. Once upon a time, the military was noticing that one particular type of aircraft had a much higher-than-average number of accidental pilot ejections (that is, the pilot’s ejection seat was activated when the pilot did not intend for that to happen). Given the cost of military aircraft, it gets very expensive when something like this happens, so they had a lot of engineers study the problem to figure out why the seat was ejecting, but no mechanical or electrical problems could be identified. Eventually, someone got the bright idea to look at the aircraft that the accidentally-ejected pilots had trained on. It turned out that in all cases, they had trained on an aircraft where the positions of the throttle and the ejection seat controls were reversed! So, when the pilots got in this new aircraft, they had already formed a mental model of where all the controls were, and no amount of training on the new aircraft could change it.
Identifying the User Model
Okay, so we can’t change the user model. That means if you find a mismatch between the user model and the game, you should change the game’s interface so that it either conforms to the user model, or change the interface so that it is different enough that it triggers a different user model. But how do you know what the user model is in the first place?
Thankfully, this is pretty easy to do. The easiest way is to ask. Find people who play games similar to the one you’re making. Set up a situation for them, and ask them how they think the game would work (or how they would accomplish some task, or whatever you’re trying to figure out) if they had to guess. Once you ask a few people, a clear consensus will emerge pretty quickly.
Another pretty easy way to identify the user model is to playtest. Watch when people are playing the game, and make note when they do something wrong.
Lastly, if your game’s model is nontrivial, it is probably wrong. Other things being equal, people will assume simplicity.
Whose Responsibility Is It, Anyway?
You might wonder, in some cases, if usability issues are really your problem as the game designer. After all, if you create a good game and you give a complete and correct set of rules, isn’t it the responsibility of the players to actually, you know, read the rules and follow them? If they play your game wrong, how is that your fault? Some people are just stupid or careless, and certainly the brilliant designer should not be held accountable for these people. Right?
Well, first off, it may not be the player’s fault. They might have been taught by someone else. They might be in a distracting environment, so they can’t give the rules their undivided attention. They migh maybe they purchased the game second-hand and the rules were missing. The language the rules were written in might not be their first language. There are any number of reasons why a perfectly intelligent and rational person might have difficulty. So, don’t just write these people off as not worth your time.
Second, most usability failures feel like a mistake on the part of the user (player), but they are actually a UI issue that could be fixed. Consider: if your game were easier to use, it wouldn’t let the players make mistakes. As the designer, take responsibility for the usability of your game, and you will find that players are learning it faster, making fewer mistakes, and generally having a better time.
Building a Good UI
Now that we know how to identify a bad UI, how do you design a good one? In general, a good UI does two things:
It does what the us and
It gives the user feedback so they know what it did.
If the game doesn’t do what the player thinks it will, that is a problem with the user model not matching the game model, as we’ve already discussed. But there is one other aspect to designing the UI: giving the player immediate feedback so that they know what they did is correct (and, in the unlikely event that they did something wrong, they will immediately see that it is wrong and understand why).
Here is another way of looking at what a good UI does:
Make it easy to and
Make it hard to do things the wrong way.
Here’s an example: suppose you have a board game with several kinds of tokens. Maybe you have one set of markers that keeps track of player score, using a scoring track around the edge of the board. Maybe the game board has a map divided into provinces, and players have military units that are placed in the provinces. Maybe there’s also a global market with goods for purchase and sale, and a separate track for each trade good that lists its current price.
It would be easy to get all these different game bits confused. But what if each token was a different size and shape, and each space on the board matched the shape of the token that was used there? All of a sudden, it becomes a lot easier to figure out that the small square tokens must go on the small squares of the scoring track, the star-shaped goods markers go on the star shapes of the trade good price tracks, and so on.
How will the players remember how to adjust the trade good values on each track? A rules summary printed on the board right next to the tracks makes it easy to remember. What about how combat is resolved? Unit strengths, stats and abilities can be printed on the military units themselves, and the remaining rules can either be summarized on the board or on a quick-reference card or other player aid given to each player at the start of the game.
As you go about designing the UI, here is a process you can follow:
First, make a list of tasks that players need to accomplish in the game. Make it easy to do those tasks.
Second, pay special attention to the most common tasks, the ones that players are doing over and over. Difficulty and complexity of a task should be in proportion to how rarely it is used.
Iterate through playtesting.
Use of Color
Color is a great way to convey information to players if done well. It is efficient: color takes up no additional space on a game component, because the compon all you’re doing is coloring it. Here are a few quick-and-dirty tips for thinking about color use in your game:
The colors that normal human eyes detect most easily are red and green, followed by blue. These colors will tend to stand out more… which can be good for drawing attention, but bad for eye strain if you use fully-saturated bright colors.
Don’t a nontrivial portion of your audience has some degree of colorblindness. Vary the intensity of colors as well (so that if, for example, photographed with a black-and-white camera, you would still see a difference), and use different shapes in addition to different colors. By having things differentiated in multiple ways (different shape, different color, etc.) it makes it really obvious that those things are distinct from each other.
Use color consistently. If you use one color for several things in a game, those things should be related. Some board games I’ve played, for example, have (say) five different resources, and
but each player also has a color, and some player colors and resource colors are the same, even though there is no relationship between the green player and green resources. This kind of thing can confuse players who might think that a particular resource is owned by their opponent when it isn’t.
More UI Design Tips
In no particular order:
Automate or eliminate tasks that don’t involve interesting decisions, if possible. Every click or keypress in a video game, or die-roll or card flip in a board game, should involve the player doing something that is interesting to them. If the player first has to do a bunch of upkeep tasks just to have the privilege of making interesting decisions later, see what you can do to streamline the boring stuff.
Use visual metaphors. They make it obvious what something represents. If your players control a bunch of pieces that represent people, using people-shaped pawns is clearer than using wooden cubes. Compare the pawn images below. Each has a very different effect on how the player views it.
Likewise, if you use icons in the game to represent certain abilities, choose icons that look like the concept they’re representing (if you can).
Be consistent with similar games. In an RPG, red hearts probably mean life or hit points, while blue drops probably represent mana or magic power. Why? Because that’s how everyone else does it, and your players will assume by default that you do it that way too.
Don’t just say “well, this is confusing, so we’ll explain it in the manual.” Remember, your players may not have the manual and they may not read it. Try to make your UI intuitive enough that your game doesn’t even need a manual.
Lessons Learned
Giving your game a good UI is a skill that is separate from core systems design, but it is an important skill to learn. Keep in mind that, as with most things in this course, UI design is a huge field and we are only going to cover the very basics. There are entire courses (and even college majors) devoted specifically to UI, not to mention hundreds of books, and I encourage you to seek out these resources after this course is over.
Further Reading
There are many great books on UI design. If this topic interests you, I would recommend Donald Norman’s Design of Everyday Things, which gets into the details of how the design of something as simple as a door or a stove can go horribly wrong… with lessons that can be applied directly to games, both digital and non. Also, for ways to show game data to players in efficient and innovative ways, I would recommend any of Edward Tufte’s books: The Visual Display of Quantitative Information, Envisioning Information, and Visual Explanations.
If you are primarily interested in video games, there are so many great sources on computer UI that it would be hard to list them all here. If you have any personal favorites, leave as a comment on this blog post, or post on Twitter using #GDCU.
The ongoing homeplay from a week ago was to arrange for a blindtest session, which should be completed on or before this Thursday (August 27). Continue working on this if you have not completed it already.
Your other task, also before this Thursday, is to critically analyze your game with respect to user interface. Think about your playtests so far, and what rules your players have had trouble with. What kinds of components or player aids would make it easier for them to remember?
Come up with a user interface plan for the final version of your game. This plan should involve the following:
A complete list of all game components that will be included in the final game.
For each component, a detailed description of what you are planning to use. If you have, say, “one pawn to represent each player”, how many pawns are included? What colors will they be? What shapes? Will they be made of metal, plastic, wood, or something else?
If there are cards, describe a sample card. What information will be displayed on each card? Will the card be oriented as “portrait” or “landscape”? How will the information be laid out – where on the card will each item go? How will it be displayed – what colors, shapes, and keywords do you plan to use (if any)? If there are several kinds of cards, do this for each.
If there is a board, describe the layout of the board. As with cards, consider what information will be displayed on the board, how it is laid out, and how it is displayed.
If there are other components, give similar information to that listed here.
This list is mainly for your own reference, and the purpose is to make it as easy as possible for you to assemble your final game (which you will be doing this next week). The list also serves as a sanity check: do you have access to all the components you need? If you do not own some of them, think about how and where you plan to create or purchase them.
Post your UI plan to the forums no later than this Thursday (August 27), noon GMT.
By next Monday (August 31), read and respond to at least three other posts at the same level as you, giving preference to those that have not had any responses. By reading, it may give you some ideas to use on your own project. You may also be able to share some ideas you already have with others, helping them to improve their projects.（）
CopyRight Since 2010 GamerBoom All rights reserved &&闽ICP备&号-1