面對眾多的產品設計需求，產品設計人員要想一一理清楚就已經是一件不容易的事，更何況要將這些需求清單全部都變成可演示的產品原型。對于沒有研發(fā)背景的產品經理來說，從需求檢查清單到需求文檔是一個較難理解的技術鴻溝，這里的研發(fā)背景是指參與過產品的需求分析、產品設計、產品開發(fā)、產品測試、產品運營這樣完整的過程，特別是沒有開發(fā)之前的產品階段經驗的，對產品的需求管理會比較模糊，沒有一個清晰可視化的指引，產品經理在管理產品的時候會比較累，也比較的被動。因此對于這類產品經理來說，有相對來講比較貼近最終產品實際的原型，對產品的需求管理會容易很多。再者對產品設計人員來說，一個產品的原型并不是只有一個版本，且設計多個需求時，部分設計可以重用，也能提升產品設計的效率。

AxureRP經過這么長時間的使用，已經漸漸深入人心，不過很多人看到AxureRP的第一反應就是原型設計，其實AxureRP還可以做很多其他的事情。就像很多其他工具那樣活用起來，雖然說術業(yè)有專攻，但在要求不高的時候，AxureRP絕對可以用來做產品的需求管理，首先其自帶的共享協作功能，就是很好的將需求化整為零，又最終歸集在一起的應用；其次是其站點地圖管理模式可以清晰的反應出整個產品的結構，類似產品的需求檢查清單，可以逐一確認；再者AxureRP可以用來做版本管理，每次改動都可以記錄下來。

AxureRP的共享協作功能類似開發(fā)人員用的集成開發(fā)環(huán)境，可以將需求分成各個小項，由各個不同的產品設計人員設計，然后最終歸集在一起做統(tǒng)一驗證，當然這里有一個設計風格統(tǒng)一的問題，這個應該每個公司都有一套特定的設計規(guī)范的，至少某個產品的設計風格是有統(tǒng)一標準的。需求拆分后，首先要保證每個單獨的需求都有完整的Story可描述，原型設計完成之后可做單獨的演示驗證；其次要保證每個拆分后的需求合而為一之后是一個整體，這里不講求無縫對接，只求大體上沒有問題即可，這樣在做完整性驗證的時候，就不會出現斷層的情況，就要求在開始原型設計之前要確定好整個產品的需求檢查清單，對每一條需求list指定對應人員進行設計。大家在共享任務里領走各自的所負責的部分，在設計完成后提交即可，且每次改動規(guī)定必須先簽出到本地，這樣可以不影響實際的原型整體。

AxureRP的站點地圖面板可以很好的展現產品的層次結構，可以直接將需求檢查清單按照產品的模塊構成維護成樹形的結構，每個需求對應一個節(jié)點，這樣可以清晰的看出哪些做了哪些沒有做，而且這樣設置之后也有利于協作的時候分派，匯總之后也不會導致結構混亂。如果不能按照這樣的方式進行設置，也可以在設置好對應的產品信息架構之后，將里面的節(jié)點和需求檢查清單里面的list項進行關聯，以便備查。這塊功能的使用我在介紹AxureRP的時候講到過，可參考《AxureRP介紹–站點地圖面板》和《AxureRP介紹–架構圖和流程圖》。

產品的設計版本管理可以依托AxureRP的站點地圖面板來進行，將每次相對較大的調整都復制出一個版本節(jié)點來記錄，這里改動是否需要新建版本由各自的產品設計人員來把握，目的是為了對每個設計版本可以進行追溯，盡量減少改過來又改回去的返工情況。而且進行版本管理之后，也可以清晰的看出每個需求節(jié)點的需求變動情況，前前后后改動次數較多的就說明有問題了，要么是需求分析階段的問題，要么就是產品設計人員沒有理解需求的本質，總之可以針對性的進行分析和解決。

AxureRP還可以自動生成需求設計說明書，這個我想大家都知道了，只不過所生成的問題如果要實現圖文并茂，一是在設計的時候就寫好注釋，本文所介紹的方法，在協作的時候就可以要求不同的設計人員將各自所設計的功能進行注釋；二是手工的補寫，對于較大的設計項目來說，這個比較困難，必須有一個人了解整體的設計細節(jié)。

AxureRP還有很多隱性的功能是可以發(fā)掘的，比如模板的重用、頁面的說明等，個人感覺如果現行公司內沒有很好的需求管理工具的話，AxureRP是一個不錯的選擇，可以在內網搭建一個小型服務，將產品原型的生成目錄發(fā)布上去，就可實現在內部的訪問，非常的便捷。