少量参与者参与可用性测试是一种非常有效的改进界面的方法。通过观察真实的人尝试使用一个设计，我们从用户的角度来看待界面。由于普通用户缺乏系统“应该”如何工作的内部知识，他们经常遇到设计创造者没有预见到的问题。
发现这些意想不到的问题是进行可用性测试的关键。但这些问题令人惊讶，而不是利益相关者预期的问题，这一事实常常导致人们怀疑所观察到的问题是否真正代表了“真实”用户将遇到的问题。
那些怀疑是否应该信任可用性测试结果的利益相关者经常断言测试参与者没有代表性，或者没有足够的测试参与者认真对待测试结果。
当您遇到这些反对意见时，这里有一些技巧可以帮助团队理解为什么他们应该认真对待定性可用性测试。在最简单的情况下，怀疑可能仅仅是缺乏方法论经验的结果，可以通过清楚地解释方法和以令人信服的形式传达结果来成功解决。
为利益相关者提供积极的解释
首先也是最重要的是，一定要做到在进行可用性课程之前，解释你的研究方法. 提前描述这个过程比在人们开始怀疑后试图为它辩护更有说服力。准备您自己的解释，或分享视频和文章，包括什么是可用性测试和为什么只需要几个参与者. 事先承认这种方法的局限性：提到一些问题，比如人们是否相信某个品牌是可靠的，仅仅与5个用户交谈是无法准确回答的。但是可用性测试不是关于信念或偏好，而是关于发现普通用户在使用特定设计完成特定任务的特定环境中的行为。
通过解释:
“我们可能会看到人们遇到我们没有预料到的问题，因为我们对设计的熟悉使我们很难发现一些问题。”
“由于所有用户都缺乏我们团队对设计的内部了解，这种视角差异所导致的问题很可能会影响到许多用户，并在最初的几次测试中就会显现出来。”
“我们不会试图通过与大量用户重复测试来证明每个问题到底有多糟糕，而是专注于快速发现常见问题，这样我们就可以修复它们并改进设计。”
在早期计划阶段，与团队成员分享这个环境，特别是如果他们不熟悉可用性测试的话。即使是熟悉可用性测试的团队也能从这一提醒中受益他们不像他们的用户。
听天由命
有时候，利益相关者会忽略测试结果，因为他们认为测试结果只不过是另一种观点——撰写报告的研究人员的观点。
可用性测试的全部目的是听取用户的意见。来自熟练研究人员的见解和分析可以为报告增加巨大价值，但始终确保用户的直接反馈，用他们自己的话来说，是响亮而清晰的。你可以显著地引用研究参与者的直接引语；视频剪辑甚至更具吸引力（如果您能够录制会话并有时间编辑片段）。
最有说服力的方法是安排团队实际直接观察可用性测试会议. 这种做法让他们自己看到测试参与者是真实的人，并对用户与系统的斗争产生同理心。当团队成员直接观察会话时，他们还可以看到研究人员没有领导或影响用户。
解决参与者不具有代表性的异议
为了避免反对意见，即测试参与者不能代表“真正”的用户，请确保与真正具有代表性的用户一起进行测试——并提前与涉众分享您是如何招募他们的。
与真实用户进行测试
如果您正在测试一个实时的网站或应用程序，那么招聘实际的访问者或用户是找到具有代表性的参与者的有效方法。当今复杂的分析工具(例如HotJar或Ethnio)可以很容易地锁定特定类型的用户，比如正在使用网站特定部分或应用程序特定功能的用户。过去或潜在客户的列表是真实测试参与者的另一个重要来源。
在招聘之前买入用户资料
如果您不能直接从实际系统中招募参与者，您可能需要这样做从其他渠道招募参与者．但是，你仍然可以通过仔细定义目标受众的重要特征来确保参与者具有代表性。如果你有角色，参考它们。询问将收到研究结果的利益相关者，让他们提供关于目标受众是谁的意见。然后筛选潜在的测试参与者，通过问他们一些问题，选择性地识别出具有目标用户所有基本特征的人。
无论您使用哪种方法来寻找参与者，都要向您的利益相关方描述每一步:在研究的计划阶段，通过将参与者概况分发给直接观察测试会议的利益相关方，并作为最终报告的一部分。
反对意见认为没有足够的参与者来证明一个问题
对可用性测试方法的前瞻性解释有助于在测试结果中建立可信性和信心。但仍有一些人担心，少数人遇到问题并不一定意味着这是一个普遍的问题——尤其是在研究中只有一个参与者遇到问题的情况下。这个参与者可能是离群值这些人有着许多其他用户所没有的不同寻常的期望或习惯。
事实是，看到至少两个人在同一个问题上挣扎确实会激发人们对这个问题的正确性的更多信心。但这并不意味着你应该忽略只有一个参与者经历过的问题。(从统计学角度来看，5分中的1分和5分中的2分之间的置信区间没有太大的差异。)相反,收集更多信息来更好地解释单个实例的上下文．
分析来自单个用户的发现
当只有一个测试参与者遇到问题时，首先考虑以下问题:
- 修理它要花多少钱?如果有一个简单的解决方案，那么仅仅解决它可能比花时间记录问题成本更低，更不用说花时间在团队会议上没完没了地讨论这个问题了。（当您已经计划测试下一个设计迭代时，此选项最为有效，您可以检查“修复”是否引入任何新问题。）
- 这个问题对那个人来说有多严重?严重的问题通常是那些阻止用户完成任务，造成巨大挫折，或直接与关键设计目标相关的问题。如果其中任何一个都是正确的，但它不是一个容易解决的问题，那么在提交设计更改之前，需要进行进一步的调查。
收集更多关于单参与者可用性调查结果的信息并不一定需要更多的用户测试。首先要考虑的是竞争分析:如果对竞争对手的设计进行审查后发现，大多数设计都没有这个问题，那么为了满足用户的期望，修复它可能就很重要了。
检查独立数据源以估计频率
使用情况分析或支持请求等现有数据源非常适合于估计问题的频率和潜在影响。
例如，审查支持请求，并比较其中有多少与“异常值”问题有关，与测试中观察到的其他问题相比较。这些信息可以提供真实流行率的相对估计。
如果您没有关于有多少用户遇到问题的具体数据，那么您可能能够确定与该功能交互的用户比例是多少以及这些用户对组织目标的价值。例如，假设一项研究中的一名参与者误解了排序功能的工作原理，因此她无法找到产品。如果你为排序功能设置了带有事件跟踪的分析功能，那么快速检查该数据就可以揭示实际客户使用排序功能的比例。(因为并非所有用户都会遇到这个问题，所以受影响的用户比例要比使用该功能的用户比例低一些。)
将测试观察结果与可用性理论进行比较
考虑您的单用户可用性问题的程度可以通过现有的关于用户行为的知识以及使用户界面变得容易或难以使用的知识来解释。例如，检查10个可用性启发式几十年来已经证明了自己。或者看看可用性指南出版基于大量的用户研究和广泛的其他设计。虽然这种宽泛的用户体验理论并没有专门针对你的个人设计，但你可以从之前的研究中归纳出来。
如果您在单个测试参与者身上观察到的问题可以很容易地用现有的可用性理论来解释，那么您就有更充分的理由相信这是一个真正的可用性问题。另一方面，如果该理论预测您的设计应该是简单的，并且不会造成问题，那么您不幸的测试参与者可能确实是一个离群者，这个问题不太可能以任何频率重复。
不幸的是，用户体验理论的状态是这样的，它不能以这样或那样的方式最终决定问题。人类行为是如此多变，设计的可用性进一步依赖于无数的小细节，我们永远无法100%确定某件事是好是坏。但这并不意味着我们对UX一无所知．对于某些用户类别和任务类型来说，什么让用户界面容易或困难，我们从几十年前的研究中获得了大量的概念性见解，你可以利用这些知识来解释个人经验观察。
此外，将您的测试观察结果与外部验证的UX知识联系起来，可以是向您的团队解释您的发现的有用方法。要清楚的是，不仅仅是你认为设计有问题，很多人在测试其他设计时也发现了类似的问题。给这个问题起个名字。这些策略有助于你对“小样”提出异议。
进行定量可用性测试
对于无法与现有数据源进行关联的潜在严重问题，仅使用5个用户进行测试可能不足以确切地提出行动方案。在这个例子中定量可用性研究可以提供更多的信心，在多大比例的用户可能遇到问题。如果这个问题可以在一个不加节制的远程测试，从20个用户所需的精确定量研究是合理负担得起的。
如果一个组织对小团体的定性方法有根深蒂固的怀疑，定量研究也可能是值得的。用更大的用户样本测量定性结果的发生率可以证明特定组织的设计和用户中定性方法的可靠性。利用定性研究的投资，在组织内彻底记录和宣传该项目，特别注意定性和定量结果之间的对应关系。
结论
如果团队不相信这些发现，因此不采取任何措施解决问题，那么发现设计问题就毫无意义。有效地解决对可用性测试结果的怀疑是用户研究的一个重要部分，并且应该从开始到结束纳入每一个研究计划。
分享这篇文章: