“该死，真希望我们一年前就这么做了。“这是我在为他们的第一个用户研究项目建立了一个团队后立马听到的。了解用户需要的过程是如此强大，希望他们能够回到过去，重新创建他们的产品和服务，这一次则是想获得他们刚刚获得的见解。
当然，你不能回到过去(至少现在是这样)，但是你可以马上开始自己的用户研究程序。一旦你决定沿着这条路走下去，你首先会意识到你所选择的研究方法是多么丰富：可用性审计、启发式评估、可用性测试、实地研究——你会先选择哪一个?哪种方法最有效?
1.可用性审计
可用性审计(也称为可用性走查)是一种简单的基于任务的技术，但它们的有效性最低。当你执行审计时，团队中的某个人会坐下来，扮演用户的角色，处理与设计相关的各种任务和活动，寻找设计可能会挫败或延迟用户的地方。
假设你正在为医疗专业人员构建一个系统，以便为患者和护理人员定位和共享有关癌症治疗和方案的信息。团队成员可以扮演护士或顾问的角色，查找正确的信息并假装将其提供给患者的护理人员。在此过程中，团队成员将确定难以找到或看到信息的地方，以及难以共享信息的地方。
虽然在界面中生成更改事项列表是一种很好的技术，但问题是要知道这些更改实际上能否会改善实际用户的设计体验。尽管团队成员扮演的是用户的角色，但他们所做的是他们认为用户会用产品做的事情。
如果团队成员不是训练有素的、经常从事此类工作医疗专业人员，他们如何知道什么会真正让人沮丧?把信息传递给病人有很多微妙之处。如果没有这样做的技能和实践，他们不太可能抓住关键问题。
可用性审计可能是最省钱的用户研究形式。但它缺少一个关键的组成部分:用户。它的成功是基于团队成员真正了解用户世界的来龙去脉。如果团队正在构建一个他们自己会使用的工具，例如软件开发的项目管理工具，那么可用性审计将更有可能产生一个高质量的更改事项列表。当你拥有一个不基于用户实际行为的更改事项列表时，你就承担了投资于实际上不会增强任何东西的增强功能的风险。事实上，如果你根本不做任何更改，那么你将面临使设计变得更糟的巨大风险。(你有没有遇到过自己喜欢的某个软件更新后，软件变得更糟的情况?)
这就是为什么我们有其他的研究方法。
2.启发式评估
启发法是一种经验法则，通常基于某些人所做的一些研究。启发式评估采用一组启发法并查看设计是否与之匹配。
例如，你可能会有这样的启发，“系统反馈应该传达设计的当前状态。”你可以仔细检查你的设计，看看是否存在不清楚系统状态的情况，然后提出修改建议。
启发式评估比可用性审计更好，因为很有希望有用户参与启发式规则的创建。然而，就像可用性审计一样，关于知道在哪里寻找问题并识别它们，也有很多预设。有些人受益于一套经过许多类似项目仔细调整的启发式方法。例如，一家专门研究高等教育网站的设计公司收集了一套启发法，这套启发法被证明适用于大多数大学网站。他们可以使用这些规则来快速地发现设计中的问题和缺陷。
然而，许多人试图使用一般的启发法，最流行的是Molich和Nielsen的10种针对计算机系统的启发法，它们最初是在20世纪80年代提出的。虽然它们可以列出需要更改的事项(很容易就能说出某些事项的错误)，就像可用性审计那样，但是仍然不知道这些更改是否会改进设计。事实上，研究表明，对于那些没有观察过真实用户的人来说，用启发式评估使界面变得更糟糕的几率相当高。这就是为什么我们喜欢直接涉及真实用户的研究方法。
3.寻宝游戏可用性测试
可用性测试是一种比我目前列出的方法更加复杂的用户研究，但它仍然很简单。最简单的形式是，你坐在用户旁边，看着他们使用你的设计。就像生活中的许多事情一样，做这件事也有很多种方式。
其中一种就是我们所说的“寻宝游戏”可用性测试，因为我们要求每个参与者做一个特定的、预先确定的任务，就像你在“寻宝游戏”中所做的那样。我们可能会要求他们“寻找胰腺癌的手术方案”或“与患者的护理人员分享惠普尔手术的好处和风险”。“当他们执行这些任务时，我们可以知道设计在哪里帮助了他们，在哪里阻碍了他们。”
我们可以记录每一个设计减慢用户或挫败他们的地方，还可以记录任何用户走向错误的方向或犯错误的地方。从这些信息中，我们可以得出一个需要更改的事项列表。有了足够的用户和足够的任务，我们可以在设计中涵盖很多领域。
这比可用性审计或启发式评估更好，因为我们看到真实的用户与设计交互。因为他们对设计的创造不是很熟悉，你基本上是通过他们的眼睛看到你创造的东西。他们可能会对某个术语或命令感到困扰，因为它与他们的经验不匹配。然而，寻宝游戏测试仍然要求我们知道应该让用户做什么任务。我们根据自己对用户行为和需求的理解来创建这些测试。这意味着，如果我们对用户和他们的工作不是很熟悉，它就会和可用性审计或启发式评估一样有缺陷。为了弥补这一点，我们创建了一种不同的可用性测试-基于访谈的可用性测试。
4.基于访谈的可用性测试
与寻宝游戏测试一样，我们要求用户完成一系列任务。但是，与寻宝游戏任务不同的是，我们不会从预先确定的任务开始。相反，在基于访谈的测试中，我们所做的事情正如其名:我们采访我们的参与者。例如，我们可以与癌症顾问坐下来，请他们描述一下他们最后一次需要为一个家庭提供治疗方案的情况。当他们谈话时，我们会记录下他们所描述的活动，情况的细节，以及他们使用的特定词汇。
结合所有这些，我们接着会要求用户做一些与这个设计非常类似的事情。我们用他们自己的话语(而不是我们使用的行话)来做出说明，用他们描述的情况作为背景。当我们进行基于访谈的测试时，我们经常会在我们的设计中发现以前没有见过的巨大漏洞。因为用户描述的场景更加真实，我们可以看到我们的设计在这个真实环境中无法工作的地方。现在，我们越来越接近于找到真正能够改进设计的问题和解决方案。
5.实地研究
虽然基于访谈的可用性测试让我们更接近用户的实际行为和想法，但这种技术仍然受到在用户体验的真实环境之外进行操作的影响。这就是为什么实地研究是开始用户研究最有效的方法。
实地研究将我们带入用户自己的环境。我们看他们做什么，怎么做，在哪里做。我们可以看到他们挂在墙上的东西，他们与同事或家人的互动，以及存在于每个人生活中的自然混乱。例如，我们可以看到当人们被现实生活中的活动打断时会发生什么，比如一个同事问了一个需要立即回答的问题。我们可以看到，我们所创建的设计本身并不适合这种中断，它们最终会做一些耗时的事情。
6.我们如何与一个团队开始用户研究
我们的首选永远是实地研究，这是最丰富，最有影响力的方法。当你带领一个团队(尤其是涉众团队)在他们自己的环境中与真正的用户见面时，你将看到设计中最大的变化。这就是我们的出发点。
有趣的是，虽然实地研究看起来更贵，但其实它并不比运行良好的可用性测试更贵。然而，如果我们不能做到实地研究，我们就选择基于面试的任务。在最初的研究中，我们要远离寻宝游戏可用性测试，直到我们真正确定那些最重要的任务。在项目的后期，当我们测试受早期研究启发的新特性的细节时，我们才使用寻宝测试。
尽量不要使用启发式评估，也不要做可用性审计。我们承担不起与之相关的风险，它们很有吸引力，因为它们看起来很容易，你不会意识到它们把项目引向了错误的道路，直到为时已晚。没有理由去坐等用户调查的时机。你将如何行动起来呢?
作者Jared M. Spool
原文链接：https://articles.uie.com/starting_user_research/
翻译：马克笔设计留学
