篇一 应用设计中常犯的十大错误
By Jakbob and Page Laubheimer on Feburary 17,2019
译者：yanni
概述：随着用户界面能够引导并支持用户完成整个工作流程，应用的可用性在不断增强。
设计复杂应用是一个具有挑战的项目。构建既能够充分支持复杂任务，又能够直观地让人理解如何操作的应用是一个巨大的挑战。为应用设计中发生的普遍问题提出普适性的建议是很困难的，因为我们注意到其中的很多问题都有各自的领域特性，从我们这篇文章发布的第一版到今天这版的11年间一直如此。
因此，我们一开始的建议就是针对目标用户去做研究。
开始可以通过任务分析和领域研究去理解用户的需求和工作流程
利用低保真原型草拟出应用的基础结构和功能，不要在那些你了解用户以后会修改和放弃的想法上投入过多的资源。
迭代优化后针对少量用户对每次的改动进行测试。迭代次数越多，你的应用越好。
尽管大多数应用在可用性的问题上都有各自的领域特性，以下仍有十个我们经常在各行业的应用中看到的错误。其中的五个错误（1，2，3，4，6）在我们第一版的文章中也有包含，由此可见可用性的指导原则是多么长效。第一版文章中的十个指导原则依然是正确的，不过其中针对的五个错误现在已经较少出现了，它们被另五个错误所替代（5，7，8，9，10）。
下面是我们当前列出的应用设计中糟糕又常见的十大错误，希望我们在另一个11年后写这篇文章的下一版时，它们其中的大部分已经很少见了。
1. 糟糕的反馈
其中一个提高应用可用性最基本的原则就是提供清晰的反馈：
展示用户系统的当前状态
告诉用户他们的动作和命令有什么含义
告诉用户正在发生什么
应用总是沉默着让用户去猜测，而用户常常猜错。
好的反馈告诉用户很多的事情——比如，用户可点的按钮是不是表明了它们作为按键能够点击的特点？点击以后系统会做什么？按钮当前是被选择状态还是激活状态？
其中一个体现出反馈重要性的场景就是应用进入编辑模式，修改现有信息。让用户清楚地理解当前是编辑状态是很重要的，此时应用将会区别修改区域与其他地方。比如，一些应用会合并一行或者一列的可编辑数据，另一些应用可能会使整个表都变成可编辑状态。当然，清晰的反馈能够告诉用户什么区域是可编辑的；好的反馈也能通过各种方式体现，从使用不同的背景来表明当前的可编辑区域到通过编辑的按钮去清晰地展示出它们的功能。
在编辑模式时，这个来自 Telerik.com的应用会给当前表格中编辑状态的一行增加一个灰色的背景，还会改变其中的元素，使它们看起来更像表单字段，同时改变编辑和删除按钮为更新和取消，用不同的外观来表现。在反馈中改变按钮的位置和颜色是特别重要的一个信号，它降低了用户在编辑以后没有注意或者没有依赖肌肉记忆的情况下点错按钮的可能性。这种反馈清楚地暗示了系统正在发生什么以及如何回应用户的输入。
1.a．没有进度提示
缺乏反馈的其中一个表现是当系统需要很长时间去完成一个动作时没有提示用户，这时用户往往会认为应用中断了，然后开始点击其他的目标。
如果你不能够满足最优的响应时间，那么，让用户通过进度指示器了解到正在发生什么：
如果一个命令需要2-10s的时间，展示类似“spinner”的等待动画。这种进度指示器能让用户耐心等待，使他们不会去点击其他的任何东西直到响应完成。
l如果命令需要时间超过10s，放一个明确的进度指示条作为一个更好的百分比指示器。（除非你真的不能预测这个操作完成前还需要多少工作）
2. 不一致
请记住双D原则：differences are difficult(不同就是困难)。用户对一些事物将会如何表现或者去哪里可以找到它们都有自己的预期，背离这些期待的话就会导致用户的困惑与挫折感，当人们尝试去解开那些困惑时也会增加认知负担，人类的大脑总是希望一致。
以下是一些很容易在复杂应用中出现，甚至导致熟练用户都会产生困惑的不一致问题：
针对相同动作的不同语言或命令
在不同的地方放置相同功能的控件
把相似的控件（从用户角度看）放在相近的地方（比如，一个靠近工具栏，第二个靠近菜单栏，第三个在深层次的配置目录下）
相似工作流模式要求用户与界面中完全不同的几部分交互
合法的输入数据有不一致的规则：有时候允许一个入口，有些时候又被标为无效，而且没有任何的反馈来说明原因
l有时候能够找到一个功能，有时候又因为一些莫名其妙的原因找不到了
UI因素和控件经常移动也不利于空间的一致性
在我们研究中，一个有着多年使用AutoCAD经验的建筑师，一直想要弄明白到底什么时候可以或者不可以把不同的浮动面板固定到屏幕的一侧。在一段时间内，她试了很多次让一个浮动面板固定在左侧都没有成功，原因是隐藏的参数设置使得这个特殊的面板不能够被固定，不过这个限制条件并没有清晰地告知用户。隐藏的参数设置希望帮助高级用户自定义界面以便更好地使用，不过由于糟糕的反馈，我们研究的参与者并没有明白为什么一些时候能够固定面板有时候又不能。这种不一致性是用户挫折感的主要来源，即使是资深用户也一样。
AutoCAD不能让用户始终在屏幕一侧固定面板。即使是资深用户也不能够确定为什么这一功能只针对部分面板有用。（原因是一个隐藏的参数被设置成关闭其中的一个面板）
3. 糟糕的错误提示
错误提示是反馈的一种特殊形式：它们告诉用户有东西出现了问题。我们已经知道错误提示的指导原则几乎有30年了，但有些应用仍然在违背它们。
最常见的违背原则的一个实例就是错误信息只是简单地说发生了错误，没有原因的解释以及如何去解决这个问题。这种信息让用户陷入困境。
几年来这个问题越来越严重，主要归咎于网络应用：用户常看到“出了一些问题，再试一次”这种错误信息，没有错误的成因细节或者如何才能修复。至少本地的桌面应用过去也还常常告诉人们是什么问题（但是经常使用用户听不懂的术语）
从 Quicken（左上）、Dropbox(右上)、IBM Verse( 下方 )收集的关于一些运行错误的模糊提示：他们都没有描述问题的本质以及如何避免此类问题或者在此过程中用户之前的工作是否会遗失。
错误消息的通知不仅帮助用户修复当前的问题，还教育了用户。尽管用户可能不会花时间阅读和了解你应用的特点，但是当你对错误的解释足够清楚时，他们会为了解决错误而努力理解错误发生的情境。。
4. 没有默认值
默认值在许多方面帮助了用户，它最重要的作用体现在：
当默认设置令人满意时，可以加速用户的交互速度，避免其去设定特定的值
通过提供问题的一种正确答案来指导用户
- 如果初级用户不知道做什么的话，他们可以接受默认设置从而得到安全的、常见的输出。
默认值能提高用户重复性工作的效率，比如在相同的表单中输入多次。在表单的一些区域识别出关键值能提高产出，减少用户的挫败感。你的一些分析数据更够帮你了解是否在特定区域有最常用的选项。
默认值对下拉菜单来说特别有用。很多应用提供了“选择一个”（在没有选择的状态下）作为默认值，强迫每个用户与下拉菜单交互，选择一个值。如果你先前已有了一个选择（理想的常用值），至少有一些用户根本不需要每次都与下拉菜单交互。
在数字表单中，如果用户需要的值偏离默认值很小（比如数量字段），你可以让用户通过步进器来调整数值而不需要输入（不过仍要允许用户在需要的时候输入不同的值）。步进器有两个优点：他们在减少用户交互的成本同时为仍在探索系统的新用户提供了一个初始数值。
Mint,个人理财应用，有一个帮助用户寻找信用卡的功能。他们自动填入了用户每月花费的平均数值，这样用户可以方便地修正这个数值，不管是通过键入还是使用增加和减少按钮。
5. 非标志性图标
很少有图标会引人注目，因为大多数的用户都能够立刻理解它们。即使是那些几乎通用的图标（比如汉堡包菜单），用户也不熟悉，这正是交互设计师所希望的。如果你的应用有与众不同的图标是很糟糕的，用户们很有可能不理解这些特别的图标有什么含义。记住雅各布定律：“用户花了大部分时间在其他的网站上”。这意味着除非图标旁边有文本解释，不然很难或不可能被用户理解。
包含文本标签的成队图标有以下四个优点：
1、 它扩大了目标对象的区域（根据菲茨定律，这减少了用户找到控件的时长）
2、 它减少了识别命令的时间：两个记忆点比一个好（图标和文本）
3、 有助于促进用户对界面的理解，联系之前的操作。（通过建立相同命令的多种联系点）
4、 它能够帮助用户从视觉上区别相邻放置的几个命令。
在最近的研究中，我们从各种桌面图标中选择了几个没有标志性的：它们都是没有特色的图标，不能够清晰地暗示其目的。你能够猜出它们代表什么吗？我们研究的参与者不能。
6. 难以获取的目标
在人机交互中，任何可以被点击或者按键的东西我们都叫做目标：所有活动的UI元素都是目标。用户如果想获取目标，他们一定要（1）先识别出目标（2）可靠地点击。现代应用的界面都可能在这两方面产生问题。
6.a.弱识别
“可见性”意味着你可以对这个对象做什么。比如说，一个复选框能够选择或者取消，一个滚动条能够上下移动。标志物是视觉元素，可以帮助你在使用对象前仅通过看就能理解它们作用。（如果它是物理设备而不是UI元素的话，你也可以在使用前通过看去理解它们的作用）。这些概念在唐.诺伊曼的“日常事物的设计”一书中被提出。
标志物在UI设计中尤其重要，因为所有的屏幕像素都可以被点击，即使你点击以后什么都不会发生。屏幕上有太多的视觉元素导致用户不会像玩扫雷游戏一样都去点击一遍看能不能找到一些有所反应的东西。（例外：小孩子有时候喜欢通过到处点击去探索屏幕）。
在现代应用中，一个最糟糕的设计是超扁平。很多扁平化设计的目标识别性很差：人们不能够轻易辨别是文本还是按钮，因为它们不像传统的3D设计那样有提示性。
弱识别性的通病：
用户说：“我在这要做什么”
用户不能找到需要的功能
尝试用较大的文本来解决上面的两个问题。（更糟糕的是冗杂的、多段的提示在你开始执行几个动作后就会消失）
6.b.细小的点击对象
这里另一个相关的问题是点击的对象太小以至于用户总是错点到有效区域的外面。即使用户最开始就正确地找到了标志物，如果他们点击以后什么都没有发生的话用户就会改变想法，认为这个标志物是无用的。（一些细小的点击区域对于资深用户以及很不擅长的用户来说是特别大的问题。
7. 模态的过度使用
很多应用使用模态对话框来表现数据的交互——修改一个存在的条目，增加一个新条目或者删除，甚至阅读关于该条目额外的详细信息。模态对话框出现在当前屏幕的最顶层，此时背景通常变暗（假设了较暗的环境可以避免干扰，从而使用户专注于当前的任务）。不幸的是，因为这种设计覆盖了一些用户可能在填写表单时想要参考的信息，反而减少了曝光给用户的内容。（注意，即使被覆盖的内容没有包含用户在编辑时需要的信息，用户也倾向于利用之前的工作成果，通过复制粘贴之前输入的内容，甚至是参考其他的模板来思考如何完成当前的任务。）
在 Airtable中，编辑表格中的一行会打开一个模态对话框，从而覆盖表格中的大部分信息，妨碍用户去参考它们。
8. 无意义的信息
较长的一串字母和数字，比如在应用数据库中自动生成的经常用来唯一识别某个项目的ID，这些字符串对于用户来说完全没用，不过它们经常特别显眼地展示在表格的首列，强迫用户从一列扫描搜寻他们关注的信息时看到它们。当这些无意义的索引对于后端很重要时，它们不应该放在用户关注信息的首要位置，特别是在高信息密度的屏幕中，提供一些人们易懂的信息作为主要锚点，把这些ID放到更不重要的位置上。
不同寻常的编码信息经常出现在医疗应用、CRM系统（在每一次用户在与客户的销售活动中，他们都经常不得不去选择该系统中的一个编码）、会计软件和企业应用中。在这些所有的应用中，为了简洁，那些对人们有意义的信息全部被概括成简短的编码。一个简洁的编码与整个句子相比或许能够填入很小的区域，不过给用户增加了更多的认知负担。用户将需要自己翻译理解这些代码信息，而且我们的短期记忆很快就会消失。即使是经常接受训练的专家也不能记住每个可能的代码，这种心理的翻译也会消耗他们过多的精力。
这张表格的第一列有无意义的ID信息,网络和位置代码也包含有编译的信息，它们更简洁地呈现了复杂的信息，地址名是其中人们唯一能看懂的一列，为了解释给其他人，人们不得不依靠自己的记忆或者一系列的代码键。
9. 垃圾抽屉般的菜单
如果你的应用有上百甚至上千的功能，你就不得不为那些功能在某个地方放置控件，而且，你需要组织排列优先级，这样用户才能够轻易快速地找到其中一些重要的功能。这样做的结果常常是一个过载的菜单：最常用的几个动作呈现在工具栏中，最后的一项被标为“更多”，或者“其他工具”，最糟糕的是…保留其他所有不合适的动作。
这些菜单标签的信息识别度很低，无异于一个装满垃圾的抽屉：一个装着你所有无法归类但又不想扔的东西的地方。这些情况经常发生，因为团队总有一系列需要但不知道如何放置的功能，或者因为一些老的应用无法移除一些陈旧的、很少使用的功能。过载菜单的问题在于没有其他的任何人知道这里可能有什么，就像你房子里的垃圾抽屉一样。换句话说，这降低了功能被发现的可能性，因为大多数的用户没有理由在这些菜单中搜寻。
Airtable:就像垃圾抽屉菜单…信息识别性很差。用户很难猜测这个菜单中到底会有什么。
10. 接近的破坏性和确认性动作
把一些动作类似“保存”放置在一些破坏性的动作旁边（类似“丢弃”）是经常看到的一个设计，这会导致一些用户的悲剧。从逻辑上看，这样放置是有意义的（比如,保存和删除放在一起，因为它们决定了这一项的结果），但这也很容易导致用户点击错误的按钮，特别是当用户很着急地完成一些重复性的动作时，或者当他们想不好选什么时。这种无意识地错点另一个按钮的行为叫做“滑倒”。
Veeam,一个企业的备份软件，在开始新的备份工作时，提供了多步骤向导。在我们的研究中，一个用户几乎要花上20分钟才能通过这个流程，还差点在最后的页面点击了取消而非完成，因为两个按钮放置地很接近。如果这个用户点击了取消，20分钟的工作就白做了。
Microsoft Outlook将“跟踪旗帜”的图标按钮放置在存档和删除图标右边，这些图标服务对立的用户目标，但是它们很小，放置的位置也很接近，所以当用户快速操作时很容易点错。
11. 总结
应用都有各自很强的领域特性，所以针对某个行业的一个可用、高效、令人愉悦的应用对其其他行业来说可能会成为一个十足的灾难。创造一个可用的应用需要你对自己的用户做调研，了解他们的工作流程和需要的功能，以及心理模型和期待。
然而，以上列出的十个应用设计中的错误是我们在跨行业的研究中观察到的，包括创意行业，金融行业，事业单位、医疗保健业、工程业等等。
文章来源：https://www.nngroup.com/articles/top-10-application-design-mistakes/
