產(chǎn)品需求RD的寫作方法

1、產(chǎn)品需求文檔（PRD）的寫作方法無論我們做什么事都講究方式方法，寫產(chǎn)品需求文檔 （以下稱PRD文檔）也是如此，之前我通過五篇文章分享了自己寫 PRD文檔的一些方法，而這一篇文章主 要是對之前五篇文章進(jìn)行整體的摘要介紹，幫助大家快速了解寫作流程。產(chǎn)品需求文檔（PRD）的寫作五篇章：1、寫前準(zhǔn)備（信息結(jié)構(gòu)圖）2、梳理需求（產(chǎn)品結(jié)構(gòu)圖和用戶流程圖）3、原型設(shè)計(jì)（手繪原型，灰模原型，交互原型）4、撰寫文檔（PRD文檔） 5、用例文檔（UML用例圖、流程圖）1、寫前準(zhǔn)備（信息結(jié)構(gòu)圖）:在寫PRD文檔之前，我們需要先羅列出產(chǎn)品功能的信息內(nèi)容，這一步是將 想法逐漸清晰的第一步，也是幫助我們接下來規(guī)劃功能的輔

2、助信息， 同時(shí)也可以 輔助服務(wù)端技術(shù)人員創(chuàng)建數(shù)據(jù)庫。因?yàn)檫@是第一步，所以我們不需要羅列的很詳 細(xì)，在之后的步驟里，我們會(huì)逐步改進(jìn)和完善信息內(nèi)容。例如一篇文章的信息內(nèi)容主要有：文章標(biāo)題、文章正文、文章作者、發(fā)布時(shí) 間、所屬分類。初始的功能需求只有這些信息內(nèi)容， 但是在之后的功能規(guī)劃中逐 漸更加細(xì)致的考慮時(shí)，可能會(huì)增加或者刪減，因此第一步我們不用刻意的追求信 息的全面。羅列信息內(nèi)容的方式有很多種，文本形式、思維導(dǎo)圖形式等等都可以，最主 要的是能夠清晰易懂，我最常用的方法就是思維導(dǎo)圖，因此我稱這一步為信息結(jié) 構(gòu)圖。2、梳理需求（產(chǎn)品結(jié)構(gòu)圖和用戶流程圖）：當(dāng)我們對產(chǎn)品的信息結(jié)構(gòu)了解后，我們就需要規(guī)整腦

3、海中的產(chǎn)品需求，讓想 法更加結(jié)構(gòu)化，因此這一步是梳理產(chǎn)品的需求。我們首先要羅列出產(chǎn)品的頻道及 頁面（產(chǎn)品結(jié)構(gòu)圖），其次再基于產(chǎn)品結(jié)構(gòu)圖梳理出頻道及頁面中的功能，并延伸 構(gòu)建出用戶的操作流程（用戶流程圖）。以上兩步是為了讓我們在撰寫產(chǎn)品需求文檔之前能夠?qū)Ξa(chǎn)品有一個(gè)全面的 了解，類似鳥瞰式的一目了然，也方便調(diào)整完善。3、原型設(shè)計(jì)（手繪原型，灰模原型，交互原型）:當(dāng)我們逐漸清晰了產(chǎn)品的需求后，并梳理了產(chǎn)品的各個(gè)頻道及頁面，那么這一步就要開始驗(yàn)證這些想法的具體界面表現(xiàn)和方案的可行性了。首先我建議通過手繪的形式快速在草紙上繪制出產(chǎn)品的原型，推演和討論方案的可行性，當(dāng)有一定的進(jìn)展之后，我們再通過軟件工具進(jìn)

4、行更深入的設(shè)計(jì)。 移 動(dòng)產(chǎn)品可以考慮灰模原型，網(wǎng)站產(chǎn)品可以考慮交互原型，對于這兩種原型方式， 無論是移動(dòng)產(chǎn)品還是網(wǎng)站產(chǎn)品都可以使用，具體取得于你的個(gè)人習(xí)慣和團(tuán)隊(duì)要 求。對于產(chǎn)品經(jīng)理來說，原型設(shè)計(jì)是為了幫助我們細(xì)致的考慮方案，并論證方案 的可行性，同時(shí)也是為了避免產(chǎn)品宣講時(shí)，抽象的語言描述導(dǎo)致聽眾理解困難和 理解偏差。4、撰寫文檔（PRD文檔）：當(dāng)我們通過以上三個(gè)大的步驟之后，我們就已經(jīng)非常清晰產(chǎn)品的需求了，一 般情況下，通過原型加描述的方式就已經(jīng)完成了 PRD文檔的目的（很多產(chǎn)品經(jīng)理 直接使用Axure制作PRD）。當(dāng)然也會(huì)有一些個(gè)人或團(tuán)隊(duì)的要求不一樣， 對PRD文檔有特定的規(guī)范標(biāo)準(zhǔn)， 這類情

5、況可能是需要存檔歸類。無論什么樣的規(guī)范標(biāo)準(zhǔn)，PRD文檔的目的都是相近的，因此功能描述的方式也是相似的，所以在這里我分享了三種撰寫PRD 文檔的方式5、用例文檔（UML用例圖、流程圖）:產(chǎn)品需求文檔（PRD）的寫作方法的補(bǔ)充文章，主要講解PRD文檔中的重 要輔助文檔“用例文檔”產(chǎn)品需求文檔的寫作（一）-寫前準(zhǔn)備（信息結(jié)構(gòu)圖）賄準(zhǔn)気就是準(zhǔn)備失敗一 _ _ 一I1I當(dāng)我們初次接觸產(chǎn)品需求文檔時(shí)，首先會(huì)從網(wǎng)絡(luò)上尋找產(chǎn)品需求文檔模板，希望從中了解和學(xué)習(xí)具體的寫作要求，但實(shí)際上，現(xiàn)在網(wǎng)絡(luò)上絕大部分的PRD文檔都是與實(shí)際工作不相符的，或者說是復(fù)雜的。前幾天一位從事產(chǎn)品類工作的朋友， 發(fā)來一份他寫的產(chǎn)品需求文

6、檔目錄截圖 給我（下圖），當(dāng)時(shí)我就郁悶了，這些類目更像是MRD文檔，而不是PRD文檔了, 因此我決定寫幾篇講述寫作 PRD文檔的文章，分享一些我關(guān)于PRD文檔的見解 和寫作方法。*七、L品I鳳險(xiǎn)提屮1政讚鳳險(xiǎn)2合現(xiàn)風(fēng)險(xiǎn)3.架構(gòu)講估意見4妥全鳳險(xiǎn)5.戢定信息鳳除 &商笏談判的鳳臉T外部合作的風(fēng)險(xiǎn)丄£運(yùn)營碩估L船管理策略乙舞上運(yùn)營策略3.合柞接入方式S.網(wǎng)上數(shù)據(jù)桂揣龐險(xiǎn)9.不當(dāng)便用鳳險(xiǎn)10葺他侃險(xiǎn)PRD是英文Product Requirement Document的縮寫，中文的意思是產(chǎn)品 需求文檔，具體的名詞介紹大家可以詢問 Google 0PRD文檔是基于BRD、MRD 的延續(xù)

7、文檔，主要用于產(chǎn)品設(shè)計(jì)和開發(fā)使用，因此閱讀這份文檔的人群絕大多數(shù) 是設(shè)計(jì)與技術(shù)人員。在這類人群中，設(shè)計(jì)師更多依賴于原型進(jìn)行交互或視覺的設(shè) 計(jì)，因此看這份文檔的人就會(huì)偏向于技術(shù)人員。 相對于技術(shù)人員，他們不太關(guān)注 產(chǎn)品的商業(yè)需求和市場愿景，因?yàn)樵谶M(jìn)行產(chǎn)品討論立項(xiàng)時(shí)，產(chǎn)品的定義就已經(jīng)向 參與設(shè)計(jì)和研發(fā)的人員宣講過，因此技術(shù)人員更多的是關(guān)注界面、功能、交互、 元素等等內(nèi)容，因此PRD文檔是一份詳細(xì)的產(chǎn)品功能需求說明文檔，是產(chǎn)品文 檔中最底層和最細(xì)致的文檔。PRD文檔是一份沒有閑話，直入主題的功能說明文檔，因此我們在寫作時(shí)，腦海里構(gòu)思的是成品產(chǎn)品的界面功能的邏輯線框圖。在寫作這份文檔前，我們需要先做一

8、些準(zhǔn)備，把BRD、MRD的相關(guān)需求消化并融合規(guī)劃出產(chǎn)品的結(jié)構(gòu)圖。 因?yàn)檫@些準(zhǔn)備工作是屬于思維類的，所以我推薦使用思維導(dǎo)圖軟件 (Mi ndMa nager) 進(jìn)行規(guī)劃工作。規(guī)劃產(chǎn)品的第一步就是梳理出產(chǎn)品的信息結(jié)構(gòu)，有了信息結(jié)構(gòu)我們才能繼續(xù)往下規(guī)劃產(chǎn)品結(jié)構(gòu)，并且信息結(jié)構(gòu)是服務(wù)端技術(shù)人員創(chuàng)建數(shù)據(jù)庫的依據(jù)，是數(shù)據(jù) 結(jié)構(gòu)的輔助文件。對于新產(chǎn)品或者新功能，沒有人能夠比產(chǎn)品經(jīng)理更加清楚所需要的信息內(nèi)容了，因此第一步我們就需要先將這些信息羅列出來，形成結(jié)構(gòu)化（如下圖）I文章狂丈文輛霍i羽論訝址吉消鈕囂評婦r乘氏srteiiF口里石-、口廈否坯輅口3TJWI握Ezl JIP回內(nèi)訝跆問標(biāo)JE1單頁面友情鉉按H除

9、戶耆 管埋fl密碼 VflTWffiia管理功旎這張圖是以我的博客作為示例，在羅列信息結(jié)構(gòu)時(shí)，我們更多的是考慮信息 數(shù)據(jù)，因此在這一步，我們還不需要深入的考慮產(chǎn)品的界面與功能。 信息結(jié)構(gòu)的 考慮有面向前端的，也有面向后端的，具體視產(chǎn)品類型而定。例如CMS之類的程序，這類程序采用框架式開發(fā)，將功能與模板獨(dú)立，因此前端具有多變性，并且這類產(chǎn)品屬于平臺型產(chǎn)品。 針對這類產(chǎn)品，我們在規(guī)劃信息結(jié)構(gòu)時(shí)，只需要簡單的考慮一些前端的功能需求， 更多的是面向后端管理員操作進(jìn)行考慮，從后端入手規(guī)劃和羅列出所需要的信息內(nèi)容結(jié)構(gòu)。無論是什么樣的產(chǎn)品類型，無論從哪里入手，我們第一步都是先要羅列信息 結(jié)構(gòu)，因?yàn)樾畔⒔Y(jié)構(gòu)圖

10、不僅是輔助技術(shù)人員創(chuàng)建數(shù)據(jù)庫的圖表，也是輔助產(chǎn)品人 員進(jìn)行產(chǎn)品功能規(guī)劃的參考，只有對信息或數(shù)據(jù)的結(jié)構(gòu)了解，我們才能玩轉(zhuǎn)數(shù)據(jù)， 玩轉(zhuǎn)產(chǎn)品。在信息結(jié)構(gòu)轉(zhuǎn)數(shù)據(jù)結(jié)構(gòu)時(shí)，如果是針對已經(jīng)存在的產(chǎn)品而增加的新功能，那 么技術(shù)人員就需要根據(jù)這個(gè)信息結(jié)構(gòu)進(jìn)行數(shù)據(jù)庫對比，已經(jīng)存在的數(shù)據(jù)便直接調(diào) 用，如果不存在，則就需要具體的討論，確定新信息的使用途徑和以后的擴(kuò)展方 向，以便確認(rèn)是創(chuàng)建數(shù)據(jù)表還是創(chuàng)建數(shù)據(jù)字段。（雖然產(chǎn)品經(jīng)理不需要技術(shù)開發(fā)， 但是如果能夠懂技術(shù)原理和數(shù)據(jù)庫原理，非常有助于產(chǎn)品規(guī)劃和技術(shù)溝通。）信息結(jié)構(gòu)圖是產(chǎn)品層面的理解，如果要入庫這些信息，還需要進(jìn)行數(shù)據(jù)結(jié)構(gòu) 的討論。一條信息的存儲(chǔ)有很多附加屬性， 具

11、體是存成字段還是數(shù)據(jù)表，還是說 存在中間表或者關(guān)聯(lián)表，這些都需要在完成 PRD文檔后和數(shù)據(jù)庫技術(shù)人員共同 討論。討論時(shí)除了展示信息結(jié)構(gòu)圖，還要講解產(chǎn)品原型和功能需求，以便數(shù)據(jù)庫 技術(shù)人員了解產(chǎn)品意圖，方便他們做數(shù)據(jù)庫規(guī)劃時(shí)考慮到以后的擴(kuò)展。信息結(jié)構(gòu)圖是我們將概念想法形成結(jié)構(gòu)化的第一步，也是我們接下來幾步工 作的輔助文件，同時(shí)在接下來的幾步工作中，我們還會(huì)不斷的完善信息的結(jié)構(gòu)。產(chǎn)品需求文檔的寫作（二）梳理需求（產(chǎn)品結(jié)構(gòu)圖和用戶流程圖）上一篇我們將概念想法形成了信息結(jié)構(gòu)，羅列出了產(chǎn)品的所有信息內(nèi)容，現(xiàn)在我們就要依據(jù)信息結(jié)構(gòu)，開始規(guī)劃產(chǎn)品的功能需求，繪制出產(chǎn)品結(jié)構(gòu)圖和用戶流程圖。首先我們要規(guī)劃出產(chǎn)品

12、的頻道及子頻道、子模塊或子頁面。（如下圖）刊1御道子頻152枚塊元妙;*頁面】按塊元索2頁面映挾2頁面3欖塊元和反嬌嵐面1帀面元Hi 貢面元廉2換加3旅塊元童2頁自噢塊1蟲塊2反腔帀面2頁面屢塊槿塊元竈2圖注：講解一下我對于這個(gè)思維導(dǎo)圖的名詞理解1、頻道：某一個(gè)同性質(zhì)的功能或內(nèi)容的共同載體，也可稱為功能或內(nèi)容的類別。2、子頻道：某頻道下細(xì)分的另一類別3、頁面：單個(gè)或附屬某個(gè)頻道或分類下的界面4、模塊：頁面中多個(gè)元素組成的一個(gè)區(qū)域內(nèi)容，可以有一個(gè)或多個(gè)，也可以循 環(huán)出現(xiàn)（例如:文章列表）5、模塊元素：模塊中的元素內(nèi)容，以文章列表舉例：文章標(biāo)題、文章摘要、文 章發(fā)布時(shí)間，這些都是元素，都是組成模塊

13、的內(nèi)容，同時(shí)他們也是可以循環(huán)出現(xiàn) 的。元素的類型可以是：文字、圖片、鏈接等等如果你學(xué)過網(wǎng)頁設(shè)計(jì)，或者了解 Web產(chǎn)品的模板機(jī)制，你就能夠理解這些名詞了。如下圖所示，這是我的博客的首頁結(jié)構(gòu)。中間內(nèi)窖區(qū)內(nèi)齊事墳1示怛謝詁.littpy/tarKjie .nio右關(guān)1*局）內(nèi)喬換衛(wèi)2直鳥（全局）L當(dāng)我們規(guī)劃出頻道后，我們就需要以用戶的視角進(jìn)行一步一步的模擬操作， 逐漸完善產(chǎn)品的結(jié)構(gòu)導(dǎo)圖。我稱為用戶流程圖，用于展現(xiàn)產(chǎn)品經(jīng)理腦海中比較抽 象的產(chǎn)品邏輯，也是產(chǎn)品經(jīng)理對自己腦海中的產(chǎn)品想法進(jìn)行梳理的一個(gè)過程。（如下圖示例）P!站標(biāo)逾廠元皋文相副標(biāo)祂坊儺損現(xiàn)f、 蟲面模就（步IX）頁頭（全局：-搜雷曲進(jìn)/一模

14、坡元責(zé)搜索框 k揑索按迅蕪于皆杰訂閱R5S到QQ郵輜新淞微肯馬訊我葡n krss右側(cè)文車列表也可以稱為貞面首頁發(fā)布河間 文章標(biāo)麺 文章摘更 柞者 兩風(fēng)分棗 岡讀次數(shù) 標(biāo)整 評論數(shù)Web頁面示例些井拿 產(chǎn)品體驗(yàn) 產(chǎn)r£ia計(jì) 天下雜侃示例網(wǎng)站：httpJftangjie.me右側(cè)（全局）文草列表舟思齡想 我的兇印 職場人生熱門丙展【全局:版収信邑 統(tǒng)計(jì)猶碼標(biāo)賽其矗內(nèi)簾友晴鏈揍這樣做的目的就是梳理產(chǎn)品邏輯，讓我們清楚的知道產(chǎn)品有幾個(gè)頻道，頻道 下面有沒有子頻道或者有多少個(gè)頁面， 這些頁面里又有哪些功能模塊，這些功能 模塊里又有哪些元素。這樣我們就模擬了用戶的整個(gè)操作流程，逐一的將產(chǎn)品的

15、所有功能界面操作了一遍，也列出了產(chǎn)品結(jié)構(gòu)圖和用戶流程圖。用戶皂尢憲汀冊快燙登錄ftiftQQ述範(fàn)OpenK征舒浪微1W會(huì)員登錄（示例）-用戶嘗辻坯引箱確認(rèn)汀冊按翱住冊成勒完禪證咨返朋靈沽鑼郵箱找回密閔-猛訂瑪 請認(rèn)找同按鉗有了這份結(jié)構(gòu)導(dǎo)圖，我們可以對產(chǎn)品進(jìn)行鳥瞰式考慮和完善，當(dāng)有問題時(shí)， 修改起來也比原型和文檔方便很多。這樣的方法同樣適用于移動(dòng)互聯(lián)網(wǎng)產(chǎn)品的規(guī) 劃，并且比起 Web產(chǎn)品更加容易梳理產(chǎn)品結(jié)構(gòu)。以上講的都是前端面向?yàn)g覽者的用戶流程， 但是如果規(guī)劃的是一個(gè)平臺級的 大眾化產(chǎn)品就不能從前端進(jìn)行梳理了，例如 CMS、BBS之類的程序，他們采用 框架式開發(fā)，將功能與模板獨(dú)立，前端的界面布局僅

16、僅是通過模板機(jī)制的標(biāo)簽調(diào) 用，因此在做產(chǎn)品規(guī)劃時(shí)，前端是涉及不到的，也不應(yīng)該從前端入手。遇到CMS 類平臺產(chǎn)品的規(guī)劃，也同樣使用這樣的方法，只不過是從后臺入手模擬管理員的 流程。PRD文檔寫前準(zhǔn)備就是讓我們先通過思維導(dǎo)圖梳理思路， 明白產(chǎn)品有多少個(gè) 頻道、有多少個(gè)頁面、頁面有多少個(gè)功能模塊、功能模塊有多少個(gè)元素，逐步的 將腦海里的想法明確梳理成結(jié)構(gòu)。 雖然已經(jīng)明確了產(chǎn)品的結(jié)構(gòu)，但是這樣的思維 導(dǎo)圖對于設(shè)計(jì)與技術(shù)人員依舊是抽象的， 他們?nèi)匀豢床欢?，同時(shí)對于產(chǎn)品經(jīng)理自 己來說，這樣的結(jié)構(gòu)圖也是沒有經(jīng)過推演的，具體是否符合產(chǎn)品邏輯，是否符合用戶體驗(yàn)，都是沒有深思過的，因此我們接下來就要進(jìn)行原型設(shè)計(jì)，

17、 開始具體的 考慮結(jié)構(gòu)方案的可行性。下一篇我將講解原型設(shè)計(jì)的幾種方法，并說明為什么原型設(shè)計(jì)要早于產(chǎn)品需 求文檔的撰寫。產(chǎn)品需求文檔的寫作（三）原型設(shè)計(jì)（手繪原型，灰模原型，交互原型）財(cái)rnd0 GJieatKUCJI IOFiinnnc loi rrfIrf-E000G0IIf *&EL«Jt&忸-)Numcf 匚勺gl窣昨心二T左a上一篇文章我們通過思維導(dǎo)圖將想法進(jìn)行了結(jié)構(gòu)化梳理，接下來我們就需要進(jìn)行方案的可行性推演，驗(yàn)證產(chǎn)品功能是否可行，預(yù)估項(xiàng)目要花多少人力物力， 因此我們就要通過原型設(shè)計(jì)進(jìn)行相關(guān)需求的論證。一開始就撰寫PRD文檔，我們很難對產(chǎn)品進(jìn)行各方面的評估，

18、也無法得知方案的可行性，并且無法直觀細(xì)致 的考慮產(chǎn)品。原型設(shè)計(jì)是幫助我們更細(xì)致的思考，并做各項(xiàng)需求的評估，同時(shí)也是將自己腦海里的想法進(jìn)行輸出，通過原型設(shè)計(jì)后，我們就可以進(jìn)行產(chǎn)品宣講了。相對于 之前抽象的文字描述，原型則更加清晰產(chǎn)品的需求，設(shè)計(jì)和技術(shù)人員或者老板也 能夠更加直觀的了解到產(chǎn)品意圖。原型設(shè)計(jì)是將結(jié)構(gòu)化的需求進(jìn)行框架化，因此原型也被稱為線框圖，具體的 表現(xiàn)手法有很多種，相關(guān)的輔助軟件也有很多，例如：Axure RP、BalsamiqMockups、UIDesigner 等等。當(dāng)?shù)搅嗽驮O(shè)計(jì)這一步時(shí)，已經(jīng)不僅僅是構(gòu)思了，我們需要更加深入的了解 每個(gè)頁面上的元素和這些元素的屬性。例如按鈕元

19、素，我們就需要考慮這個(gè)按鈕 的功能，并且這個(gè)功能操作后帶給后端和前端的反饋。舉例這個(gè)按鈕是注冊會(huì)員 按鈕，用戶操作后，第一步邏輯是驗(yàn)證用戶輸入的信息是否合法，不合法則給出前端反饋；合法則和后端通信驗(yàn)證是否已經(jīng)存在同樣信息，已經(jīng)存在則給出前端反饋，不存在則進(jìn)入下一步，注冊成功；注冊成功后的反饋是跳轉(zhuǎn)頁面，還是彈 出層提示用戶完善資料，這些都是需要更詳情的考慮的。當(dāng)然這些更細(xì)致的思考 是留在需求文檔撰寫時(shí)的，而此時(shí)我們需要做的就是把這些元素通過原型表現(xiàn)出 來。原型設(shè)計(jì)的表現(xiàn)手法主要有三種：手繪原型、灰模原型、交互原型1、手繪原型因?yàn)樵鸵脖环Q為線框圖，因此手繪是最簡單直接的方法，也是最快速的表 現(xiàn)

20、產(chǎn)品輪廓的手法（如下圖）手繪原型在初期驗(yàn)證想法時(shí)非常高效，也方便討論和重構(gòu)，同時(shí)也適合敏捷開發(fā)時(shí)快速出原型。2、灰模原型灰模原型是由圖形設(shè)計(jì)軟件制作而成，我最常用的軟件是PhotoShop 和FireWorks ,相對手繪原型，灰模更加清晰和整潔，也適用于宣講，但是需要產(chǎn)品人員熟悉使用圖形設(shè)計(jì)軟件（如下圖）sumUmACEO*f?«i&A«SBS:熬I解Wu CEOAiil MB膵，擁林梯阻rwi血 MiMerHulu 住DM 害拉螂son Kih r!m£AlllKEOKtti&A 耶”黨柏肆浄廉観任帝時(shí)CEO野舒黑空當(dāng)蟲肋鸚 LeMn仞M汩鼠而

21、聲文審JB仍疥可曲*11虎2牡鼻（nACEOMftABMS:和與Huki CEOAill imr.制tDLkxwE罰 Milterimjlu住0耳葦圧其巾5"曲沁班靈豐人飆虎撫期整惺逸人営 單.kU挪卩好丿壬愜K1EO粵苗-黑丸£申：站到 LtvmwhftjWS,.雨養(yǎng)愛歡釀仍口剛?cè)lJflmXEQOMftCEO*m£3ASM«S: UiHulu 匚 EO©） 即擊，綁"珂的養(yǎng)納矯桶陽購腦獅詡iPOfUHulu 匸E0E 石珂麗血爐 KUSr7T®iffAflrtCEOarYWiAS 磯枇理沁亞曲町匚中童妬岬曲Ltvinw

22、hnWS+而氮如銀們有可険斉it廉琳加：中，annm畬 米tnHulu CEOAii酒爐 將.新聞團(tuán)的刊（5老釉 （J&naltinn Miile<>fnHutu CtOftHICiTUiion Kib門規(guī)頑人IBctCEOBf¥WA?5a. XOS'i'.iftfiCEO 劌前少.交 關(guān)創(chuàng)Mas LT陽Qfw汨奩*頁ftJt察15仍TT可IE成7）雅冊 Aceo,iSKf PddeLfi雅疏.城測竝.由旨制.主吸刪的朋 產(chǎn)品阿況兗関寫悻申著于厲護(hù)盤計(jì)的彌h: Mtp:/iang|.ne*戚乳jftCEQM 舷人各卑帕:MMW Huh CEO人a】

23、滯慝耶-聊眩嗥/的弄?jiǎng)?GrHHlKJQffiatlun MillQHilu CEOAC 育協(xié)卿3踽“弼S進(jìn)小鷹CEOfl性 慄話人苦屯瀕翹韻冊睢細(xì)KEO ?Ke 舉玄£恩知妙“塚乂亦職友+ %近士 幼鹽苛舷為離撓癢久6 a灰模原型常用于移動(dòng)互聯(lián)網(wǎng)產(chǎn)品的設(shè)計(jì)，由于移動(dòng)產(chǎn)品的交互需求復(fù)雜，原 型設(shè)計(jì)軟件難以高效的表達(dá)需求，因此移動(dòng)互聯(lián)網(wǎng)產(chǎn)品的設(shè)計(jì)通常是灰模原型加交互文檔組合成PRD文檔。（過幾天我再詳情講講移動(dòng)互聯(lián)網(wǎng)的產(chǎn)品設(shè)計(jì)）融名稱 倚童.ill Bell洛杉磯東部莫雷諾市4:20 PM購 teAW*樓盤均價(jià)：砧000元周邊二手房均價(jià)：&4200元iFtLh冃±a

24、0.07% .剛匕去年上漲W ,61% a租劇介格裁月單間：8S0td二居：4200元居；14007L三雖;54007G車月均價(jià):4M5元席，比上月下鐵1163、交互原型交互原型是使用原型設(shè)計(jì)軟件完成的原型，常用軟件是Axure RP,通常情況交互原型的設(shè)計(jì)僅早于 PRD文檔，是產(chǎn)品經(jīng)理想法推演的最后一步。通過 Axure PR之類的交互原型軟件制作出來的產(chǎn)品原型，在功能需求與交互需求的 表現(xiàn)和正式產(chǎn)品幾乎是一致的，所以有時(shí)交互原型也被稱為產(chǎn)品Demo版。通常情況下交互原型是產(chǎn)品經(jīng)理與交互設(shè)計(jì)師共同討論確定，然后由交互設(shè)計(jì)師制作，但是絕大多數(shù)的公司是沒有交互設(shè)計(jì)師這個(gè)職位的，因此這類工作最終是

25、由產(chǎn)品經(jīng)理來負(fù)責(zé)的。（很多公司給視覺設(shè)計(jì)師的職稱是交互設(shè)計(jì)師，但本 質(zhì)還是視覺設(shè)計(jì)）關(guān)于Axure PR制作交互原型我在這里就不多介紹了，網(wǎng)絡(luò)上有很多這類的 教程，我個(gè)人建議是學(xué)習(xí)Axure PR時(shí)，隨便了解一下網(wǎng)站模板的結(jié)構(gòu)，這樣可 以幫助你更加結(jié)構(gòu)化使用Axure PR。以上三種方法并不是漸進(jìn)的流程，而是三種原型設(shè)計(jì)的方法，具體取決于你 的產(chǎn)品需求和團(tuán)隊(duì)要求。產(chǎn)品經(jīng)理設(shè)計(jì)原型是為了幫助自己更細(xì)致的思考方案的可行性，也是為了給別人講解的時(shí)候，讓聽眾能夠清晰直觀的了解產(chǎn)品，同時(shí)也是為了確保產(chǎn)品在執(zhí) 行過程中，是按產(chǎn)品經(jīng)理最初設(shè)想的需求和期望完成的。因此產(chǎn)品經(jīng)理的原型是沒有很高的要求的，只要對方

26、能夠聽懂看懂，使用手繪原型是最高效率的方法。產(chǎn)品需求文檔的寫作（四）-撰寫文檔（PRD文檔）前三篇文章我們逐步梳理了產(chǎn)品的信息結(jié)構(gòu)、框架結(jié)構(gòu)、界面結(jié)構(gòu)（原型）,這一步我們就要根據(jù)之前完成的工作，開始正式撰寫產(chǎn)品需求文檔了（PRD文檔）。通過之前的準(zhǔn)備工作，我們更加清楚了產(chǎn)品的需求，并細(xì)致的考慮了方案的 可行性，從而減少與避免了撰寫文檔時(shí)容易忽略的細(xì)節(jié)黑洞。PRD文檔沒有標(biāo)準(zhǔn)的規(guī)范，也沒有統(tǒng)一的模板，每個(gè)公司都不一樣，并且每 個(gè)人也不一樣，這個(gè)取決于個(gè)人習(xí)慣和團(tuán)隊(duì)要求。雖然PRD文檔沒有標(biāo)準(zhǔn)的規(guī)范，但是有兩項(xiàng)是必不可少的，那就是文件標(biāo)識和修改記錄。文檔在撰寫過程中， 我們可以自行不斷的修改完善，

27、但是如果正式發(fā)布或交給團(tuán)隊(duì)其他成員后， 一旦 有了修改，為了文檔的同步，我們就需要標(biāo)注出文檔的修改內(nèi)容，備注修改記錄。 關(guān)于文件標(biāo)識和修改記錄，大家的格式都大同小異（如下圖）。產(chǎn)品需求文檔http:/tangjie.me產(chǎn)品名稱文件狀態(tài)I1草牘I V1正式發(fā)布11正在修改文件標(biāo)識tiPad當(dāng)就版本；V3X作考；宙木完成日期h2012-5-1序號版本編寫/樓訂說明修訂人桂訂日期備注1V3.0刨建丈檔唐杰2012 5-28綠底為提要惟息2芫善歸整唐杰2012-6-1紅色文字為后頻修改內(nèi)容PRD文檔的形式常見的有以下三種：Word、圖片、交互原型一、Word這是傳統(tǒng)意義上的PRD文檔，主要有四個(gè)部分

28、組成（具體視你的產(chǎn)品要求進(jìn) 行劃分），分別是：結(jié)構(gòu)圖、全局說明、頻道功能、效果圖。（在第一篇文章里我 有講過，PRD文檔的閱讀者更多是偏向于技術(shù)人員，因此 PRD文檔目的性很明 確，就是要描述產(chǎn)品的功能需求，所有 PRD文檔是沒有關(guān)于市場方面的描述， 同時(shí)我也建議大家盡量減少不必要的文字，在能夠讓閱讀者看懂并且了解產(chǎn)品意 圖的情況下，文字越少越好。這主要是因?yàn)榻^大多數(shù)人是沒有足夠耐心認(rèn)真看完 PRD文檔的，因此我們要盡量減化文檔內(nèi)容。）1、結(jié)構(gòu)圖：、信息結(jié)構(gòu)圖：主要是輔助服務(wù)端技術(shù)人員創(chuàng)建或調(diào)整數(shù)據(jù)結(jié)構(gòu)的參考文件、產(chǎn)品結(jié)構(gòu)圖：主要是輔助設(shè)計(jì)和技術(shù)開發(fā)人員了解產(chǎn)品的全局結(jié)構(gòu)，他和用戶流程圖不一樣

29、，產(chǎn)品結(jié)構(gòu)圖只是羅列出產(chǎn)品的頻道和頁面。2、全局說明：主要講解產(chǎn)品的全局性功能的說明，例如網(wǎng)站產(chǎn)品的頁面編碼、用戶角色，移動(dòng)產(chǎn)品的緩存機(jī)制、下載機(jī)制，這類全局性功能的說明。這里 我舉一個(gè)移動(dòng)產(chǎn)品的“狀態(tài)維持與恢復(fù)”的例子，示例如下。狀態(tài)的維持與恢復(fù)當(dāng)用戶退出產(chǎn)品時(shí)（誤操作、Home鍵、鎖屏、自動(dòng)關(guān)機(jī)），產(chǎn)品需要維持用戶 操作前的狀態(tài)，當(dāng)用戶返回產(chǎn)品時(shí)仍可以恢復(fù)到之前狀態(tài)，并繼續(xù)使用。維持狀態(tài)包括流程操作、信息瀏覽、文本輸入、文件下載。鎖屏狀態(tài)時(shí)，如果用戶在產(chǎn)品中有下載任務(wù)時(shí)，仍然保持下載。產(chǎn)品需求文檔示例:（見附件PDF）3、頻道功能：以頻道為單位，頁面為子項(xiàng)，分別描述產(chǎn)品的頻道、頁面及 頁面

30、模塊元素的功能需求（格式如下）。示例格式1、頻道名：頻道介紹及需求說明2、頁面1 :頁面介紹及需求說明、頁面模塊1 :模塊功能需求說明、頁面模塊1-元素1 :功能說明、頁面模塊1-元素2 :功能說明、頁面模塊2 :模塊功能需求說明在撰寫功能需求時(shí)，我們需要考慮用戶的流程，例如一個(gè)“完成”按鈕，我們需要描述他完成后，系統(tǒng)要不要給出反饋提示（反饋提示是什么樣的形式反饋, 內(nèi)容顯示成什么，有沒有內(nèi)容需要調(diào)取數(shù)據(jù)庫），或者要不要跳轉(zhuǎn)頁面（跳轉(zhuǎn)到哪 個(gè)頁面，這個(gè)頁面是其他頻道頁面，還是這個(gè)功能的子頁面，如果是子頁面就需 要再描述這個(gè)子頁面的模塊及元素內(nèi)容）。4、效果圖：效果圖是由設(shè)計(jì)師完成的產(chǎn)品圖，和實(shí)

31、際開發(fā)完成的產(chǎn)品保真 度一致。二、圖片圖片形式的PRD文檔是基于效果圖的說明文件，將傳統(tǒng) Word形式的功能 需求說明標(biāo)注在效果圖上，這種方式經(jīng)常使用在移動(dòng)互聯(lián)網(wǎng)領(lǐng)域，實(shí)際上是圖文 形式的交互需求文件，只是在此基礎(chǔ)上更深入的描述出功能需求。對于圖片形式的PRD文檔，我們只需要另外再描述一下全局說明，其他頻 道頁面的需求直接以圖片形式展示，這種方式相對于Word文檔的純文字更加生動(dòng)易讀并且直觀，因此有一些產(chǎn)品經(jīng)理非常喜歡用這種方式代替Word形式的PRD文檔。、交互原型這里指的交互原型就是上一篇文章講的原型設(shè)計(jì)，使用 Axure PR之類的交 互原型設(shè)計(jì)軟件制作出來的產(chǎn)品原型非常真實(shí)和直觀，并且

32、原型軟件還支持元素 標(biāo)注和導(dǎo)出 Word文檔，因此很多產(chǎn)品經(jīng)理都喜歡使用 Axure PR來代替Word 完成PRD文檔。當(dāng)我們通過Axure PR制作出產(chǎn)品原型后，實(shí)際上他已經(jīng)是很完善的產(chǎn)品 Demo 了，因此我們只需要加上元素的標(biāo)注，在標(biāo)注中說明功能需求，這樣導(dǎo) 出的HTML文件相比Word文檔更直觀易懂，是非常高效的產(chǎn)品需求說明方式。無論你采用哪種方式產(chǎn)出需求文檔， 最終的目的都是為了方便團(tuán)隊(duì)成員理解 產(chǎn)品的意圖，因此哪種方法能夠避免細(xì)節(jié)黑洞，高效完成產(chǎn)品的設(shè)計(jì)和研發(fā)，那 么這種方法就是最有效的方法。好了，關(guān)于產(chǎn)品需求文檔(PRD)的寫作的介紹寫完了，一共四篇文章， 希望能夠幫助到你，如

33、果覺得文章中有什么錯(cuò)誤或者有疑問，歡迎評論留言產(chǎn)品需求文檔的寫作（五）用例文檔（UML用例圖、流程圖）在產(chǎn)品和技術(shù)領(lǐng)域里都有 UML的技能知識，而對于產(chǎn)品人員的 UML貝U更 多的是指用例圖，也就是我所稱呼的用戶流程圖。在講PRD文檔寫作的第二篇文章里，我提到了用戶流程圖的制作，實(shí)際上用戶流程圖是我在產(chǎn)品規(guī)則的初期 對用例圖的一種結(jié)構(gòu)化的表達(dá)方式，由于以結(jié)構(gòu)化的方式描述用例太抽象， 缺少 邏輯性表達(dá)，并且那篇文章更偏向于功能性用戶流程，還不是實(shí)際意義上的用例， 因此今天我補(bǔ)文一篇，細(xì)講一下 UML用例圖和用例文檔。用例文檔是由多個(gè)用例組成的一份文檔，主要用于技術(shù)開發(fā)與測試使用，他 是PRD中的重要輔助文檔，用于講解某個(gè)環(huán)節(jié)的功能邏輯，例如用戶注冊、活 動(dòng)報(bào)名等等功能都是需要用例輔助說明的。用例文檔的寫作時(shí)間在原型設(shè)計(jì)之 后，通常和PRD文檔同步撰寫。用例文檔中有兩個(gè)關(guān)聯(lián)文件，分別是用例圖和流程圖。用例圖是UML的一種類圖表現(xiàn)方式，是從用戶角度描述產(chǎn)品功能，并指出該用戶在產(chǎn)品各功能中的操作權(quán)限。流程圖是