PRD 这样写，我看着都不爽

昨天帮别人看了一份产品需求文档，也就是 PRD。不过，看完后我是很不爽的。

原因很简单，这已经触碰到了我那细节控的神经。

接下来我说几个关于这份 PRD 的问题，如果你是产品经理，可以试着对照一下自己是否有类似的毛病。

1、英文字母不分大小写

在这份 PRD 中，有多处提到「ios 客户端」和「android 客户端」。不仅如此，有的还写成「Ios 客户端」或者「IOS 客户端」。

不知道你们看了是啥感觉，反正对我来说，这样的写法我是不能接受的。

正确的写法，应该是「iOS 客户端」和「Android 客户端」。

另外，在文档中关于数据接口的内容部分，到处都是「api」或者「Api」这样的写法。

不知道是这份 PRD 作者在键盘上对大小写键无感还是咋地，漏洞百出。

正确的写法，应该是「API」。

所以，对于这种涉及到专有英文单词的地方，一定要注意大小写，并统一规范。

2、语文表达的错误

绝大多数的产品都有用户登录功能，但绝大多数关于这个功能的 PRD 中都会把登录写成「登陆」。

甚至在已经上线的产品中，也存在这样的纰漏。一方面是输入法的问题，但更主要的是产品经理不够细致。

除此之外，在语文结构的表达上，很多写法同样是有问题的。

比如，我在这份 PRD 中看到这么一句文案：「成功创建订单」。

乍一看，似乎没啥毛病。可按照「名词 + 动词 + 状语」的表达结构来看，这种说法其实是不准确的。

正确的说法，应该是「订单创建成功」。

这些看似不影响大面的细节，实际上反映了一个产品经理的基础素养。当然，用户是不会找茬的，但用户会有自己的感觉。

3、提示信息和操作不对应

在这份 PRD 中有一处是关于对话框的交互设计，这位产品经理写在对话框里的文案是这样提示的：「确认删除该订单吗？」，然后对话框下面有两个按钮，分别提示「删除订单」和「不删除」。

乍一看，是不是同样觉得没啥毛病？

可是，这种写法并没有将提示信息和操作对应起来。问的是要不要删除，那操作结果只需要回答是否确认就行了。

所以，正确的写法是把两个按钮上的文案分别改成「确认」和「取消」。

这么一来，提示信息和操作就能对应上了。虽然只是简单的提示和操作，但同样需要讲究。

4、没有穷尽所有用户场景

PRD 中有一处设计是让用户填写表单并上传，可产品经理在定义上传结果时只考虑了两种情况，分别是成功和失败。

对应的，就是针对这两种情况的提示文案。

可是，真实的用户场景远不止这两种情况。比如，上传过程中如果出现网络异常怎么办？如果上传后是因为服务器异常导致没有响应怎么办？如果用户误操作返回上一个页面导致数据丢失怎么办？

这些，都是需要穷尽的用户场景。

关于穷尽场景的做法，可以用流程图去做各种路径上的分叉判断，这样得出的所有叶子节点就是细分场景。

然后，把这些细分场景都考虑在产品方案内，做好反馈措施。

要不然，用户可能会因为一个没有被穷尽到的场景搞蒙。比如，因为程序员没有做出场景判断，导致一些接口参数异常的错误直接暴露给用户。

这种体验，显然是不好的。

5、只有方案，没有背景

这份 PRD 还有一个问题，就是满篇的方案，但唯独没有说明为什么要做、以及做完后的意义是什么。

说白了，就是缺乏需求背景。

一份完整的 PRD 不仅仅是设计方案的呈现，更应该包含需求背景和意义。这样，承接这份 PRD 的人才知道自己做的事有什么价值。

比如，为什么社交产品里要做「话题功能」？

如果只是因为别的产品有所以我们也要有，那这样的产品经理就是搬运工。

话题功能最大的作用，其实是通过主题将原本没有交集的人拉到同一个空间，进而让他们产生社交关系链并形成互动。

所以，给每一个设计找到理由，是产品经理的必备能力之一。

人都会为有意义的事情而奋斗，或许是收益、或许是个人价值的实现。

写在最后

细节决定成败。

这是一句已经被说烂的话，但话糙理不糙。尤其是对于做产品来说，细节真的能体现出很多背后的思考。

生活中有很多值得观察和思考的细节，细腻感也不是一天两天培养出来的。

不过还是那句话，生活处处皆产品。

················· 唐韧出品 ·················