做产品时，我越来越重视那些看起来不够宏大的问题。
一个流程里的重复输入，一次经常被忘记的提醒，一个需要切换三个工具才能完成的小任务。它们很具体，也因此容易验证。
先看见真实的场景
在讨论功能之前，先描述一个人如何完成一件事。
他从哪里开始？在哪一步犹豫？什么信息缺失？现有办法为什么不够好？
如果这些问题还无法回答，新增功能可能只是让界面变得热闹。
用最小的改变检验理解
第一版不必解决所有问题。它应该帮助我们判断：对这个场景的理解是否正确？
一个小工具、一段清晰的说明，甚至一次手工服务，都可能提供有用的反馈。
给反馈留一个位置
真正的改进，通常来自使用之后的观察。做出来只是开始，听见使用者的困惑，才有机会把它做对。