我很少會寫傳統意義上的產品需求文檔；甚至，我連word都很少用。用慣了Axure的任意佈局方式，再用word感覺非常彆扭，尤其是在添加圖片時，簡直感到捉急。當然，這不是我不用word寫需求文檔的根本原因。
簡單來談一下，爲什麼軟件開發項目中，需要需求文檔這麼個東西？
在稍微大一點的開發團隊中，產品經理未必能向所有開發人員，傳達具體的產品開發需求。這時就需要一份文檔來供所有的項目參與人員閱讀。而產品經理又常常愛拍腦袋、容易變卦，所以文檔也是開發人員約束產品經理的一項武器。在產品上線前的測試環節，測試人員也同樣會拿產品需求文檔來驗收產品質量。當團隊進入新人時，文檔也可以讓新人更快地瞭解產品。
總的來說，產品需求文檔有三個核心作用：
- 傳達產品開發需求；
- 保證各部門溝通有理有據
- 產品質量控制有具體標準
由此可見，產品需求文檔是必不可少的。那一份好的需求文檔，就應該能準確傳達出產品的開發需求。那麼產品需求文檔該用什麼方式寫，才能更好地傳達出產品開發需求呢？
就我所見，行業大多產品經理都是用Word+Axure原型的方式組成產品需求文檔。那這種方式，是否真的能方便地表達出產品需求？我問了很多程序猿，他們在開發時，一般都是看着效果圖和原型圖寫代碼，只有在遇到問題時，纔會查看word文檔。也就是說，開發需要一邊寫代碼，一邊看效果圖，一邊看原型，還要時不時查看文檔。而且，大多數程序猿都不會逐字逐句去讀產品經理的長篇大論。那產品經理寫word真的合適嗎？這樣的用戶體驗真的好嗎？花費大量時間寫word真的有價值嗎？在Axure畫原型的同時，我們爲什麼不能直接在旁邊標註呢？這樣豈不是方便快捷很多嗎？
其實，當下流行一種直接在原型圖
上標註的需求文檔撰寫方式。在新版的Axure8中，也已經推薦了原型加標註的需求文檔樣式。Axure8新增了一組部件—不幹貼，就是方便產品設計人員進行功能標註。
重視用戶體驗
的產品需求文檔該怎麼寫？
下面我就不講思路了，先展示我的產品需求文檔的歷史版本和最新版本對比。
產品需求文檔V1.0 版
這是我一年前的原型加標註，只有很粗糙的標註，現在看來真的是很low啊
產品需求文檔v2.0版本
這個是第二個大改版，做成了網頁的形式，有一級導航，二級導航，還有版本號。左邊的站點地圖
也進行了清晰的邏輯分組。
產品需求文檔v3.0
這是現在我用的版本，導航欄變得精緻了有沒有。所有標註都進行了像素級排版，所有的間距都用準確的像素測量，然後佈局。
隨着每個版本的調整修改，其實都伴隨着視覺效果提升、邏輯架構更清楚，也更加提升了用戶體驗。
下面繼續來展示更多頁面
產品簡介
我將PPT做的商業需求文檔
貼在了裏面，真可謂時時刻刻不忘商業目標啊
版本說明
是非常重要的版塊，整個版本所有的需求都列在這裏，並且已經寫好了版本升級的提示內容，市場同學可以直接拿去用。開發同學通常都是參考這裏來進行工作分配，點擊詳情按鈕，可以直接跳轉到原型圖頁面，那裏有詳細的需求描述
此頁面我沒有進行詳細豐富，其實還可以寫具體什麼功能，由誰負責，工期多久等內容
版本歷史
這個頁面也是很重要的頁面，所有的版本迭代都可以展示在此表格，可以清晰地看到你們團隊的版本迭代週期
修訂歷史
此頁面是非常重要的頁面，雖然他是排在最後一個位置，但是，每次打開Axure文檔都會先顯示此頁面。就拿需求文檔來說，我還沒遇到哪個版本不用進行修改的，所以產品經理一定要把每次文檔調整的地方在這裏清晰地寫出來，方便文檔讀者觀看，也方便自己記錄
思維導圖
這個版塊下，全是產品相關的圖表，比如產品結構圖
、信息結構圖、流程圖等。我曾經嘗試用Axure自帶的流程圖部件來畫流程圖和思維導圖，但得出的結論是，太耗時間，而且佈局很費力。所以，這裏我都是用mindmanager導出圖片
全局說明
這個頁面其實是展示整個產品的設計規範，一些很多頁面通用的規則都可以在這裏展示
交互原型
此頁面就是所有的原型+標註頁面了，在這裏，我會將這個頁面所有的功能與跳轉邏輯標註清楚，並且用紅色將重要按鈕凸顯出來，用藍色標記可點擊的鏈接。而功能標註的佈局我是仿照sketch的風格設計的，但比sketch
更優秀的地方在於，很多地方是可以點擊的，具有交互的
用例文檔
其實，這個用例文檔的頁面，是我閒的無聊時做的，並沒有什麼卵用，測試人員也不會使用此表，更加方便的還是Excel
需求卡片
這個頁面到現在也已經放棄了，因爲對需求的整理，最好還是在Excel中
結尾
這份需求文檔是我打磨一年，所產出的。目的就是希望打造出一份易於團隊協作的產品需求文檔。之所以不貼出源文件
的下載鏈接，也是希望其他產品人看到後，可以有所啓發，從而做出合適自己團隊的需求文檔。不發任何原文件或HTML文件