axure基础教程播放：PRD需求说明文档你真的会写了吗

需求说明文档又叫产品需求文档，在行业一般都直接叫做PRD，很多新人在写PRD文档的时候，要么是直接按照自己的理解去写，要么就是从网上随便找一份模板下来，好一点的公司会由QA部门统一规范文档格式，但是结果你写了，时间用了，却没人愿意看，有没有这样的困扰了？

需求说明文档是必不可少的，它的作用你知道哪些？

首先，是对自己而言，需求说明文档是你重新梳理思路和查缺补漏的一个方法，我们在设计需求的时候不一定能想全面的，这个一般人都是做不到的，能在设计阶段就能完全无纰漏的产品，我是佩服的，那么除开需求评审检验需求以外，需求说明文档的书写过程就是一个很不错的方法，所以写文档，是有很大的好处的；

其次，是对跨部门而言，特别是QA和研发部门，QA虽然说可以看你原型交互写测试用例，但那仅仅限于很有经验的QA才能写好和测试不出问题，研发就更不用说了，要是没理解透你的需求，怕是要全副武装；

最后，是对公司而言，每个人的岗位内容都可能发生调整，交接的时候公司不小出问题，你也不想一直带“徒弟”或者花自己的时间去帮别人解决问题吧？

需求说明文档应该怎么写？

• 内容和格式

说到需求说明文档你肯定会想到文档的内容和格式，一篇好的文档应该至少包含图片中所呈现的内容，再结合自己公司和客户要求进行完善，比如有一些企业就会要求加入核心算法的讲解或者服务器部署方案；内容和格式这里我就不去深究探讨了，模板工具里面已经做好了排版布局，有需要的人可以关注后留言或私信，免费领取，这里我要探究的是到底是用word写还是用Axure写的问题。

• 展现形式

我相信很多公司乃至于很多个人，都是用word建立一个模板，然后不断的码字，最终完成PRD需求说明文档，但从我的经历来看，有时候word版本的需求说明文档并不那么适用，特别是以敏捷开发为主的互联网公司。

不同公司业务和模式应该根据自身情况来规定需求说明文档的书写方式，我一般提倡两种：

一是我们所熟知的word版本；

word版本太常见了，也是很多客户认可的一种形式，如果你是针对客户，并且你的客户有这方面的要求，不用考虑，直接写word吧。

二是基于原型图的Axure版本；

对，你没看错，就是Axure版本，可能会有人想不就是直接在原型交互里面写清楚需求细节不就好了么？我曾经尝试过，结果可想而知，就是不够，你解释花的时间更多！因为原型交互注重细节，那么顶层设计和整体描述怎么办？所以你需要将你的原型进行一个升级改造，由总到分，再由大到小，你节约了时间，研发和测试也节约了时间，何乐而不为？

如有需要，可以关注后留言或评论，只需一个单词“word”或“Axure”我就懂。

关注不迷路，我是产品经理小新，专注分享互联网产品经理干货。