那些大的软件公司，譬如Apple、微软、Google等等，通常会为第三方app设计师们提供一系列设计指南。这样做的目的在于：
一方面，设计师和开发者可以比较轻松的上手打造在质量方面至少符合“基础标准”的产品，而无需重新思考和验证全新的设计模式及UI元素。
另一方面，如果某一平台当中的所有产品都遵从统一的设计规则，那么用户也将受益于界面外观与互动方式的一致性。
遵守设计指南，这几乎是一条铁打的规矩。但是在实际当中，“官方标准”未必能很好的适用于各种情况。我们不清楚为什么有些元素会出现在设计指南当中，也许是因为官方所做的测试不够彻底，或者说这些元素和模式是用来解决某一类设计问题的最基础最具适用性的解决方案。
本文当中提到的4种UI元素都是Apple惯于在自家app中使用的，其中的一些也出现在了官方的设计规范当中;自然，不计其数的设计师也会跟从这些用法。而另一方面，我们(Nielsen Norman Group)在一次又一次的可用性测试当中也真真实实的发现了这些元素所导致的可用性问题。
说不定Apple的诸神会用雷劈我们，但我们仍然建议各位设计师在使用这些UI元素时多加考虑，或尝试优化/替代方案，因为这些元素在可用性测试当中的表现确实存在问题：
页码指示符(小圆点)
导航栏里的完成按钮
加号(+)图标
拖拽图标
1.页码指示符(小圆点)
iOS的页码指示符，在形式上就是横排的圆点，用来表示一系列可以通过横滑浏览的分页视图。其中，代表当前视图的圆点处于高亮状态，其他的则是灰暗的半透明状态。
iOS系统首屏，页码指示符用来表示页面总数以及当前所在位置。我们时常见到这种通过系统首屏来演示页码指示符使用方式的范例，实际上，页码指示符能完美适用的界面环境并不多，而系统首屏正是其中之一，因为用户明确的知道自己的手机里装有很多app以至于第一屏无法完整呈现，需要通过横向滑动查看更多。
很多app或网页都会使用这种元素来暗示用户可以通过横向滑动来查看同级的其他页面，也有一些是将其用在界面中特定的区域来暗示其中存在更多内容。不能否认，这种形式的页码指示符在app和移动Web的界面设计当中都很流行，但是要知道，它同时也是用户最容易忽略掉的界面元素之一。在我们所做的一系列可用性测试当中，用户经常难以发现这些在尺寸上过于微小的圆点，进而错失了那些可以通过横滑来查看到的内容或功能入口。所以，我们认为圆点形式的页码指示符至少不能被用作关键功能和内容的唯一导航方式。
虽然iOS允许你将这些圆点渲染成其他颜色，但想要使如此微小的元素一目了然的突显在界面当中还是非常困难的，除非你能确保将其置于高对比度的纯色背景上。很多产品会将圆点们放置在五颜六色的banner图上，使这些本就难以被留意到元素不知不觉的融入到背景当中，进一步降低了可发现性。如果一定要这样做，那么必须确保圆点和背景色之间始终具有较高的对比度，最好是使用纯色背景。
iOS的Zappos，在第一张底图上，页码指示符已经很弱了，而在右侧第二张底图上，几乎完全消失了。
有一部分产品则在iOS的基础上进一步自由发挥，将圆点改为方形或其他形状，布局上也更加随意。不妨设想，即便用户已经习惯了iOS的小圆点模式，现在他们就算发现了界面中的这些小元素，还要猜想这些方块会不会就是代表着以前的那些小圆点 – 可发现性没有显著提升，同时还造成了认知上的困难。如果要使用页码指示符，尽可能使用用户已经熟悉的圆点模式，并将其居中的置于对应内容的下方。
Android中的Fab，借鉴了iOS模式的小圆点，但将其置于了内容的右侧，相比于居中的位置，更难被发现。
即便用户能够注意到页码指示符，这里还有一些潜在问题，譬如小圆点们可以让用户知道有多少同类型的信息视图以及当前所处位置，但无法提供任何与内容本身相关的信息。此外，用户对互动的控制权也非常弱，必须按照次序逐一浏览，无法直接跳转。所以，如果在你的需求当中这些体验要素比较重要，那么小圆点恐怕不是你的最佳选择。
鉴于小圆点页码指示符所存在的一些可用性问题，我们建议：
首先考虑你的内容是否适宜通过横滑的方式依次浏览，还是可以通过更复杂同时也更灵活的其他导航方式进行架构。
对于横滑浏览的内容，尽量采用右边缘露出一部分内容的方式来加强对于“更多”的暗示，而不要单纯依靠页码指示符。
2.导航栏里的完成按钮
iOS中很多代表“完成”操作的按钮时常被置于导航栏当中右侧的位置，包括表单界面的提交按钮也是如此。如今这种模式也开始潜移默化的影响到一些Android平台里的app。
根据我们的可用性测试所得出的结论，不说跨平台的影响力，单就iOS本身，我们也不建议将“完成”性质的按钮放在这里，原因很简单，将最终操作放置在界面顶部，有悖于自上而下的信息流向。用户在填写表单或编辑内容时，交互行为通常是由上至下的，当他们即将完成的时候，也会预期在结尾处看到结束处理的操作。多数情况下，当人们无法在结尾处找到这样的功能时，便会产生迷惑并开始四处寻找。
在下面的案例当中(左侧是Pinkberry，右侧是Nordstorm)，用户填写完表单之后需要点击登录或下单按钮。这样的布局就是我们所说的有悖于自上而下信息流向的形式，用户的全部注意力都随着表单而逐渐下移，最终发现在结尾的地方没有任何完成操作，剩下的就是茫然无措。要知道，即使是在手机这样的小屏设备上，四处寻找某种UI元素也是需要耗费很多额外的注意力成本的;将完成按钮直接放置在内容底部是最符合直觉的做法。
当然，从另外一个方面讲，将完成按钮置于导航栏当中的模式也有其自身的优势：因为导航栏是固定在顶部的，所以用户在编辑内容时可以随时点击到，而且当内容区域较长时，放置在顶部的按钮也不会被键盘所遮挡。如果用户确实无需完成全部内容的填写便可以进行完成操作，那么你可以考虑将完成按钮固定在底部，并会随着键盘的起落而相应的移动。这种方式的缺点是会占用一定的纵向空间，但优点也是很明显的：即符合直觉，又随时保持可见，同时相比于顶部右端的位置来说，更易单手点击操作。
鉴于导航栏里的完成按钮所存在的一些可用性问题，我们建议：将按钮置于内容底部;如果内容较长，可以尝试将按钮位置固定，并使其不会被键盘遮挡，以便用户可以随时点击。
3.加号(+)图标
见过的app越多，你越会发现，在不同的环境当中，加号图标往往会代表各种不同的功能。当加号位于导航栏当中时，通常表示“新建”功能;如果被放在列表单元当中，要么是表示将这条内容添加到某种分组当中，要么是用来展开详情。无论是在同一个app的不同界面，还是在不同的app之间，同一元素承载着不同的功能含义，这对于用户的认知与记忆都是一种负担。
加号图标的可用性在很大程度上取决于它在界面当中所处的位置。当位于导航栏时，加号通常能够表达准确的含义，即创建一条与主要内容相同性质的新内容。然而，当加号出现在主要内容当中时，多种含义的可能就会给用户带来迷惑。
举个例子，Any.do曾经的一个版本当中，会在待办事项分组标题右侧放置加号图标。在这个环境下，你不知道点击这个图标是会展开其中的全部事项，还是会在这个分组中创建新事项。在最近的一个版本中，他们将加号放在了界面右上角，明确的用于创建新事项。
无论是Web还是移动app，位于界面内容当中的加号图标通常用来表示该内容可以扩展查看更多信息，有时还会搭配箭头图标同时使用。通过加号来触发其他类型的功能很可能破坏用户所习惯的预期。例如，在LinkedIn的app当中，取决于所在位置的不同，嵌套在圆环当中的加号图标代表着关注或是加入某小组的功能。在我们的可用性测试当中，很多用户抱着查看详情的预期去点击该按钮，却发现自己关注了对方动态，进而感到莫名其妙。
取决于产品类型及目标用户行为习惯的不同，你的app当中的加号图标可能最适于表达某个特定的功能含义。无论怎样，要尽量避免在app当中随处使用，因为取决于所处位置的不同，用户确实很容易将其理解为不同的含义，或是抱着一直以来习惯的认知进行操作而导致与预期不符的结果。
鉴于加号图标所存在的一些可用性问题，我们建议：
导航栏是一个相对安全的位置，而在其他位置使用加号按钮则需通过可用性测试来确保用户能正确的理解你想表达的功能含义。
要彻底避免加号图标带来的潜在问题，不妨彻底避免使用它，取而代之的，通过箭头来代表详情扩展，通过简单明确的文字按钮来清晰准确的传达其他功能含义。
4.拖拽图标
和移动设备上的很多其他图标一样，拖拽图标也并不能很直观的体现出背后的含义。我们发现很多用户其实并不明白这个图标代表着所在元素是可以被拖拽移动的，而且纵向排列的三条横线也很容易让人误以为是某种菜单图标。实际上，这种形象隐喻的是可拖拽物体上的防滑条纹，好像你把手指放在上面就可以拖动整个对象而不至于打滑。通常，用户需要长按这个图标，使对象整体进入某种激活状态，然后拖拽到合适的位置。
在可用性测试当中，我们发现，用户更倾向于点按对象本身进行拖拽，而不是去按住一个含义模棱两可的小图标。相比于列表单元这样的对象，图标在尺寸上太小了，如果要求用户必须通过按住它来拖动整个单元，那么交互成本的增加就是必然的。此外，用户也会认为一个单元整体只会触发一种行为，也就是无论拖拽小图标还是单元本身，都可以使其被拖动。
Yahoo! Finace使用了标准的iOS拖拽图标，用户长按该图标可以使单元进入可拖动状态。虽然列表单元本身是目标更大、更易操作、更符合直觉的对象，但用户却无法通过长按单元本身来达到触发拖拽的目标。
此外，我们还是要强调一下拖拽图标与我们所熟悉的汉堡包菜单图标真的过于相似了：
外形相同或过于相似的对象，所触发的事件是截然不同的，这种情况会使人迷惑不安。虽然行业中关于汉堡包图标的争论愈发激烈，但越来越多的用户已经开始习惯了“点击三根线的图标展开导航菜单”的模式。当他们发现行为结果和他们所习惯的、所预期的东西不一致时，就会产生挫败与迷茫。
鉴于拖拽图标所存在的一些可用性问题，我们建议：
至少允许用户长按目标单元整体也能实现拖拽的目标，而不要只将交互区域限制在拖拽图标上。
另一方面，对于汉堡包菜单图标，可以尝试更清晰明确的表达方式，例如在三根线前面增加三个点，或是同时放出“菜单”标题在图标旁边。
小结
背离“官方的”、“常见的”设计模式，总会让人觉得不安，况且与大家的模式保持一致也能帮助用户降低学习成本。但是，无论你决定遵从怎样的设计规范，我们都建议你通过必要的可用性测试来验证这些模式是否真的适用于自家产品及目标用户。至少，在我们自己的研究过程当中，我们见到了很多用户在本文提到的4个常见模式上遇到了足够引发我们进行思考的可用性问题。
本文来源于伯乐在线
添加新评论