混淆混淆_混淆是可用性缺陷

混淆混淆

作为软件工程师，您应该始终在寻找下一个缺陷的位置，或者至少寻找一些错误的线索。 问题在于，大多数开发人员都经过培训，等待质量检查团队的反馈。 在许多情况下，质量检查团队都遵循脚本或接受过有关如何使用该系统的培训，因此，在熟悉度方面有些线索会丢失。

迈克尔·博尔顿（Michael Bolton）有一篇有趣的文章，关于作为神谕的混乱 ：

詹姆斯凝视着他的眼镜。 他说：“当您感到困惑时 ，这表明发生了一些令人困惑的事情。 我给您一个令人困惑的产品进行测试。 混淆可能不会很有趣，但是当您处理令人困惑的产品时，这是自然的结果。” 詹姆斯默契地建议将乔恩的困惑作为预言 ，这是我们认识到问题的启发式原则或机制。

当质量检查小组感到困惑时，这表明了潜在的问题，应将其用作启发式方法。 混乱可能来自几个方面。 首先，测试脚本可能与用户界面不同步，这种方式使得测试人员应该如何进行尚不明显。 在整个开发生命周期中不断发展的任何应用程序中都可能发生这种情况。 其次，您可能会让未经培训的人员成为测试人员。 通过提供有关如何使用该应用程序的适当信息，可以快速纠正此问题。 它还可能指向不完整的测试脚本，这意味着新手无法在没有其他指令的情况下执行测试脚本。

质量检查团队可能感到困惑的另一个原因是应用程序令人困惑。 这不是一个好兆头，应视为对开发团队的警告。 应用程序很可能存在可用性缺陷。 对于某些团队来说，不存在可用性缺陷，并且可用性问题已添加到要做的事情中。 在开发Web应用程序时，这是一个大错误。 大约一年前， 我写了关于Krug的可用性规则 ：

克鲁格的前两个可用性规则非常相关：

1. 不要让我思考–在人类可能的范围内，当我查看网页时，它应该是不言而喻的，显而易见的，不言自明的。
2. 只要每次点击都是无意识的明确选择，我就不必单击多少次。

我喜欢“不要让我思考”的规则。 如果您牢记此规则设计应用程序，则将克服大多数可用性问题。 但是，如果您是一家初创公司并且正在为庞大的用户群开发产品，那么您可能会有更多的担忧。 马克·埃文斯（ Mark Evans ）最近写了一个关于“我明白了”的经验法则 ：

但是，如果您撇开企业家的热情，一家初创公司的成功前景取决于一个引人注目的构想，以及重要的是，能否Swift吸引潜在用户说“是的，我理解”。 这意味着要明确服务或产品的功能以及所提供的价值主张/好处。

产品/服务需要满足需求或说服用户满足他们不知道的需求。 吸引用户加入必须对用户友好且高效。 产品/服务必须令人愉悦。

如果您遵循这些基本原则，则您的产品应该不会引起混淆。 我坚信为用户简化事情，因为这意味着他们将喜欢（或至少不讨厌）使用该系统。 这显然是一件好事，但更重要的是，用户将寻找其他方式来使用您的应用程序。

那么，为什么应该在“混乱的”应用程序中跟踪可用性缺陷？ 如果应用程序令人困惑，则意味着它将很难使用。 当应用程序难以使用时，人们会停止使用它，因为他们看不到使用系统的好处。

可用性也很难定义，但是如果您查看Krug的规则，您将发现用户不必寻找正确的方法，这应该是显而易见的。 但是，生产之前呢？ 您在系统上没有典型的用户，那么如何确定可用性？ 我看到的一件事是，测试脚本的长度可以很好地触发某些困难的事情。

假设您已完成手动测试。 忽略测试用例设置说明，测试一项功能需要多少步骤？ 这与启发式的点击次数相似，但它是用户完成任务必须执行的操作数。 您可以说数字大约是7，但这并不完全有用。 我使用“为什么”作为选择指标。 如果您问“为什么需要完成此步骤？” 并且没有明显或可定义的原因，那么您可能正在为任务引入不必要的步骤。 如果您可以消除这些问题，则您的应用程序可用性应该会提高。

为了真正简化您的应用程序，请确保您的质量检查团队在流程开始时就开始质疑。 有人编写了测试脚本，它可能是QA测试人员。 开发人员和测试人员应仔细阅读测试脚本，并为每个步骤询问“为什么”。 通过QA测试后，这将主动消除计划中的任何绊脚石，并拥有更加实用的系统。

您是否有任何提示或技巧来提高可用性？

参考： Regular Geek博客上我们的JCG合作伙伴 Rob Diana的混淆 ： 可用性缺陷 。

翻译自: https://www.javacodegeeks.com/2012/07/confusion-as-usability-defect.html

混淆混淆