做产品之前，先把问题问清楚

一个需求，可能有几种解释

“这里需要一个导出按钮。”这句话给出了一个方案，却还没有说明问题。

用户也许想把数据交给同事，也许需要定期归档，或者只是暂时无法在系统内完成分析。不同的目标，会导向不同的设计。

先理解用户想完成什么，才能判断这个按钮应该怎么做。

把观察和假设分开

记录需求时，可以用三句话整理：

1. 我们看到了什么：用户正在使用什么流程，在哪里遇到阻碍。
2. 我们认为原因是什么：当前的解释，以及还没有证实的部分。
3. 我们准备怎样验证：用什么方式观察变化，什么结果才算有帮助。

这样的记录能减少“大家都懂了”带来的误解。

让验证足够小

不一定要完整开发一个功能才能开始验证。一个可交互的页面、一份真实的操作记录，或者对现有流程的小幅调整，都可能提供有用的证据。

但要明确：原型被理解、代码构建通过、用户在真实环境完成任务，代表不同的阶段。

写下可判断的完成条件

“体验更好”很难验证。“用户能在文章列表中找到某个标签的全部文章”则具体得多。

完成条件可以包含：

• 在什么前提下进行操作。
• 用户执行什么动作。
• 页面应该给出什么结果。
• 遇到空数据或失败时如何处理。

让下一次决策有据可查

记录最终选择，也记录做出这个选择的原因。将来情况变化时，团队就能判断原来的前提是否还成立。

一个清楚的问题，往往比一份很长的功能列表更能推动事情向前。