原型|Axure原型可以当产品需求文档使用么

编辑导语：需求文档的撰写是产品经理的日常业务之一，那么，就具体业务的内容、难度差异等方面进行考虑，产品需求文档的撰写应该如何操作？本篇文章里，作者结合Axure原型，阐述了他对需求文档的撰写思考，一起来看一下。

文章插图
工作中就产品需求文档的事情与领导发生了分歧，基于之前快速迭代小团队的工作习惯，我认为给开发交付的时候只要在交互原型中做好标注就行了，既方便我去写描述，又方便开发人员去看，一举两得。
但领导让我一定要写文档，而且让我一定要从思想上改变这种“危险”的想法。没办法，虽然从事了几年产品工作，我还是从头梳理了一下该用什么形式交付产品需求文档这件事。
一、Part 1讨论到这种看似非常基础的问题，产品经理会习惯去把问题做拆解，把名词做定义，往往疑问就来源于问题提得不那么合理。
所以首先我们所说的Axure原型到底是什么。Axure毕竟只是一个工具，在不同的人手里会做出不同的花样，那么首先我要说Axure原型≠产品原型。
那什么是产品原型呢？下面有两个定义：
某种东西的第一个、典型或初步的模型。 ——《牛津字典》
将想法转化为可传达给他人或者与用户一起测试的形式，并且有随着时间推移改进该想法的意图。 ——《原型设计》O＇Reilly
大概意思明白了，但还是不是很明白对吧？那就举几个例子，上面是项目最终交产品的话，下面就是产品原型。

文章插图
【 原型|Axure原型可以当产品需求文档使用么】产品原型就是产品的一个雏形，有的人会把它做得很精细，尽量还原最终产品想达到的样子；有的人就大概整整，让看的人能Get到他想表达的最主要的点就行了。
具体到我们所说的产品，其实以下几种形式都能算作是产品原型。

文章插图
但这些都只是进行想法的表达。还是刚才的例子，最终要将一个产品实现出来，对于大多数团队和项目来说，我们还是需要一个用于施工的说明性文档，这样才能够大家一起把这件事情做成，否则就只能凡事靠自己了。

文章插图
把原本你对产品原型的讲解继续深化、细化形成一个说明性的文档，就得到了产品需求文档。抽象来看，需求文档就仅仅比原型多了一些需求说明。
软件的产品需求文档一般就用文字、用表格、用流程图说明就够了。而建筑的施工图由于行业的发展，形成了自己的一套独特的标注体系。开个脑洞想一下，产品需求文档又何尝不能有自己的一套标注体系呢？
所以接下来我会一口气得出三个结论：

产品需求文档=产品原型+需求说明；
产品需求文档并不绝对就是Word版的文档；
标注清晰的Axure原型就是产品需求文档。

二、Part 2如果接受了我上面的结论，那其实需要接着讨论的只是形式上面的问题，Axure和Word，哪个更适合写PRD呢？
似乎越来越多的人倾向于用Axure，也有专门叫教人怎么做个动态文档的，看起来很酷炫。但需求逻辑真的很多时，要想把需求说明全部都写进去变成“真”文档，排版就是门学问。

文章插图
而Word文档看起来既老派，又经常动辄几百页，让人一看就头大。可以为它就要被淘汰了，每当老板要个“总”文档时，又不得不用到它。

文章插图
其实我们都知道Axure和Word一开始都不是为了写产品需求文档而诞生的，由于其各自的功能形式的局限，就已经决定了他们在写PRD时候有优势又有劣势。
Axure所提供的是一张张单独的画布，你可以随意摆放文字和图像，并用引线将它们连接起来。这些图像你还可以让他们可以交互起来。
Word提供了一个连续的流式的内容区域，你可以一直往里面填充内容，定义好章节标题就永远不会乱。Word还有相比其他软件更为成熟和强大的修订及标记功能，能记录好每次修改的变更。

文章插图
工具的不同，就导致了两者的输出物所针对的需求场景也是各有侧重。

文章插图