设计研究：为什么你不应该测试假设

为什么检验假说是错误的起点？

在我 最近的帖子 关于发现研究在节省时间和金钱方面的价值，我谈到了 可用性测试 让团队设计。我认为值得从实际会议和准备工作中的表现来扩展这个问题。通常情况下，"假设 "这个词会很快进入谈话。

如果你对可用性测试不熟悉，它涉及到让针对你的目标人群招募的参与者尝试你的界面任务，类似于他们在现实世界中的尝试。通过观察和调节，我们发现问题并提出改进建议。所有这些都是非常直接的。

我们测试的界面可以是一个真实的网站，虽然这往往是为了优化，或者更常见的是一个开发中的原型。与2000年时的线框图相比，现在的原型非常容易建立。有了一些可用的工具和一个有才华的设计团队，就可以开发出一个看起来和行为都像真的东西的原型。

在这里，"假设 "的作用在于原型的起源。因为它们相对来说比较容易建立，我看到越来越多的原型被送来进行可用性测试，这些原型的建立完全是团队头脑风暴活动的结果。下面是对这一过程的一个快速总结：

• 命题思路产生
• 团队集思广益，假设这个想法应该如何演变成一个设计。
• 原型已建成
• 进行可用性测试

这大致是这样的 敏捷团队 工作：开发MVP（最小可行产品），测试它，快速失败，然后再去。但如果你不是以敏捷的方式建立的，这种方法是有缺陷的。当然，客户会参与进来，但在这个过程中太晚了。

应研究的假说

原型应该被测试。假设应该被研究，而不是测试。如果你需要说服力，看看 设计委员会双钻框架.第一个阶段是 "发现"，他们将其定义为：

第一颗钻石帮助人们理解，而不是简单地假设，问题是什么。它涉及到与受问题影响的人交谈并花时间与他们相处。

可以说，测试假设是可以的，因为团队可以对结果持开放态度，并在必要时回头看。但即使是这样，这肯定是在浪费时间和金钱？

我还听到有人说，他们需要原型来向客户展示他们的想法是什么。这就忽略了发现研究的重点，即定义想法所要解决的问题空间。定义经验是以后的事。

如果你想充分利用你的预算和时间，并建立差异化的数字产品，提供卓越的用户体验，你需要让你的客户尽早参与到整个过程中。让他们参与到测试你的假设中来，通常会导致产品/服务不佳或过程更长、成本更高。