教你用Axure快速輸出高質量的PRD

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

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

1、Axure版PRD 還是 Word 版PRD

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

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

為了向團隊說明業務解決方案，並試圖讓相關方都能理解而且支援這一解決方案，以及在開發過程中有條不紊的推進方案的落地執行。

PRD的問題不在於如何寫而在於讓團隊能夠理解業務，以及開發過程中如何被傳遞與執行。真正困擾我們的是一個很尷尬的現象：

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

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

PRD 結構圖

在描述需求的時候，通常用“輸入”---->"輸出"的邏輯關係闡述使用者需求，並且用“表格”來呈現完整的需求列表。

使用者登陸

WORD輸出的文件，最大的優勢就是有一個清晰的目錄大綱，一眼過去就能大致明白這一個“專案”的範圍，要做那些事情。

之所以今天很多人在反對這種格式文件，原因在於這種“專案交付式”的需求規格說明書已經跟不上節奏，其撰寫和閱讀的效率太低，寫和讀都非常的痛苦。而且非常侷限，很難真正理解一個產品的全貌，傳統的軟體工程面向的是專案交付，而不是我們今天大力倡導的以使用者為中心的產品思維。

曾經負責過一個專案，應甲方要求，洋洋灑灑輸出六萬餘字的PRD（一式三份打印出來，推在桌上蔚為壯觀），依然感覺意猶未盡。這種巨幅的PRD文件，在傳統軟體領域，極為普遍，但尷尬的是，這種文件往往寫完就束之高閣。

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

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

是時候拋棄線性描述的WORD了，網際網路下的產品經理需要更高效的專業工具和工作方式。

從現在出發，我們的目的是讓你的PRD相對輕便，別人願意看，自己也不太“痛苦糾結”。

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

x 產品 PRD v1.0

可以參考以下的方式來設計一個清晰的文件結構：

版本摘要：為什麼要做這個版本，要做什麼，什麼時候做好；

變更日誌：讓你的團隊成員知道你“又做了什麼手腳”；

產品原則：通用性的規範，需要遵從什麼標準，什麼要求，做成什麼樣；

功能結構：“用圖來描述”你現在想要改動“個人資料”模組還是訂單頁面；

關鍵流程：涉及到的關鍵業務流程；

故事板與原型：用場景化的語言描述某個功能是什麼，配合適當的例子，讓團隊成員真正理解這個場景下的使用者行為。

2、設計一個清晰的摘要追蹤版本

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

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

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

版本定義例項

你可以用內聯框架設計要給主頁，閱讀者可根據你的設計快速理解整個專案

透過定義版本摘要，不僅可以作為團隊版本迭代的指南，也是進度跟蹤的工具。引領整個團隊正確的理解專案。視不同的情況，不同的產品（業務）型別，版本的摘要有完全不同的內容，如果是甲方的專案，還可以把專案架構，溝通機制都作為一個摘要來傳遞。

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

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

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

基本原則就是：不要讓原型檔案滿天飛。

3、任何一個產品迭代過程都需要有明確的里程碑計劃

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

里程碑

很多公司可能配置了專職的專案經理，產品經理只需要獲取到專案的推進計劃並跟蹤結果的輸出即可。

而在一些創業團隊，產品經理有時候會兼顧專案的角色，作為整個專案的牽頭人，專案的里程碑計劃非常重要。

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

產品經理一定要有強烈的結果意識，時刻關注專案的進度情況，並儘早啟動相關的風險預備計劃，時刻準備應對可能的失控局面。

具體到專案進度的編制、執行和控制，是另外一個話題，暫且略過。

4、準備應對需求變更，但不要想著去控制變更

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

（題外話，對產品經理來說，自己能意識到這一點沒有什麼用，關鍵是能打造一個“敢”於變更的環境）。

所有應對和管理需求變更的“奇淫技巧”，首先要的是能夠從心理上有所準備，能夠擺正心態正確面對需求的變更，然後才是透過恰當的手段管理需求變更——不要想著去控制變更，一字之差之間有很大的不同。

對於大型的專案，建議把需求變更作為一個獨立的模組進行管理，並一定要建立完善的需求變更流程和環境，一旦需求變更失控，則整個專案就會處於一種混亂狀態，甚至直接導致專案的失敗。

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

要做到這一點，不但要求產品經理在專業技能方面比較過硬，也需要產品經理想盡辦法打造一個合理的專案環境。而後者，往往更重要。

需求變更例項

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

5、設計一個全域性的產品規範

產品經理應該儘早制定一份產品的基本原則，什麼能做，什麼不做。當然，這裡可以完整的描述從體驗角度需要遵從的基本規範。

全域性互動例項

這裡沒有太多的建議和參考，你的產品原則，既可以是戰略性的，也可以是產品功能性的，可以大到決定產品方向，可以小到顏色字型。

制定產品規範（原則）的目的，是為了保障產品的體驗一致性。更重要的是，保護你的產品不出現意外。

產品經理應該儘可能的從多維度制定規則，但不要過於複雜。

任何產品都很難照顧到產品的所有角色，必須明確產品的側重點是什麼。

不滿足所有使用者的產品才是好產品。

6、設計一個靠譜的產品結構

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

從這樣一個粗糙的描述裡面，你應該能夠理解，所謂架構，就是把各個部件進行歸納彙總，提煉抽象，並透過適當的連結方式打造成一個穩定的形狀，滿足人們的實際需要。

在你面對一個產品/一個需求的時候，應該能在腦海裡勾畫出模型，什麼東西是4個桌腿，什麼東西是一個桌面，4條腿和一個桌面如何共同構建和支撐這個業務的穩定執行。

功能架構

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

實際情況是，有的時候你並不需要畫一個結構圖，因為產品的結構可能已經千年不變了，這個版本也可能僅僅是修復一些問題，甚至只是把方形的使用者頭像改成圓形——因為你的老闆覺得好看。

產品架構不僅是能支撐當下的業務，也要能具備適度的擴充套件性和容錯性。

7、流程，還是流程

越是複雜的系統，越是推薦把流程圖做一個目錄，不但是引導閱讀者，而是檢查遺漏的方法。

產品經理在繪製流程圖的時候，儘可能的遵從通用的規範，並養成養好的習慣。好的流程圖，可以快速讓整個團隊熟悉理解業務，並最佳化業務。

業務流程例項

梳理業務流程的步驟，估計沒有多少經驗的產品經理們都能想象得到，先要去調研，然後畫成圖，在這個過程裡面會有確認，完善的工作。

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

但這極可能陷入形式主義性質的錯誤，這種調研僅僅是在知道“使用者現在怎麼做？”最後極可能得出一個流水式的糊塗賬。

產品經理需要的是探索更深層次的問題，為什麼要這麼做，為什麼不這麼做？

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

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

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

產品經理不僅僅是要知道每個環節的流程，更要理解整個業務的體系，並協助團隊成員從全域性來理解業務邏輯。

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

在你的腦海中想象一串葡萄的樣子，你的業務流程圖也應該是這樣，一條主線若個支線無數節點。

每一項業務通常都能找到它的關鍵支撐點。

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

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

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

8、用故事板描述需求，而不是隻有功能

所謂的使用者故事，就是描述使用者想要實現的功能，最簡單的說法，就是“誰想要幹嘛”。

產品經理們的PRD文件會出現”寫了沒有人看“的尷尬，一個重要原因就是使用者需求的描述方式。

你寫了很多也足夠細緻，但讀文件的人卻始終沒有辦法進入角色。過於技術化的描述讓人昏昏欲睡沒有思考的慾望，根本在於閱讀者不能透過角色置換想象一個使用者在幹嘛，要幹嘛，以及為什麼。

隨著業務複雜性的提升，”需求清單“會變成像裹腳布一樣讓人不願意忍受。

根據使用者的業務場景寫成故事板，而不是列出一張”需求清單“。

這麼做的目的是為了保證團隊能夠理解、認同為什麼要這個功能，以及使用者是怎麼做的，並引發團隊的思考。

產品經理描述的功能需求（故事板），應該儘量用團隊可以理解的業務語言來描述，而不是描述諸如欄位，儲存的技術語言。

作為產品經理，必須把重心放在使用者所能理解的問題上。你解決的是使用者的問題，而不是程式猿們的問題。比如頁面響應速度這個問題，產品經理可以描述為“啟動頁3秒後自動跳轉到首頁”，而忽略“響應速度”本身是個什麼概念——原因在於你的使用者並不能理解你的響應速度，而你應該像你的使用者一樣思考問題。

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

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

關鍵是場景覆蓋的程度，覆蓋越廣，適應性會更強，程度越深，可能使用者的體驗相對會更好一些。產品經理需要在不同的版本里面權衡在什麼版本做什麼功能，二八法則可能是你很好的一個工具。

想辦法讓你的團隊在你的文件裡面”看見“使用者的具體行為動作，在每個人的腦海中構建出一副生動的畫面，你的PRD才會有活力。

9、別再把原型貼上進WORD

前面已經大篇幅的系統介紹了一份PRD包括的內容，包括如何設計結構，如何跟蹤進度，甚至好包括需求的變更管理。

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

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

你完全不需要糾結是用標籤，還是用auxre 元件的“說明”來描述截圖的功能，這裡唯一重要的就是這份PRD的使用者能不能看懂，以及他們如何看。如果沒有閱讀axure的習慣，那你需要開展相關的培訓工作。

功能說明例項

在這裡例子裡面，我補充了“故事板”，列舉了要完成開機的這個過程裡面要包括那些環節，每個環節要實現什麼功能。

然後再每一個頁面直接，我設計了相關的跳轉動作和跳轉機制，並透過標籤來描述每一個細節，包括toast的時長，密碼的輸入動作，WiFi的狀態轉換，等等。

在整個介面，你可以細緻的展開每一個動作，每一個細節，包括異常的處理邏輯。

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

不要設定過多的互動，而透過一些輔助說明是個不錯的選項。

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

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

還記得上述的流程圖嗎？

像一串葡萄的樣子。

努力設定一個良好的邏輯表達業務關係

10、5個技巧足夠你用好你的Axure了

1、保持原型的組織性和命名規範

Axure提供了許多選項來保持專案的組織性。

比如頁面快照可以讓你快速組織一個樹狀結構，母版在命名後可以排序等等。

規範的命名是原型被容易理解和維護的關鍵所在，任何一個頁面一定要與最終研發出來的產品一致。

比如訂單詳情頁，登入頁，這些都是非常規範的命名。在原型維護時，就可以透過搜尋框快速定位。——效率值千金。

實際上，規範的命名應該下沉到元件級。

更為理想的情況下，下游可以直接延續上游的定義規則，整個團隊可以基於一個通用的語言來構建整個團隊流程。

在專案發生意料之外的事情時，規範性的原型設計，可以幫助他人順利地介入然後接管事務，以便保持專案的健康。

理想狀態下，一個原型應該是清晰易懂不需要解釋的，特別是在跨地區協作的時候。

2、母版是效率之王

任何工具，包括紙和筆，都只是將你的想法，傳遞給別人的一種形式或是工具。

不要在這個環節投入過多不必要的精力，儘可能的設計模組化、繼承化的東西。

母版正是這種思路的完美體現。

任何一個App都有很多頁面，多數情況下頁面的結構是一致的，不同的是頁面元素。而且還有一些功能，也會在不同的頁面出現。

有的人就不假思索的直接複製貼上來完成這項工作，不但效率低，而且容易出錯。

更好的做法就是製作一個母版，直接拖拽極可。

母版設計例項

母版可以理解為一個可以複用的頁面，你在設計頁面的所有元件、互動和技巧都可以在母版中使用。

母版設計好，可拖放在頁面的任何位置，統一修改維護，母板有更新，所有用到該母版的頁面都會更新。整個原型的維護更新就會變成非常便捷，而且不會出錯。

母版的另外一個好處是可以觸發事件，在一些情況下，透過母版觸發事件是非常高效的設計方法。但是，不要把過大的組合物件變成母版，而是應該把多個母版變成一個組合物件。

3、系統自帶的元件足夠完成絕多數的設計

元件作為axure的基礎，是表達原型的基本元素。

一個完整的元件庫，能夠讓你的原型看起來更真實。很多人就開始熱衷建立一個自己的 Axure 元件庫，網上也能找到大量的元件庫。

但實際上，你很可能並不需要這麼做。

大多數情況都可以透過自帶的元件庫完成工作，更激進一點的方式，直接用佔位圖即可。

對原型而言，絕大多數都不需要（也不應該）去追求原型的模擬美觀程度，而應該在於表達思路，完善想法上面，icon這一類的工作是設計師的範圍。

樸素原型例項

對PM而言，用最樸素的方式表達產品思路更重要，也就是你並不需要為原型付出額外的精力。

4、一個元件可以搞定的事情，絕對不用兩個

axure的原型因為是元件組成，所以當你每新增一個元件到你的專案中，也就意味著未來的維護需要耗費更多時間。

因此，原型一定要簡化。

一個元件可以搞定的事情，絕對不用兩個，多一分力氣都不要花在“原型”的設計上。

這一點實際上要求你對工具的每一個特性都非常熟悉。

比如在button上再組合一個文字標籤，這樣帶來的麻煩是修改命名、設定互動，甚至移動都是需要操作多個元件，而且導致元件檔案過於臃腫。

這種做法很常見。

還有一種奇怪的現象就是，使用兩個面板實現互斥性操作。A面板操作B面板，這種設計在多數情況下都是蹩腳設計。

這種情況可能是對面板的操作還不太熟悉，任何元件都可以直接轉換為動態面板，動態面板可增加多個狀態，直接設定每個狀態的跳轉即可。

設計一個選項卡只需要一個動態面板即可實現，而不是透過多個面板的互動進行切換。

動態面板很常用也很好用，通常都是用來做一些互動動效，比如輪播圖，選項卡等。

但是不要濫用，濫用指的是在不需要的情況使用面板，在可以用的時候又不用。

5、掌握快捷鍵

組合元件：ctrl+g；

鎖定元件：快捷鍵：ctrl+k；

平移元件：按住shift拖動元件；

複製元件：按住ctrl拖出一個複製的元件；

垂直或水平復制新元件：按住ctrl+shift後拖動元件

11、模板下載

本文是從一個完整的專案裁剪的模板，不夠完整，只是為了表達你可以考慮嘗試這種架構讓你的PRD更可讀，也便於管理。

現在，已經有很多PM習慣用Axure直接輸出prd。但是一些PM透過Axure輸出的prd卻不是那麼完美，畢竟它不像傳統的word文件輸出，有明確的目的、範圍、背景、功能需求、非功能需求等。

如下圖：

WORD輸出的文件，最大的優勢就是有一個清晰的目錄結構，一眼過去就能大致明白整個專案的基本內容。但是WORD輸出文件的缺點在於閱讀效率低下，且開發們都特別討厭長篇大論的文件，通常情況下他們是拒絕檢視的。

所以，用Axure輸出prd成了現在大部分PM的首選，但是用Axure輸出存在的缺點便是目錄層級結構不清晰。如何用Axure輸出一份程式設計師愛看的prd文件，就成了首要問題。

下面，筆者將結合自己日常工作中的情況，為大家進行分析。

一、規範的目錄結構框架

在正式開始畫原型之前，我們首先應該用Axure把prd的架構搭建出來，而不是一開始就動手去畫原型，最終輸出的內容也只有最基本的互動原型，其他內容都沒有。

一個好的prd框架結構應該至少包含以下內容：產品簡介、產品概覽、產品架構、產品原型、非功能性需求，如下圖：

著重說說以下3點：產品簡介、修訂歷史、全域性說明。其餘內容請讀者自行預覽專案檢視：https://3zuiql.axshare.com

1.1 產品簡介

透過產品簡介，讓UI、開發、測試等相關人員迅速的熟悉產品的相關背景、產品描述、目標等，加深對產品本身的理解，有助於工作的開展。

有的小夥伴會好奇，公司通常情況下都會有產品啟動會，會上已經說清楚了這些內容，產品還有必要多次一舉再輸出這些內容麼？

答案是必然的，因為產品啟動會並不能確定所有人員都到場了，也不能確保會上所有人員都認真聽了（誰知道某個開發是不是在會上偷偷勾搭UI妹子呢…..），更不能確保產品開發中途沒有新的成員加入，所以輸出一份好的產品簡介是十分必要且重要的！

下面說一下產品簡介頁面應該包含哪些內容：

產品簡介：一句話說明產品核心的功能，兩三句話說明產品大概的內容；目標使用者、使用場景：闡述一下什麼人在什麼情況下會使用該產品；專案背景、痛點：簡單說明一下為什麼我們要做這個產品，目前存在哪些痛點；產品目標：產品要解決的問題，最終實現的目標，能達到什麼樣的效果。

詳細內容各位讀者可以根據自己實際情況做一定的調整，總之一句話：讓所有參與人員透過檢視頁面內容能夠迅速的理解該產品的基本情況！

1.2 修訂歷史

任何PM寫prd，都不能保證考慮全面所有場景，更不能保證在開發階段中prd不做任何變更。冒著被開發打的風險，給大家說一句：產品不改prd就好比開發寫程式碼沒有bug一樣。

所以有改動是必然的，改動不可怕，但是在專案正式啟動之後，每一次改動必須要有記錄（無論改動多小），讓專案成員知道你又在搞事情，搞了些什麼事情~~~

修訂歷史必須包含：修訂的日期、當前版本號、修訂說明、修訂作者。另外，建議提供連結，透過修訂記錄可以直接跳轉到具體的修訂頁面。

1.3 全域性規則

一定要有全域性規則！一定要有全域性規則！一定要有全域性規則！重要的事情說三遍。

為什麼強調一定要有全域性規則呢？

對於相同或者類似的規則，通常產品只會在一處標明。如在A頁面列表標註：排序按照記錄生成時間逆序排序，在B頁面同樣存在列表時，則未進行專門說明。按照產品理解，我前面已經寫清楚了按照逆序排序，所以此處同理應該逆序排序。

然後事實是：開發分模組，每個開發人員只關心自己要開發的頁面，他或許壓根沒關心你在另外的頁面寫了什麼。所以，對於此類情況，我們應該寫進全域性規則裡，因為全域性規則是所有開發人員必須去檢視的頁面。

全域性規則具體包含哪些內容呢？

答案：只要是需要所有開發人員檢視，且適用於整個系統的都可以寫進全域性規則中，包括：互動說明、螢幕適配、全域性欄位說明等等。比如：欄位‘郵箱’，在系統中多個地方出現，我們只需要在全域性規則寫明1次欄位‘郵箱’的規則限制即可，而不需要在‘郵箱’出現的每個地方都進行重複編寫規則。

同時一些特殊的說明也需要在全域性規則頁面備註好，讓開發一目瞭然，如：下文中2.2。

二、注意事項 2.1 如何清晰地書寫邏輯規則

用Axure輸出，大家習慣性的在原型旁邊進行規則的備註。方式多種多樣，有：牽線、標號等等。

以下是個人總結出來的方式，詳細內容請看下圖（個人經驗，不喜勿噴）：

2.2 區別開頁面邏輯規則與原型上的文字

透過全域性規則，說明什麼是頁面本身內容，需要在頁面顯示的，什麼是頁面邏輯規則。

如下圖：紅線圈住的內容是頁面中的元素，需要在頁面進行最終的顯示；而下面黃色部分為邏輯規則說明，只是提供給開發以及測試等人員檢視，不需要實際顯示在頁面中。

2.3 修改的內容要有跡可循

關於prd的修改，很多小夥伴會說，我有修訂歷史頁面，專門記錄修訂的內容啊。

且筆者前文也提過prd架構包含修訂歷史，如下圖所示：

這不是清楚明白地寫了哪些內容更改，什麼時候更改了嗎，為什麼還要說有跡可循呢？

然而實際情況卻是這樣的，開發會很生氣的找到你，說：這一頁原型內容這麼多，難道還讓我通篇讀完對比到底哪兒修改了啊？

對於這種情況，如果不做特殊說明，開發們是很難找到你修改的位置，所以具體該如何做呢？

即在有修改的頁面進行詳細的備註，包括：修訂日期、修訂前內容、修訂後內容。

如下圖：

當然對於修訂的規範，我們應該在整個系統保持一致，且在全域性規則進行說明。

這樣，開發們就能清楚明白的瞭解到你修改的部分到底在哪兒了，而不用挨個查詢頁面上的元素。

三、小結

歸根結底，prd的目的就是提供相應的依據，為了讓UI、開發、測試等工作有條不紊的進行，所以prd一定要在做到結構清晰的基礎上簡潔明瞭。

究竟如何輸出一份好的prd還需要各位讀者結合自身實際情況多思考，總結出適合自己、適合自己公司的一套才是最重要的。