，供参考。这类文章背后的思维方式乃至精神是最需要吸收的，内容本身是其次的；你读的越多，你练习的就越多。你经历的越有代表性的产品案例，你就越会发现，很多时候，设计是无知的、黑暗的，并没有什么错。只有特定的产品、特定的资源、特定的情况、特定的用户群体，所有这些因素混合在一起，呈现出各种可能性，需要不断地权衡、争取或妥协。在下方输入文字。那些大的软件公司，如苹果、微软、谷歌等，通常会为第三方应用程序设计者提供一系列的设计指南。这样做的目的是：一方面，设计人员和开发人员可以轻松地开始创建至少在质量方面符合“基本标准”的产品，而无需重新思考和验证新的设计模式和UI元素。另一方面，如果平台中的所有产品都遵循统一的设计规则，用户也将从界面外观和交互方式的一致性中受益。遵循设计指南，这几乎是一条硬性规定。但在实践中，“官方标准”未必适用于所有情况。我们不知道为什么有些元素会出现在设计指南中，也许是因为官方测试不够彻底，或者这些元素和模式是解决某一类设计问题的最基本、最适用的方案。本文提到的4个UI元素都是苹果在自家App中使用的，其中一些也出现在官方的设计规范中；自然地，无数的设计师会遵循这些用法。另一方面，我们（NielsenNormanGroup）实际上在可用性测试中一次又一次地发现了由这些元素引起的可用性问题。也许苹果大神会闪电劈我们，但我们还是建议设计师多考虑这些UI元素，或者尝试优化/替代，因为这些元素在可用性测试中确实存在问题：页码指示符号（小圆点）完成导航栏中的按钮加号（+）图标拖动图标1.页码指示器（小圆点）iOS的页码指示器在形式上是一个水平的点，用于指示一系列可以通过滑动浏览的选项卡视图。其中，代表当前视图的圆点处于高亮状态，其他为灰色半透明状态。在iOS系统的首屏，页码指示器用于指示总页数和当前位置。我们经常通过系统首屏看到这个如何使用页码指示器的例子。事实上，页码指示器能够完美应用的界面环境并不多，系统首屏就是其中之一，因为用户清楚地知道自己的手机中安装了如此多的应用程序，所以第一个屏幕无法完全显示，需要横向滑动才能查看更多。许多应用程序或网页使用此元素来暗示用户可以通过水平滑动查看同一级别的其他页面，也有一些在界面的特定区域使用它来暗示其中的内容更多。不可否认这种形式的页码指示器在app和移动web的界面设计中非常流行，但要知道它也是用户最容易忽略的界面元素之一。在我们做过的一系列可用性测试中，用户经常会发现这些尺寸太小的圆点很难找到，从而错过水平滑动可以看到的内容或功能入口。因此，我们认为，点状分页指示符至少不应作为关键功能和内容的唯一导航方式。虽然iOS允许你用其他颜色渲染这些点，但要让这么小的元素一眼就能在界面中脱颖而出是非常困难的，除非你能保证将它放在高对比度的纯色背景上。许多产品会在彩色横幅图像上放置圆点，使这些难以被注意到的元素在不知不觉中融入背景，进一步降低了可发现性。如果必须这样做，则必须确保点和背景颜色之间始终存在高对比度，最好是纯色背景。ZapposforiOS，在第一个底图上，页码指示器已经很弱了，而在右边的第二个底图中，它几乎完全消失了。部分产品在iOS的基础上进一步发展，将圆点变为正方形或其他形状，布局更加随意。试想一下，即使用户习惯了iOS的小圆点模式，即使在界面中发现了这些小元素，他们仍然要猜测这些方块是否代表了之前的小圆点——可发现性并没有显着提升，同时也导致认知困难。如果要使用页码指示器，请尽可能使用用户已经熟悉的圆点图案，并将它们放在相应内容下方的居中位置。Android中的Fab借鉴了iOS模型中的小点，但将其放置在内容的右侧，这比在中心更难找到。即使用户可以注意到页码指示器，这里也存在一些潜在问题。例如，小圆点可以让用户知道同类型信息的浏览次数和当前位置，但不能提供与内容本身相关的任何信息。另外，用户对交互的控制力也很弱，必须按顺序一一浏览，不能直接跳转。因此，如果这些体验元素在你的需求中更为重要，那么小圆点未必是你的最佳选择。针对小圆点页码指示器的一些易用性问题，我们建议：首先考虑你的内容是否适合横向滑动浏览，或者是否可以通过其他更复杂灵活的导航方式进行结构化。对于水平滚动的内容，尽量采用在右边缘露出部分内容的方式来加强“更多”的提示，而不是仅仅依靠页码指示器。2、导航栏中的完成按钮iOS中很多代表“完成”操作的按钮往往放在导航栏的右侧，包括表单界面的提交按钮。现在这种模式也开始潜移默化地影响到安卓平台的一些应用。根据我们可用性测试得出的结论，且不说跨平台的影响，我们不建议将“完成”按钮放置在这里，原因很简单，最终操作放在界面顶部。与自上而下的信息流相反。当用户填写表单或编辑内容时，交互通常是自上而下的，当他们即将完成时，他们也希望在最后看到一个处理结束的动作。大多数时候，当人们最后找不到这样的功能时，他们会感到困惑并开始四处寻找。#p#在下面的例子中（左边是Pinkberry，右边是Nordstorm），用户在填写表单后需要点击登录或者订购按钮。这种布局就是我们所说的一种与自上而下的信息流相反的形式。用户全神贯注随着表单逐渐下移，最后发现最后没有补全操作，剩下的一头雾水。不知所措。请注意，即使在像手机这样的小屏幕上，也需要格外注意四处寻找一些UI元素；将完成按钮直接放在内容的底部是最直观的做法。当然，从另一个方面来说，将完成按钮放置在导航栏中的模式也有其自身的优势：由于导航栏固定在顶部，用户在编辑内容时可以随时点击，在内容区域时很长，放在上面的按钮不会被键盘遮挡。如果用户不需要填写所有内容来完成操作，那么可以考虑将完成按钮固定在底部，它会随着键盘的升降而相应移动。这种方式的缺点是会占用一定的垂直空间，但优点也很明显：直观可见，随时可见，相比右上位置更容易单手点击。鉴于导航栏中的完成按钮存在一些可用性问题，我们建议：将按钮放置在内容的底部；如果内容较长，可以尝试固定按钮的位置，使其不会被键盘挡住，方便用户随时点击。3、加号（+）图标你看到的应用越多，你就会发现，在不同的环境中，加号图标往往代表着各种不同的功能。当加号出现在导航栏时，通常表示“新”功能；如果放在列表单元中，要么表示将此内容添加到某个组中，要么用于扩展详细信息。无论是在同一个应用的不同界面，还是不同应用之间，同一个元素承载着不同的功能意义，对用户的认知和记忆都是一种负担。加号图标的可用性很大程度上取决于它在界面中的位置。当放置在导航栏中时，加号通常传达创建与主要内容性质相同的新内容的确切含义。但是，当加号出现在主要内容中时，多重含义的可能性会使用户感到困惑。例如，Any.do的一个版本用于在待办事项组标题的右侧放置一个加号图标。在这种环境下，您不知道单击此图标是会展开其中的所有项目，还是会在该组中创建一个新项目。在最近的版本中，他们将加号放在界面的右上角，明确用于创建新项目。无论是网页还是移动应用，位于界面内容中的加号图标通常用于表示可以展开内容以查看更多信息，有时也与箭头图标一起使用。使用加号触发其他类型的功能可能会打破用户习惯的期望。例如，在LinkedIn应用程序中，嵌套在圆圈中的加号图标代表关注或加入群组的能力，具体取决于位置。在我们的易用性测试中，很多用户抱着查看详情的期待点击了按钮，却发现自己关注了对方的消息，莫名其妙。根据产品类型和目标用户的行为，您应用中的加号图标可能最适合表达特定的功能含义。无论如何，尽量避免在app中随处使用，因为根据位置的不同，用户确实很容易将其理解为不同的意思，或者以自己一直习惯的认知来操作，导致不一致期望的结果。针对加号图标的一些可用性问题，我们建议：导航栏是一个相对安全的地方，而在其他地方使用加号按钮需要进行可用性测试，确保用户能够正确理解你想要表达的功能含义.要想完全避免加号图标带来的潜在问题，不妨完全避免使用它。而是用箭头来表示细节的展开，用简单明了的文字按钮来清晰准确地传达其他功能的含义。4.拖动图标与移动设备上的许多其他图标一样，拖动图标不能直观地反映其背后的含义。我们发现很多用户不理解这个图标的意思是元素可以拖拽移动，而且垂直排列的三横线很容易被误认为是某种菜单图标。其实这张图是在比喻可拖拽物体上的防滑条纹，就好像你把手指放在上面，就可以拖拽整个物体而不会滑倒。通常情况下，用户需要长按这个图标，让对象整体进入某个激活状态，然后拖拽到合适的位置。在可用性测试中，我们发现用户更有可能点击对象本身来拖动它，而不是按住一个含义不明确的小图标。与列表单元格这样的对象相比，图标的尺寸太小，如果需要用户通过按住它来拖动整个单元格，那么交互成本的增加是不可避免的。此外，用户还会认为一个单元作为一个整体只会触发一个行为，即无论拖动小图标还是单元本身，都可以拖动。雅虎！Finace使用标准的iOS拖动图标，用户长按该图标可使单元可拖动。虽然列表单元本身是一个更大、更易操作、更直观的对象，但用户无法通过长按单元本身来达到触发拖动的目的。另外，我们还是要强调一下，拖拽图标真的和我们熟悉的汉堡包菜单图标太相似了：形状相同或者太相似的对象会触发完全不同的事件，容易造成混淆。尽管业界对汉堡包图标的争论越来越激烈，但越来越多的用户已经开始习惯“点击三行图标展开导航菜单”的模式。当他们发现自己行为的结果与他们习惯的和期望的不一致时，他们会感到沮丧和困惑。针对拖拽图标的一些易用性问题，我们建议：至少允许用户长按目标单元整体实现拖拽目标，而不是将交互区域限制在拖拽图标上。另一方面，对于汉堡菜单的图标，可以尝试表达得更清楚一些，比如在三行前面加上三个点，或者同时在图标旁边加上“菜单”的标题。总结背离“官方”和“通用”的设计模式总会让人感到不安，而与大家的模式保持一致也可以帮助用户降低学习成本。但是，无论您决定遵循什么设计指南，我们都建议您进行必要的可用性测试，以验证这些模式是否真正适用于您的产品和目标用户。至少在我们自己的研究中，我们已经看到足够多的可用性问题与本文中提到的4种常见模式相关，我们已经看到足够多的可用性问题让我们考虑它们。
