如何用Axure來撰寫互聯網的產品需求文檔（PRD）?

01-07

具體的撰寫方法、流程，撰寫提綱和模板。最好有實際案例（移動互聯網的尤佳）可供參考和學習。

每個公司的流程都不一定相同

各說各家，我說我家吧，我們是一家小型互聯網創業公司

PRD的文檔部分主要由兩大部分組成：

1、產品結構、流程說明文檔，一般用excel的矩陣、mindmanager、visio或enterprisearchitect的流程和結構圖表達

2、Axure的界面和交互

文檔之外，還有最大的一部分就是：面對面溝通，紀錄結論

沒有撰寫方法、流程、模板（之前有的，取消了，以後可能還要再拾起來），這些和「提綱」都是思路，腦子裡想什麼，直接寫出來，畫出來，架出來，根本不需要管方法、流程、模板這些框框套套

實際案例？NO！泄露公司商業、產品計劃及詳情者，斬立決

題外話

為什麼不用word？？

答：寫過，三百多頁呢，尼瑪，除了老子自己寫自己看，根本沒其它人讀過全文好么

見人說人話，見鬼說鬼話

對BOSS：一張表格、圖表或幾頁PPT，把SWOT給他說清楚就行了；

對設計：鉛筆+A4，再用axure畫幾個線框圖把概念和元素說清楚就行了；

對研發：UML+excel+界面，把規則和策略說清楚，把需求說全面就行了；

對市場及運營：幾頁PPT+真實產品操作；

對客服：幾頁PPT+FAQ；

對用戶：以卧底身份混入用戶間，態度和說法全紀錄；

我來靠譜兒的回答一下這個問題，因為本身移動端產品的PRD我一直都用AXURE來編寫。

優勢

1、對產品人員：快速產出，我想沒有什麼比直接用AXURE直接寫PRD更快的方法，可以馬上拋棄繁雜的文檔格式，再也不用向寫八股文一樣寫文檔了，想想是一件多美妙的事情。

2、對於前段開發人員：前段開發人員,不必一頁頁的翻文檔，可以直接可視化的去查看，對照頁面標記去查看對應功能，所見即所得。

3、對於服務端開發人員：服務端人員可以更加快速了解整體業務邏輯，逆推服務端功能與介面設計。

4、對於測試人員：測試人員根據頁面去寫測試用例，而且對整體產品業務邏輯、頁面表現可以有更加直觀的了解，對於後期測試可以提供更加完整的測試思路。

OK 上面說了優勢，具體怎樣寫呢？先說下我的文檔結果

a、產品介紹：用於簡單介紹

b、更新說明：非常重要，每次更新標註更新說明，點擊直達更新頁面，非常方便

c、通用狀態：比如下拉刷新、搜索、載入、預設

d、用例：把流程用例展示

e、功能說明：在原型上標註氣泡，通過線條鏈接指向說明。並且可以在UE上直接加上鏈接。方便點擊查看。

總體來講就是這個結構。

參見好友 @唐傑專欄文章：

第四章：產品設計(1) – 產品需求文檔(PRD)介紹

第四章：產品設計(2.1)PRD寫作 – 羅列信息(信息結構圖)

第四章：產品設計(2.2)PRD寫作 – 梳理需求(產品結構圖)

第四章：產品設計(2.3)PRD寫作 – 原型設計(界麵線框圖)

第四章：產品設計(2.4)PRD寫作 – 用例模型(產品用例圖)

第四章：產品設計(2.5)PRD寫作 – 邏輯流程(功能流程圖)

第四章：產品設計(2.6)PRD寫作 – 需求文檔(PRD文檔)

90後的唐傑混跡與中美兩國的互聯網產品圈，平時有整理總結經驗的習慣，博客http://tangjie.me從11年就開始連載產品經理教程，在國內產品經理定義、定位以及工作內容流程不確定的情況下，他的教程還是非常系統而且接地氣的。

推薦產品新人或希望轉產品經理的關注唐傑的專欄，上手較快。

順便吐下槽，這兩年面試了不少產品經理，還真是「人人都是產品經理」啊，不管是什麼崗位什麼性格什麼行業的人都想嘗試下轉崗為產品經理，貌似也沒有門檻（其實大坑所在）。

產品經理，不是「人」的經理，是「產品」的管理者，不是「人」的管理者，所以當互聯網大佬紛紛表示自己是產品經理，你還真信啊？！不是崗位帶個「經理」就真是「經理」了，銀行客戶經理還是經理呢～所以不要因為「產品經理」聽起來牛B就想成為產品經理，產品入門不難，但要做好產品經理的工作不是人人都行，眼界、知識面、設計感、邏輯性、溝通能力等都有一定的要求，具體還有很多不一一表了，不要因為這個頭銜走上一條不適合自己的職業冤枉路。

當然如果你熱愛互聯網、充滿求知慾、理性與感性兼具、渴望改變這個世界，並且激情滿滿永遠不會丟棄對未來的憧憬和希望，那麼歡迎你加入我們，讓我們用互聯網創造更美好的世界。

樓主如果想好好做PM，就不要在axure上花費大量的功夫。不然你以後只能應聘交互設計師了（當然不是說交互設計師不如PM）。

產品大牛是一個服務於產品團隊的工具+社區的平台,旨在幫助產品經理,交互設計師在線託管自己設計的產品原型

Axure原型，可以像網盤一樣管理，現在只需要一個短鏈接群發過去，方便高效。

樓主問的應該是用axure來製作prd吧，我想我正好可以回答一下。

傳送門：產品大牛 | 助你享受產品經理工作,原型託管,在線PRD,產品導航

1、首先還是要準備的模塊

比如傳送門這個包括了：項目簡介、信息結構、流程圖、頁面組成、交互原型、功能列表、產品路線、修訂記錄。這一塊需要你自己把握，比如互金類的產品可能還有風險分析等。

2、接下來就是一個製作過程

其實製作過程很簡單，運用axure裡面的內聯框架就OK了。

點擊頂部的導航欄其實是在內聯框架中打開了左側邊欄的頁面。這玩意並不複雜。

3、關於axure做PRD的一點優勢吧

寫過prd的都知道，prd里描述一個交互效果很麻煩，你能按照你的點擊操作來敘述，但是你的同事未必能配合你理解。所以同事需要對照原型和文檔一起操作。那合在一起有何不可呢。

還有就是用axure做版本控制，本地直接能給同事看效果，不用反覆地發送word，這種感覺差不多是廖雪峰介紹git的特點吧

最後說一句，axure還是基本功，值得好好學習。

------------

歡迎加入精益求精產品經理群：633834294

http://qm.qq.com/cgi-bin/qm/qr?k=hv2i4ewZ9GEyVGU-aJO--nt_uanGDfK5 (二維碼自動識別)

我現在所有文檔類的全用Axure完成（word+PPT+Excel),發現自己已經喪失了使用其它軟體的能力

我覺得移動端更適合用這種方式

產品經理的兩項主要職責包括：對產品機會進行評估，以及對開發的產品進行評估。而定義即將開發上線的產品，則需要藉助產品需求文檔，來進行產品的特徵和功能描述。PRD文檔的寫作會因公司、團隊以及個人習慣而異，沒有標準的規範和統一模板，但有三大原則是不可忽略的：文字簡練、中低保真、測試驗證。本文僅陳述個人對產品需求文檔的理解，若有不正確的地方，還望多多指教。

（一）PRD的定義、主要構成及用處

簡而言之，產品需求文檔（Product Requirement Document），是將商業需求文檔(BRD)和市場需求文檔（MRD）進行結合，然後用更加專業的語言進行描述。它向上是對BRD內容的繼承和發展，向下是把MRD文檔中的各種理論要求技術化，向研發和設計部門說明產品的功能和性能要求。BRD&>MRD&>PRD是一個逐步論證併產出結果的過程，也是產品經理思維升華的過程。

PRD主要構成：

1.引言及概要

這部分主要解釋：需求背景、需求概要、需求目的、全局規則說明、名詞解說以及文檔變更記錄等，目的是讓閱讀者儘快了解並熟悉需求背景和概要。作為公司內部文檔來看的話，可以從簡來寫作。

2.業務說明及原型圖

整個文檔最核心的部分，其中包括產品功能主框架，比如：業務結構圖／流程圖、頁面交互／功能模塊元素構成、許可權說明表等。同時，各頁面之間基本的交互形式、文本注釋及線框圖，也是不可或缺的。

3.非功能需求

一些偏向「輔助」類的需求，包括：地理位置獲取、CDN緩存策略、Push推送機制、本地文件存放策略...

如果是產品的第一個版本，那麼在整個產品的業務流程和功能結構上就需要花更多時間來說明，既可以降低與整個團隊的溝通成本，也能作為後期開發的證據和備份，而這恰好是PRD文檔最大的用處。此外，它也發揮著將需求管理歸檔，促進從「概念化」階段到「圖紙化」階段的過渡作用。

（二）PRD寫作的三大原則

1.文字簡練

誠然詳盡的說明能給開發人員最全面的指導和參考，但「事無巨細」的備註及文字說明，有時反而會成為「過猶不及」的反例，增加溝通成本及延誤開發進程。在產品進行評審和討論具體開發細節時，有些問題會被重複提到，而在此過程中，如果能把關鍵性的邏輯用圖表或文本展現出來就很關鍵了。對於有些「眾所周知」的規則和功能需求的話，可以在產品文檔中進行適當精簡，否則開發人員也是沒有耐心看完的。

事實上，即使你的PRD已經十分精練，團隊成員也很有可能不會完完整整地看完，有時候甚至會忘記其中一些內容，然後認定是你當時沒有添加。當然，如果你跟團隊成員之間已經很有默契，彼此知道對方的開發習慣和設計套路，那麼即使有些需求沒有說明，產品的規劃和迭代也同樣能進入高效運轉的狀態。

2.中低保真

追求視覺細節和交互特效，在對外展示或用戶測試時，效果固然好。但通常的原型是為了內部溝通交流，只需要用線框圖將核心功能及架構進行展示，便可以把產品設計的思路梳理清晰。相反，高保真的原型在遇到後期的需求變更時，會帶來非常高的修改成本，而且會嚴重影響產品設計和開發的進度。正如用戶體驗五要素理論，產品的設計流程應該是：戰略層&>範圍層&>結構層&>框架層&>表現層。

3.測試驗證

這是將產品經理的想法進行呈現的階段，也是創造力和創新力出彩的地方。對於很多產品來講，有下面三個測試十分重要，而且對於PRD最終是否「接地氣」有著不言自明的決定作用。

1）可用性測試 －不僅能適應不同的用戶，而且可以找出遺漏的產品要求，從而進一步確認產品最初的要求是否是必須的。當然，從目標用戶獲取測試反饋，也是非常科學和藝術的。

2）可行性測試 －通過讓設計師和工程師介入技術的可行性調查和探索，可以儘早解決一些不太「現實」的問題，避免後期再調整的時間和精力代價。

3）概念測試 －對用戶是否有價值以及產生購買慾望的測試，可以結合一些優質快速的原型工具，將產品的預覽版本呈現出來，之後在實際目標顧客身上測試，從而得到有質量的反饋。

總而言之，精簡說明文字、保持中低保真、進行原型測試和驗證，把時間和精力花在如何提高產品核心競爭力上，減少無效及重複的工作，是產出優質、有價值產品及產品需求文檔的牽引力。

佔個位，回頭來答

我覺得一個產品不能完全拘泥於需求文檔，各個團隊的工作流程有區別，只要是能快速保質的完成開發，需求文檔模板沒必要千篇一律。

娃，我沒見過有人用axure寫需求文檔的。當然你做完原型，在旁邊做些注釋，讓開發按這個做也是ok的。

這個東西怎麼寫都好了，沒那麼重要，別在這兒花太多時間。