原型和PRD是每個產(chǎn)品經(jīng)理都必須要掌握的基礎(chǔ)技能。但之前的原型和PRD都是分開的，如果在原型上直接寫上需求，是否能提高工作效率？這篇文章，我們看看作者的分享。

畫原型圖是產(chǎn)品經(jīng)理的基本功，但很多PM畫了幾年的原型，仍然不能高效、準確的輸出一份原型。很多人都在糾結(jié)PRD應(yīng)該怎么寫，寫到什么程度，粗了怕遺漏需求，細了沒時間不說，別人還不看。

作為產(chǎn)品經(jīng)理，我們到底應(yīng)該輸出一份怎樣的PRD，又如何做到最“低成本”的方式，輸出最輕便、完整的PRD？

01 Axure版PRD 還是 Word 版PRD

到底能不能直接用auxre輸出PRD這個問題，很容易引發(fā)爭論。

在回到這個問題之前，我們再明確一下PRD的目的和作用：

為了向團隊說明業(yè)務(wù)解決方案，并試圖讓相關(guān)方都能理解而且支持這一解決方案，以及在開發(fā)過程中有條不紊的推進方案的落地執(zhí)行。

PRD的問題不在于如何寫而在于讓團隊能夠理解業(yè)務(wù)，以及開發(fā)過程中如何被傳遞與執(zhí)行。真正困擾我們的是一個很尷尬的現(xiàn)象：

“寫多了大家未必都會看；寫少了又怕別人不懂”。

關(guān)于PRD，最開始幾乎所有人都是用WORD，我們也能很容易搜索到各種模板。一般說來，PRD都是從目的、范圍、背景、功能需求、非功能需求這樣一種邏輯組織語言，如下圖所示，最終會形成一份結(jié)構(gòu)清晰的需求規(guī)格說明書。

PRD 結(jié)構(gòu)圖

在描述需求的時候，通常用“輸入”—->”輸出”的邏輯關(guān)系闡述用戶需求，并且用“表格”來呈現(xiàn)完整的需求列表。

WORD輸出的文檔，最大的優(yōu)勢就是有一個清晰的目錄大綱，一眼過去就能大致明白這一個“項目”的范圍，要做那些事情。

之所以今天很多人在反對這種格式文檔，原因在于這種“項目交付式”的需求規(guī)格說明書已經(jīng)跟不上節(jié)奏，其撰寫和閱讀的效率太低，寫和讀都非常的痛苦。而且非常局限，很難真正理解一個產(chǎn)品的全貌，傳統(tǒng)的軟件工程面向的是項目交付，而不是我們今天大力倡導(dǎo)的以用戶為中心的產(chǎn)品思維。

曾經(jīng)負責(zé)過一個項目，應(yīng)甲方要求，洋洋灑灑輸出六萬余字的PRD（一式三份打印出來，推在桌上蔚為壯觀），依然感覺意猶未盡。這種巨幅的PRD文檔，在傳統(tǒng)軟件領(lǐng)域，極為普遍，但尷尬的是，這種文檔往往寫完就束之高閣。

對一份PRD來說，沒有什么比可讀性還重要的事情了。

PRD的作用就是為了幫助能夠閱讀到它的每一個人，都真正理解并推動執(zhí)行。

是時候拋棄線性描述的WORD了，互聯(lián)網(wǎng)下的產(chǎn)品經(jīng)理需要更高效的專業(yè)工具和工作方式。

從現(xiàn)在出發(fā)，我們的目的是讓你的PRD相對輕便，別人愿意看，自己也不太“痛苦糾結(jié)”。

我們要讓團隊的每個人很清晰的知道當下處于什么境況，我們要在什么時候做到什么樣子。

可以參考以下的方式來設(shè)計一個清晰的文檔結(jié)構(gòu)：

• 版本摘要：為什么要做這個版本，要做什么，什么時候做好；
• 變更日志：讓你的團隊成員知道你“又做了什么手腳”；
• 產(chǎn)品原則：通用性的規(guī)范，需要遵從什么標準，什么要求，做成什么樣；
• 功能結(jié)構(gòu)：“用圖來描述”你現(xiàn)在想要改動“個人資料”模塊還是訂單頁面；
• 關(guān)鍵流程：涉及到的關(guān)鍵業(yè)務(wù)流程；
• 故事板與原型：用場景化的語言描述某個功能是什么，配合適當?shù)睦?，讓團隊成員真正理解這個場景下的用戶行為。

02 設(shè)計一個清晰的摘要追蹤版本

PRD的目的就是為了在團隊內(nèi)外的高效溝通，也就是，作為承上啟下的溝通工具和載體，PRD文檔會有強烈的指引性和歸檔性，PRD的版本管理就至為重要。

版本摘要是一個非常好的方式，清晰的列出當前的版本號，版本范圍和需求變更過程，以保障產(chǎn)品需求的及時同步和追溯。

你的目的只有一個，就是讓所有人都能一眼就明白這個版本的概貌，能清晰的知道要做什么，也知道你又改了什么，更重要的是，這個結(jié)構(gòu)的第一步描述了整個版本為什么要做的原因——需求的出處，以及產(chǎn)品的價值。

Axure原型需求文檔演示及下載地址：https://g11o9b.axshare.com

你可以用內(nèi)聯(lián)框架設(shè)計要給主頁，閱讀者可根據(jù)你的設(shè)計快速理解整個項目

通過定義版本摘要，不僅可以作為團隊版本迭代的指南，也是進度跟蹤的工具。引領(lǐng)整個團隊正確的理解項目。視不同的情況，不同的產(chǎn)品（業(yè)務(wù)）類型，版本的摘要有完全不同的內(nèi)容，如果是甲方的項目，還可以把項目架構(gòu)，溝通機制都作為一個摘要來傳遞。

還有一種很不好的情況就是讓原型文件通過QQ、郵件進行分享。

實際上，你完全可以在內(nèi)部搭建一個小的站點，讓整個團隊“在線”訪問axure原型，即可實時同步整個進度。

類似堅果云等同步工具也是一個方式好的方式。

基本原則就是：不要讓原型文件滿天飛。

03 任何一個產(chǎn)品迭代過程都需要有明確的里程碑計劃

里程碑計劃，簡單的來說就是什么時候能夠到達目的地。

很多公司可能配置了專職的項目經(jīng)理，產(chǎn)品經(jīng)理只需要獲取到項目的推進計劃并跟蹤結(jié)果的輸出即可。

而在一些創(chuàng)業(yè)團隊，產(chǎn)品經(jīng)理有時候會兼顧項目的角色，作為整個項目的牽頭人，項目的里程碑計劃非常重要。

在這種工作環(huán)境下，需要保證整個團隊（從上到下）對進度節(jié)點的一致認可和知悉，并盡可能的嚴格按照計劃來執(zhí)行。否則，極容易出現(xiàn)場面失控，一口又一口結(jié)結(jié)實實的鍋，會讓PM們吃不完兜著走。

產(chǎn)品經(jīng)理一定要有強烈的結(jié)果意識，時刻關(guān)注項目的進度情況，并盡早啟動相關(guān)的風(fēng)險預(yù)備計劃，時刻準備應(yīng)對可能的失控局面。

具體到項目進度的編制、執(zhí)行和控制，是另外一個話題，暫且略過。

04 準備應(yīng)對需求變更，但不要想著去控制變更

任何人寫的PRD，都不能確保覆蓋所有場景，更不能確保沒有變更，變更是正常的，沒有變更則是一種意外。

（題外話，對產(chǎn)品經(jīng)理來說，自己能意識到這一點沒有什么用，關(guān)鍵是能打造一個“敢”于變更的環(huán)境）。

所有應(yīng)對和管理需求變更的“奇淫技巧”，首先要的是能夠從心理上有所準備，能夠擺正心態(tài)正確面對需求的變更，然后才是通過恰當?shù)氖侄喂芾硇枨笞兏灰胫タ刂谱兏?，一字之差之間有很大的不同。

對于大型的項目，建議把需求變更作為一個獨立的模塊進行管理，并一定要建立完善的需求變更流程和環(huán)境，一旦需求變更失控，則整個項目就會處于一種混亂狀態(tài)，甚至直接導(dǎo)致項目的失敗。

產(chǎn)品經(jīng)理應(yīng)該成為需求的唯一出口。理想的情況是，沒有被產(chǎn)品經(jīng)理接受的變更不得進入實施階段。

要做到這一點，不但要求產(chǎn)品經(jīng)理在專業(yè)技能方面比較過硬，也需要產(chǎn)品經(jīng)理想盡辦法打造一個合理的項目環(huán)境。而后者，往往更重要。

一定要及時記錄所有的變更，包括那些不被采納的變更。

05 設(shè)計一個全局的產(chǎn)品規(guī)范

產(chǎn)品經(jīng)理應(yīng)該盡早制定一份產(chǎn)品的基本原則，什么能做，什么不做。當然，這里可以完整的描述從體驗角度需要遵從的基本規(guī)范。

這里沒有太多的建議和參考，你的產(chǎn)品原則，既可以是戰(zhàn)略性的，也可以是產(chǎn)品功能性的，可以大到?jīng)Q定產(chǎn)品方向，可以小到顏色字體。

制定產(chǎn)品規(guī)范（原則）的目的，是為了保障產(chǎn)品的體驗一致性。更重要的是，保護你的產(chǎn)品不出現(xiàn)意外。

產(chǎn)品經(jīng)理應(yīng)該盡可能的從多維度制定規(guī)則，但不要過于復(fù)雜。

越是方向上的東西越是要簡單。例如微信，如果傾向于發(fā)信者的立場，在后續(xù)的版本過程中更多的維護發(fā)信者的體驗；如果是傾向于收信者的立場，則一定在保障發(fā)信者的體驗。

任何產(chǎn)品都很難照顧到產(chǎn)品的所有角色，必須明確產(chǎn)品的側(cè)重點是什么。

不滿足所有用戶的產(chǎn)品才是好產(chǎn)品。

06 設(shè)計一個靠譜的產(chǎn)品結(jié)構(gòu)

想象一棟樓，你能看到有地基、柱子、橫梁、墻面、屋頂，這個樓之所以不會輕易垮塌，就是因為這些部件構(gòu)建了一種穩(wěn)固的結(jié)構(gòu)——物理架構(gòu)。你一定很快就能想象得到，房子要能適合居住，就得有進排水（系統(tǒng)），得有電力供應(yīng)（系統(tǒng)）等等，這就從邏輯層來構(gòu)建一棟樓的結(jié)構(gòu)。

從這樣一個粗糙的描述里面，你應(yīng)該能夠理解，所謂架構(gòu)，就是把各個部件進行歸納匯總，提煉抽象，并通過適當?shù)逆溄臃绞酱蛟斐梢粋€穩(wěn)定的形狀，滿足人們的實際需要。

在你面對一個產(chǎn)品/一個需求的時候，應(yīng)該能在腦海里勾畫出模型，什么東西是4個桌腿，什么東西是一個桌面，4條腿和一個桌面如何共同構(gòu)建和支撐這個業(yè)務(wù)的穩(wěn)定運行。

通常情況下，一份PRD中，只需從物理結(jié)構(gòu)層詳盡的描述“功能結(jié)構(gòu)”即可。

實際情況是，有的時候你并不需要畫一個結(jié)構(gòu)圖，因為產(chǎn)品的結(jié)構(gòu)可能已經(jīng)千年不變了，這個版本也可能僅僅是修復(fù)一些問題，甚至只是把方形的用戶頭像改成圓形——因為你的老板覺得好看。

產(chǎn)品架構(gòu)不僅是能支撐當下的業(yè)務(wù)，也要能具備適度的擴展性和容錯性。

07 流程，還是流程

越是復(fù)雜的系統(tǒng)，越是推薦把流程圖做一個目錄，不但是引導(dǎo)閱讀者，而是檢查遺漏的方法。

產(chǎn)品經(jīng)理在繪制流程圖的時候，盡可能的遵從通用的規(guī)范，并養(yǎng)成養(yǎng)好的習(xí)慣。好的流程圖，可以快速讓整個團隊熟悉理解業(yè)務(wù)，并優(yōu)化業(yè)務(wù)。

梳理業(yè)務(wù)流程的步驟，估計沒有多少經(jīng)驗的產(chǎn)品經(jīng)理們都能想象得到，先要去調(diào)研，然后畫成圖，在這個過程里面會有確認，完善的工作。

調(diào)研的過程是為了解決who，what，why，how，以及where的問題：誰，在什么情況下，做了什么事情，這個事情需要什么前置條件，又輸出了什么，這個事情在哪里完成的？

但這極可能陷入形式主義性質(zhì)的錯誤，這種調(diào)研僅僅是在知道“用戶現(xiàn)在怎么做？”最后極可能得出一個流水式的糊涂賬。

產(chǎn)品經(jīng)理需要的是探索更深層次的問題，為什么要這么做，為什么不這么做？

流程的基本意思是指水流的路程，也就是工作進行中的次序或順序的布置和安排，由兩個及以上的業(yè)務(wù)步驟，完成一個完整的業(yè)務(wù)行為的過程。

對一項業(yè)務(wù)來說，從它的輸入到最終的結(jié)果，理論上來說就是一張流程圖就可以畫完整，但為什么不這么做呢？

沒有多少人可以一口氣看完一張橫跨多個業(yè)務(wù)角色、多個業(yè)務(wù)部門的流程圖后，能有一個全局的概念。這種形式的流程圖，會讓人陷入一種不可收拾的泥潭中。

產(chǎn)品經(jīng)理不僅僅是要知道每個環(huán)節(jié)的流程，更要理解整個業(yè)務(wù)的體系，并協(xié)助團隊成員從全局來理解業(yè)務(wù)邏輯。

你需要把業(yè)務(wù)的核心剝離得出來，抽象出多個可以支撐業(yè)務(wù)的關(guān)鍵支點。只有先搭建了一個好的戲臺，人物角色才能夠全面鋪開。

在你的腦海中想象一串葡萄的樣子，你的業(yè)務(wù)流程圖也應(yīng)該是這樣，一條主線若個支線無數(shù)節(jié)點。

每一項業(yè)務(wù)通常都能找到它的關(guān)鍵支撐點。

比如O2O項目，我們可以抽象歸類出“受理、派單、接單、回單、回訪”5個業(yè)務(wù)動作，通過這5個基本的業(yè)務(wù)動作，能夠讓整套系統(tǒng)流轉(zhuǎn)不同的業(yè)務(wù)單據(jù)，能夠支撐多個的業(yè)務(wù)角色，而不是簡單粗暴的讓流程跟著單據(jù)走，不能演變出新增/刪減一份單據(jù)都需要重新定義、修改流程的局面。

實際上，你應(yīng)該發(fā)現(xiàn)，對產(chǎn)品經(jīng)理而言，是先有業(yè)務(wù)，再做框架，然后是功能，最后是過程。一定要避免直接操刀把一個產(chǎn)品拆分成多少個模塊，模塊多少頁面，頁面內(nèi)是什么按鈕。

axure可以輕松輸出流程圖，通常情況下都可以不用visio等工具繪制流程圖

少用多種工具的思路是讓你把一個工具用到極致，并從繁雜的工具中解脫出來。

08 用故事板描述需求，而不是只有功能

所謂的用戶故事，就是描述用戶想要實現(xiàn)的功能，最簡單的說法，就是“誰想要干嘛”。

產(chǎn)品經(jīng)理們的PRD文檔會出現(xiàn)”寫了沒有人看“的尷尬，一個重要原因就是用戶需求的描述方式。

你寫了很多也足夠細致，但讀文檔的人卻始終沒有辦法進入角色。過于技術(shù)化的描述讓人昏昏欲睡沒有思考的欲望，根本在于閱讀者不能通過角色置換想象一個用戶在干嘛，要干嘛，以及為什么。

隨著業(yè)務(wù)復(fù)雜性的提升，”需求清單“會變成像裹腳布一樣讓人不愿意忍受。

根據(jù)用戶的業(yè)務(wù)場景寫成故事板，而不是列出一張”需求清單“。

這么做的目的是為了保證團隊能夠理解、認同為什么要這個功能，以及用戶是怎么做的，并引發(fā)團隊的思考。

產(chǎn)品經(jīng)理描述的功能需求（故事板），應(yīng)該盡量用團隊可以理解的業(yè)務(wù)語言來描述，而不是描述諸如字段，存儲的技術(shù)語言。

作為產(chǎn)品經(jīng)理，必須把重心放在用戶所能理解的問題上。你解決的是用戶的問題，而不是程序猿們的問題。比如頁面響應(yīng)速度這個問題，產(chǎn)品經(jīng)理可以描述為“啟動頁3秒后自動跳轉(zhuǎn)到首頁”，而忽略“響應(yīng)速度”本身是個什么概念——原因在于你的用戶并不能理解你的響應(yīng)速度，而你應(yīng)該像你的用戶一樣思考問題。

故事板并不是為了追求完整性，而在于它能夠被理解和有價值。

所以，不太建議過于在意”故事板怎么描述“這個問題，這可能不是最重要的是問題。

關(guān)鍵是場景覆蓋的程度，覆蓋越廣，適應(yīng)性會更強，程度越深，可能用戶的體驗相對會更好一些。產(chǎn)品經(jīng)理需要在不同的版本里面權(quán)衡在什么版本做什么功能，二八法則可能是你很好的一個工具。

想辦法讓你的團隊在你的文檔里面”看見“用戶的具體行為動作，在每個人的腦海中構(gòu)建出一副生動的畫面，你的PRD才會有活力。

09 別再把原型粘貼進WORD

前面已經(jīng)大篇幅的系統(tǒng)介紹了一份PRD包括的內(nèi)容，包括如何設(shè)計結(jié)構(gòu)，如何跟蹤進度，甚至好包括需求的變更管理。

接下來，我們再看如何寫具體的需求。

Axure 足夠你完成任何的需求描述，別再費神的再折騰一份word文檔了。

你完全不需要糾結(jié)是用標簽，還是用auxre 元件的“說明”來描述截圖的功能，這里唯一重要的就是這份PRD的用戶能不能看懂，以及他們?nèi)绾慰?。如果沒有閱讀axure的習(xí)慣，那你需要開展相關(guān)的培訓(xùn)工作。

在這里例子里面，我補充了“故事板”，列舉了要完成開機的這個過程里面要包括那些環(huán)節(jié)，每個環(huán)節(jié)要實現(xiàn)什么功能。

然后再每一個頁面直接，我設(shè)計了相關(guān)的跳轉(zhuǎn)動作和跳轉(zhuǎn)機制，并通過標簽來描述每一個細節(jié)，包括toast的時長，密碼的輸入動作，WiFi的狀態(tài)轉(zhuǎn)換，等等。

在整個界面，你可以細致的展開每一個動作，每一個細節(jié)，包括異常的處理邏輯。

這描述功能性需求的時候，會涉及到一些交互動作，甚至你可能會想到一些創(chuàng)新性的設(shè)計。文字已經(jīng)不能滿足你的時候，那就做一個動效，動態(tài)面板不能滿足還可以用兩個，實在不行就做一個GIF。

不要設(shè)置過多的交互，而通過一些輔助說明是個不錯的選項。

交互動作通常只有設(shè)計會被誤解，方案難以推進等情況下使用，設(shè)計交互動作的其中一個目的本身就是為了更高效的工作，如果這個交互動作不能讓你高效，那就很可能并不是非常必須的工作。

功能的描述沒有固定的模式和格式，把事情說清楚，并遵循一定的邏輯即可。要注意的是，不要再一個頁面把所有的功能都表達出來，很多時候設(shè)計頁面跳轉(zhuǎn)是非常必須的。

更為理想的情況下，下游可以直接延續(xù)上游的定義規(guī)則，整個團隊可以基于一個通用的語言來構(gòu)建整個團隊流程。

在項目發(fā)生意料之外的事情時，規(guī)范性的原型設(shè)計，可以幫助他人順利地介入然后接管事務(wù)，以便保持項目的健康。

行文至此，我更想強調(diào)的是，Axure還是WORD，都只是表達思想的工具，作為產(chǎn)品經(jīng)理的你，一定要：

少花時間和工具作斗爭，多花時間思考產(chǎn)品。

因為：

沒有一個產(chǎn)品能夠滿足所有人，也沒有一個工具適合所有場景。不要再工具上過多的信奉金科玉律，但熟練掌握用好一個工具，可以加速你的輸出。