一定要避免关于人们可能会做什么的假设性问题。不要试图用“你会使用这个吗”或“你认为XXX有什么可能性”之类的问题来验证你未来的产品——这就是我们所说的引导目击者（证人），这会导致不可避免地使你提供的数据产生偏差，并浪费时间来构建错误的东西。

在这个阶段，你只需要观察用户已经在做什么，而不是他们理论上可能会做什么。

Rob分享了一个更新的模型:如果你不小心，用户就会对你“撒谎”

问错误的问题

记住错误的事情

根据你所听到的来“证明”，作出错误的决定

Rob和大多数其他研究人员建议，可以征得受访者的同意，记录这些采访并做有时间注释的比较，这将有助于他们准确记忆和整理行为模式，最终有助于定义产品、工程和设计团队可以放心构建的“要做的工作”。

第二步:评估用户测试

在了解了目标市场在生成研究中面临的问题后，你可能会有足够的信心去测试一个特定的产品解决方案，看看能否得到用户的重视。

这就是评估测试背后的概念。

在这个早期阶段，将产品解决方案的超轻量级实现放在目标用户面前，以了解他们的反应。虽然说原型产品越接近现实越好，但它不需要是一个功能齐全的产品:纸上的设计、原型、模型——任何类似的形式都可以。

你在这个阶段的目标是得到明确的定性信号，让用户:

理解建议的产品解决方案

明确表达对该产品作为当前优越解决方案的前景的兴奋

不幸的是，太多的产品团队加速了测试，或者直接跳过测试，直接进入工程和交付阶段。根据市场的复杂程度和你要解决的问题，这个阶段可能需要几个月甚至几年的时间。

这听起来可能让人泄气，而且很费时间，但我肯定的是:你的产品的成功将与在最初的客户发现阶段所完成的工作的质量成正比。

它值得去做，当然也值得把它做好。

第三步:可用性测试

即使你的团队创造出了人们想要的东西，如果客户不知道如何使用，那产品也是白搭。这就是产品团队在整个构建过程中，需要进行可用性测试的原因。

可用性测试的传统方法是建立一个测试环境，当用户浏览产品时，我们要观察具体情况。应当鼓励用户解释他们看到、想到和观察到的东西，同时还要提示用户，如果他们在使用产品时卡住了，接下来可能会考虑什么。在大多数情况下，产品的可用性问题变得不言而喻。

这里跟大家分享一个可用性测试面试的框架，可以询问参与者关于他们的:

期望（关于将要发生的事）

（对所发生的事情）反应

反思（关于1和2之间的差异）

这里有一种不太科学但更灵活的方法来识别较低的可用性问题。在进行测试时，让团队中的人指导新用户（最好是通过视频电话）设置产品并实时回答问题。这能够帮助团队成员理解用户被要求采取的步骤，以及这些步骤直接带来价值的方式。

这有助于团队形成对问题的共同理解，并找到真正有效的解决方案。

第四步:不断的探索

最好的产品团队永远不会停止开发新特性并进行评估测试的工作。即使他们最初的研究和测试变成了真正的产品，他们也知道创造一个永不停止学习和成长产品交付的重要性。

产品团队更常见的做法是不断地从现有用户那里学习和发现，而从完全没有“偏见”的非用户那里收集见解会很少很多。但能在现有的和新的两大群体之间取得平衡是理想的。新用户可以让你更好地了解最初的产品体验，而现有的“高级用户”可以在使用某个产品几周或几个月后，为你提供深度的见解。

优秀的产品团队能够与最活跃的用户建立长期的信任关系。你可以看到这些团队中的人员会建立不断反馈的会议，以获得洞察和倾听用户的关注和想法。这些采访的目的是找出哪些是令人愉快的，哪些是令人沮丧的，哪些是可行的，哪些是还有欠缺的。