我一直习惯在Axure上写需求声明。

然而，许多公司或技术习惯于使用word文档的PRD。

的确，Word文档形式的PRD有其存在的价值，便于归档，便于习惯Word文档的技术，便于发邮件做报告，对于一些流程复杂需要各种插图的产品项目，便于映射。

既然Word文档的PRD有这么多好处，那么所有的产品项目都用Word文档来写PRD吗？

1.如何选择Word文档或Axure文档编写PRD？在我看来，Word文档和Axure文档各有优缺点，可以根据实际情况选择合适的方法。

Word文档的PRD是一种比较传统和成熟的表达方式，其优缺点如下:

优点:

1、方便归档，方便交接和传播(传输)

2.习惯使用Word文档的技术是很方便的

3.发邮件做报告很方便

4.此外，对于一些需要各种插图的复杂过程的产品项目，Word文档便于映射。

缺点:

1.原型和需求文档需要不断切换，使用起来很不方便

2、缺乏层次感，话多，容易漏掉一些重要的需求点

3.产品经理在编写需求文档时，还需要不断在原型和Word文档之间切换，操作起来很不方便

4.产品经理编写的需求文档不能直接对照原型进行描述，容易遗漏一些需求描述

5.Word文档字数多、页数多，维护起来不方便

同样，在Axure上编写需求描述也有其优缺点，具体如下:

优点:

1.技术方面，不需要来回切换原型和Word文档，方便理解需求

2.对于产品，不需要来回切换原型和Word文档，方便描述需求逻辑

3.对于产品来说，维护需求描述很方便。如果有需要修改的地方，可以用红色标注对应的原型修改描述，表示已经修改。

缺点:

1.不方便归档(与Word文档相比)

2.不利于发邮件和做报告

3.Axure的需求描述不方便映射，不适合需要更多图标帮助理解需求的功能/项目

(如果是APP类型，不使用Axure提供的需求描述，直接在原型中写需求描述的方法不存在这个问题。)

经过一番比较，既然这两种方法各有利弊，如何选择呢？

对于需要快速原型化和迭代的中小型项目，建议直接在原型上编写需求描述，并快速向技术提供原型和需求描述文档。

Word文档可以用于复杂的过程，尤其是一些后台项目。Word因为需要添加流程图、类图、时序图等图形辅助技术来理解需求，所以更方便映射。

很多产品在绘制原型、编写需求规格说明时，习惯于在原型中编写需求规格说明，并用辅助线将它们与相应的功能(组件)连接起来。个人觉得这个方法不太好，虽然我以前是这样写的。至于为什么不好，你可以继续读下去。

如果习惯用Axure写需求文档，如何克服Axure的缺陷？也就是克服Axure在编写上述需求文档时的缺点。

第二，如何兼顾Axure需求文档和Word需求文档。因为习惯了直接在Axure上写需求说明，所以一直在思考如何让Axure克服它的缺点，兼顾使用Word文档所使用的技术。

如何解决Axure编写上述原型文档的弊端？

1.不方便归档(相对于Word文档)-导出Word文档进行归档

2.不利于发邮件和做报告——导出Word文档用于发邮件和做报告

3.Axure的需求描述不方便映射，不适合需要更多图来帮助理解需求的功能/项目——在Axure中增加一个独立的页面作为附加描述，粘贴流程图、类图、用例图、时序图等。作为附加说明。

导出Word文档的前提是规范Axure中需求文档的编写。也就是我前面提到的，建议不要在原型中写需求描述。因为:

1.原型中的写作要求会影响原型的内容，尤其是背景类型的产品原型，并影响原型的开发、阅读和理解

2.直接在原型中写需求描述。虽然影响直观，但不利于归档、报告等。，并且不利于维护需求文档，这加深了上述Axure的缺点

相信很多人都知道Axure可以导出Word文档，但是实际使用这个功能的人并不多。其实这个功能挺好用的。介绍了如何通过Axure自身的功能编写需求文档和导出Word文档。轴需求文档和Word需求文档要同时考虑，维护可以同步。

(用Axure书写需求文档)

(生成的Html原型文档)

(导出Word需求文档)

Axure 9.0用于绘制原型和导出Word需求文档。同样，Axure 8.0也可以导出Word需求文档。Axure 9.0有一个更好的特性，需求描述中的序列号可以对应组件中的序列号，序列号可以修改。这样就不需要用线把原型中的组件和需求文档连接起来，减少了线对原型界面的干扰。

(Axure需求规格文档与Word需求规格文档的对应关系)

通过上面的对比图，我们可以知道Axure需求文档和Word需求文档的对应关系。根据以上对比图，主要步骤简述如下:

导出的Word需求文档主要由3~5部分组成:页面概述、用户界面(原型截图)、需求描述(组件描述)、交互描述和主描述。我一般用前三部分，需求描述里也写交互说明。

步骤1:定义组件字段

建议默认只需要一个自定义组件字段，可以重命名为(需求描述)。更名流程图如下。因为组件描述的字段是需求描述表中的每一列，也就是说自定义组件的字段越多，表就越宽，Word文档宽度有限，所以不建议设置太多自定义组件的字段。如果想更细致的区分，可以写在这个字段下，比如需求描述中写“功能介绍、交互描述、逻辑描述”等。

第二步:写需求描述

在定义的组件字段中写入需求描述。题外话，Axure的缺点是不能在需求规范中直接映射，没有删除线(更容易区分有删除线的修改文档)。如果Axure可以将需求规范(组件描述)变成富文本，那么添加映射和删除线会更完美。

步骤3:导出单词需求描述

点击“发布-生成Word指令”(Ctrl+Shift+D)

第四步:调整输入的内容

如上所述，Word需求文档的导出由3~5部分组成，这一步是设置要生成的内容格式。下面分享一下我的设置，就不细说里面的设置了。我可以自己试试。

(页面设置)

(主设置)

因为我这里原型涉及的模板只有两个主，整体框架和底层版权，不需要特别说明，所以不需要生成模板的描述。

(属性设置)

(快照设置-原型截图)

(组件设置-要求描述)

(布局设置)

(模板设置)

按照规范编写Axure需求文档后，导出的Word需求规范文档更加规范。

原型标准化、需求规范文档规划、生成的Html原型和导出的Word需求规范文档，既能满足不同使用习惯的开发人员，又方便他们自己维护文档。