用户的界面是产品，团队的界面是什么？

有一次，一个同事拿着一份需求来找我。他问：“这里到底是什么意思？”我下意识回答：“不是已经写了吗？”他说：“我知道写了，但它到底是什么意思？”

我重新打开那份需求。内容一点也不少：背景、流程、规则、备注，甚至还有几轮讨论留下的记录。可越往下看，越发现他说得没错。它告诉别人要做什么，却没有告诉别人为什么要做；它非常完整地保存了文字，也非常克制地保留了理解。

团队每天接触最多的其实不是产品，真正陪伴他们一整天的是需求。他们通过需求认识产品、理解产品，也通过需求争论产品。很多人在产品上线以前，已经根据那几页文字在脑子里构建出一个完整版本。如果最初的印象错了，后面的工作往往只是认真地把错误做完整，并在验收时第一次见面。

我们愿意花很多时间讨论按钮放左边还是右边，因为用户可能找不到，却很少有人关心一份需求是不是也需要被设计。默认说法总是“写清楚就行”，但信息很多不等于容易理解，文字完整也不等于重点明显。一份设计糟糕的需求不会让人看不见内容；它会让每个人都觉得自己看懂了，而且看懂得还不一样。

用户第一次接触产品，是打开产品；团队第一次接触产品，是打开需求。所以用户会因为界面不好而困惑，团队也会因为需求不好而困惑。区别只是，一个问题发生在屏幕上，另一个问题发生在会议室，后者通常还会生成更多文档。

很多人觉得自己每天都在设计产品。实际上，他们也在设计团队如何误解它。