prd是一个用于跟开发、ui、测试等团队进行沟通的基础文件，所以把prd看成一个产品的话，开发、ui、测试就是这个产品的用户，为了把我们的想法尽可能的无损的传递给上述人员，我们需要在prd上尽量完整、准确的描述清楚。作为天天把用户体验挂在嘴边的产品经理，非常惭愧的表示，我的prd用户体验好像不及格：缺少细节。
现在写prd的方式，基本上就是直接出原型，然后在原型文档上更多的是把正常流程、异常流程、主体业务逻辑描述清楚，而一些交互细节、界面控制等内容则更多的依靠口头沟通。这样就带来一些问题，由于文档中缺少一些细节，所以在开发的过程中，开发人员就需要经常的就一些细节问题进行确认。
那么问题来了：
1、信息同步问题：
作为产品经理，我跟开发的同事是坐在一起办公的，而测试虽然是在一个大办公室，但还是有一定距离，ui则在另外一个办公室。开发提出问题的时候，我们口头就沟通了，事后也许又插入进来一个其他的事情，这个时候之前沟通的结果，可能就没有传达给测试和ui，然后测试同学、ui同学就接收不到最新的变化，导致信息不同步；
2、进度问题：
1）开发过程中对需求进行细化，可能新的方案跟开发的设计方案有较大的差异，可能导致开发返工；
2）如果变化未及时同步给测试同学，容易导致测试用例没有及时更新，在测试的时候按照老的用例进行测试，瞎耽误工夫；
3）ui也可能需要跟着变化，需要ui进行支持，ui是紧缺的资源，很可能无法及时响应改动，反过来又影响开发进度；
3、信任问题：
经常出现这种问题，导致开发、测试、ui对产品汪的信任下降，在后续的工作中，可能带来消极的影响：这个产品不靠谱。
尼玛，细思恐极！
怎么破？
在产品设计阶段，好好的把各种场景都考虑清楚，各种页面交互流程、异常处理、分支流程、页面控制、数据埋点等等，都在原型上描述清楚，争取提交一份符合用户心理模型的原型文档。
