一直以來，我都習慣在Axure上寫需求說明。

但是，也有不少公司或者技術習慣使用word文檔的PRD。

確實，Word文檔形式的PRD有其存在的價值，一來方便存檔，二來也能夠方便習慣使用Word文檔的技術，三來還方便發郵件做報告，四來還能夠對於一些有較複雜流程，需要用到各種圖示的產品項目，word文檔也方便貼圖。

既然Word文檔的PRD有那麼多好處，是不是所有的產品項目都用Word文檔來寫PRD？

一、如何選擇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文檔。做到Axure需求文檔和Word需求文檔同時兼顧，並且維護的時候能夠同步。

（在Axure中寫需求文檔）

（生成的Html原型文檔）

（導出Word需求文檔）

以上三張圖片是使用Axure 9.0來畫原型和導出Word需求文檔的，同樣的，Axure 8.0也能夠導出Word需求文檔，Axure 9.0有一個比較好的就是，需求說明中的序號能夠和元件中的序號對應上，並且可以修改序號。這樣就不需要通過用線條將原型中的組件和需求文檔進行連接了，減少線條對原型界面的干擾。

（Axure需求說明文檔和Word需求說明文檔的對應關係）

通過上面的對比圖，可以了解Axure需求文檔和Word需求文檔的對應關係。根據上面的對照圖，下面簡單說一下主要的步驟：

導出的Word需求文檔，主要有3~5部分組成：頁面概述、用戶界面（原型截圖）、需求說明（元件說明）、交互說明、（母版說明）。我常用的是前三部分，把交互說明也在需求說明中寫上了。

第一步：定義元件欄位

建議只需要默認的一個自定義元件欄位即可，可以改名為（需求說明），改名步驟圖如下圖。因為元件說明的欄位是需求說明表格中的每一列，也就是說，自定義元件的欄位越多，表格就越寬，Word文檔的寬度有限，所以不建議設置過多的自定義元件欄位，如果想要區分更細的話，可以在這一個欄位下面分點寫，如：在需求說明中寫上「功能介紹、交互說明、邏輯描述」等等。