鄙人拙见，欢迎各位共同探讨。

自己摸爬滚打一年多，同时也跟着产品leader学习，主要是做前台产品，一份相对完整的产品（交互）文档可以包含以下部分。

1.文档说明。主要包括对文档的作用、目的说明；版本记录。

2.产品说明。主要包括产品定位；产品目标；目标用户；商业模式；功能结构。

3.业务说明。主要包括业务流程；业务资料。

4.产品原型。此部分一般会与交互设计师共同维护。

5.关联系统需求。主要是给后台提的需求。

这一年多来做的算是一款创业产品。最开始的时候，作为一个产品新人，此前没有任何产品经验，在没有交互的情况下，我最开始尝试的就是产品原型图，因为有设计的基础，很快就上手了。但是久而久之，其实更像一个传达需求的“交互设计师”。在leader的指点下，我也参考他的完整的一份PRD，就是上述的几个部分。这样写下来，其实会促使自己去反思产品的定位、核心功能、以及整个业务逻辑和以后的发展方向。

团队采用的是敏捷开发，因此在最初的时候我们不追求美观和全面，只要能清楚目前这个阶段需要什么，快速迭代和实现就OK了。在整个团队磨合以后，作为产品的我就开始思考如何改善自己的产品文档了。

1.相对完整的产品文档。因为不断有团队成员加入，并且产品团队和开发团队分别在广州和上海，设计、开发团队也不希望仅仅成为一个执行者，因此有一份相对完整的文档，比如上述的5个部分，就能减轻你们的沟通成本以及增强大家的参与感。

2.良好的排版和设计、细节到位。团队Boss是一个有强迫症和完美主义者，因此我们作为产品，提交的产品文档也要进行排版设计。比如字距、行距、字体的颜色、标点符号全角半角等，尤其是原型图，不要想着随意画几个方框糊弄他，一定要细致到每一个icon都要用到最符合现在的设计潮流，这样会在提需求给boss审核的时候就被毙掉（因为我们公司的交互资源是公用的，所以产品经理在提需求之前需要自己画原型给老板审核）。

3.记录关联后台系统的需求。在我司，许多后台都是共用的，最开始的时候我都是口头提需求，但是发现这样子对方产品经理会理解不清楚或者自己日后查阅起来也不方便，因此提需求的时候最好把你的需求也保存在这一份产品文档里面，为日后省了不少事。第一点提到的相对完整产品文档，除了给自己团队成员看，也方便给别的产品经理理解你们的产品和查阅。

4.版本管理。我们开发的周期一般为2周一个版本，迭代速度非常快，因此在产品文档方面，我一般会自行维护一份完整的囊括整个项目各方面的内容，如上述的5个部分；而交付给交互和开发的文档，一般都是当前2周之内的工作量的文档，这样子他们不会搞不清楚这个阶段需求的边界和范围。扯个题外话，我有个同事非常喜欢把一整份超级完整的产品文档交给开发并且不帮他们做划分，因此开发经常都会一头雾水，不知道到底需要实现到什么程度。

当然，你可以有一份超前的产品文档，囊括了接下来几个版本会要覆盖的范围，放在一个公共平台方便查阅。原因有二：一个是方便你的开发团队了解你日后的发展方向和目前所做需求的意义是什么，也就是上述的参与感；第二是与你合作的开发经理会从技术实现和连续性等等的角度给你适当的建议，帮你调整你的步伐，让整个团队在一个比较合理的节奏下进行版本迭代。

5.关于产品原型。

顺便提到一句，一位前辈跟我说的：“产品经理处理的都不是一般情况，只有把“二般”情况处理好才能成功。”这句话在我现在看来，应该就是说我们应该去思考一些边界情况和特殊情况下应该如何处理，这个在写需求的时候应该特别提到，这也是我自己经常会忽略的，以后应该引起注意。

关于产品经理与交互设计师的界限，其实会有重合的部分。其实一般你的交互设计师会跟你说你的需求只需要用文字或者口头描述清楚即可，不需要具象化，因为他可能会有自己的想法，而且会不知道应该在你的基础上进行修改还是新建一份文档好，可能会浪费大家的时间。因此有2个建议：一个是如刚刚所提到，自己维护一份完整的文档，按照你喜欢的风格和习惯的排版；二是以一份文档的形式记录你的需求，主要需要涵盖以下几个内容：序号、需求模块、需求类型、具体描述、期望目标、需求收益、需求提出人、备注、完成情况。

一份良好的需求文档，能够帮你管理好你的需求。然后在这份需求表的基础上，附带上交互的文稿，就可以交付给开发了。交互文档虽然不可能细致到方方面面，但是也应该尽量完善，也方便测试写TC，还有产品团队验收产品。在开发过程中发现的问题，应该及时补充进入产品文档，对交互文档进行了修改，记得要进行标注，方便日后对照，以免需求混乱。期望目标主要是指在项目的直观实现的目标，比如优化产品UI、完善产品功能、提升PV、UV等等；而需求收益主要是一些商业目标、市场目标等等一些最终目标（取决于你的产品类型和目标），比如通过增加倒计时按钮提高订单转化率等等。当然这也只是我的个人记录需求的习惯，只是作为参考。

产品文档最好有统一性。就是在文档逻辑、语言风格、排版设计方面，最好能统一起来，方便各方理解。这个主要是在产品和交互维护同一份文档的时候，可能会产生一些歧义。比如这个某个icon在你的文档里是表示发现，而在她的文档里是表示朋友圈；再比如关闭当前正在写作的文档，提示浮层显示“是否保存文档”，“保存”和“确定”其实是有不同的，“保存”是指保存文档，而“确定”则是对上面提示语的确认。细节虽然细致，但是也值得注意，需要保持一致性，不能一个地方一个样子，这些都是交互设计师需要考虑的细节部分。因此我一般只会画辅助理解的几个简单原型，剩余的完整的需要交付给设计、开发的原型、交互等工作留给交互设计师去完成。

总之文档只是工具，最重要的是因时制宜、因地制宜，在不断磨合中探索出方便自己团队交流的文档。