PRD文件是什麼？PRD全寫是Product Requirement Document，也就是產品需求文件，是一份詳細描述產品功能、特性、行為和使用者界面的文件，它是產品經理規劃產品過程中的關鍵文件，用於指引工程師、設計師和其他團隊成員來理解產品。
PRD就像產品的說明書，把產品的目標、使用者、功能、介面、數據等等都寫得清清楚楚。一份好的PRD 不只會說產品要做什麼，還會解釋為什麼要這樣做，甚至告訴你怎麼判斷產品做得好不好。
寫PRD的目的，就是要讓所有參與產品開發的人，不管是設計師、工程師還是產品經理，都能對產品的樣子有清楚、一致的理解。這樣大家就能提高工作效率，減少誤解和重複工作，做出真正符合市場和使用者需求的好產品。
而我習慣用Axure來寫PRD，但最近也在學Whimsical這個工具，但它主打Low-fidelity，不過新人上手很快，操作也很順。但不管用什麼工具，寫PRD的重點就是要讓團隊成員對產品有共識，減少溝通上的障礙，做出真正符合市場和使用者需求的好產品。
註冊頁PRD範例，你能找到問題嗎？
下圖是一張「註冊頁」的PRD產品需求文件，你有沒有發現什麼問題？仔細想一想。
- 重覆性資訊：電子郵件和密碼的提示標題（2號和4號標注）重複了，這會導致閲讀者的混淆，例如，工程師就會跑來跟你講，你是不是寫錯了。
- 本地化與國際化：這份PRD是否已經考慮到多語系的支援？因為從提示文字來看，目前似乎只有繁體中文的版本。
- 用戶場景定義：從這個PRD來看，無法得知這個界面是在APP上，還是在網頁上，而且，若是網頁，是否只針對小網設計？還是是自適應網頁，也就是常聽到的RWD（Mobile Web或Responsive Web Design）。
除了上述所說，其實還有好多好多問題……，因為，這只是「一頁的註冊頁PRD範例」，並不是完整的PRD文件，所以你能看出的問題，別人也能看出來。
因此，整份的PRD文件會需要各個單位的人一起確認規格內容才能完成，不過不必擔心，一旦經過幾次的經驗，產品經理就會對這個「流程」熟悉了，自然就會理解該怎麼規劃出一份「完整」的PRD文件，因此，在產品需求說明會議之前，建議先找其他單位的人溝通，以避免在正式會議上變成批鬥大會。
要用什麼工具寫PRD？
根據我的經驗，在各家公司大部分的單位，都會告訴你，你用什麼工具、文件、呈現方式寫PRD文件都可以，只要相關的協作人員可以看懂就好。
但是，就是這個但是，你最好看看在你前任的產品經理是用什麼工具、方式、格式來寫PRD的。
為什麼？前面的產品經理如果有留下「大量」的規格，你真的會想要因為換工具而重寫一份規格嗎？或是改寫現在所有團隊都能夠看懂的格式嗎？
就算你有時間、有能力重寫，那麼，你的時間是公司的資源，你的老闆會同意嗎？
如果可以，先看看前任產品經理，以及現在的產品經理同事，他們都用什麼工具來寫PRD文件，是比較好的第一步。
正常的公司，規格通常是會有「延續性」的，每一個階段都會紀錄下來，留給「後人」去做產品規格的瞭解，而不該是讓人「考古」公司的產品應該是什麼樣的。
如果有一個系統，是公司服務中斷後才會提供，你真的會要求公司中斷這個系統給你試試看這個功能嗎？這就是很多公司做產品但拿不出來規格文件的問題，甚至還有老闆會說：「之前團隊跑敏捷跑太快了，所以PRD規格來不及寫」這種幹話，有這樣的老闆，你試著想一下一家公司的新人，要怎麼來理解現在產品的規格呢？
另外，建議新到職的新人們，選擇公司裡大家都在用的工具是比較好的方法，也是一個能讓其他同仁可以「快速上手」的好方法，總不能全公司的產品經理有人用Axure、有人用墨刀，還有人用Figma吧？
其他單位怎麼看PRD？
在任何產品開發過程中，溝通總是一個挑戰，尤其團隊規模很大的時候，如何確保每一個成員對產品的目標和需求有一致的理解就顯得很重要了，這也是PRD文件最有價值的地方。
為設計師提供明確方向
UI設計師和UX設計師是產品開發過程中不可或缺的角色，他們根據產品經理提供的PRD，進行互動設計和視覺設計，透過深入理解PRD中的流程與邏輯，設計師能夠設計出較符合產品需求的方案，還能避免在設計過程中偏離預定目標。
當然，你的PRD文件主要是產出之後，先和UI/UX設計師討論之後，才會形成較為具體的PRD文件版本，千萬不要自以為是的覺得這個界面就應該要這樣設計，要記得，要取得大家討論中的平衡點來規劃，也不是要你什麼不合理的規劃都要吞下去。
開發工程師的邏輯參考
對於開發工程師而言，PRD不僅是他們的指南針，還是他們的字典，從技術評估到開發途中的全部過程，開發團隊依賴PRD的產品框架、邏輯流程、頁面細節、資料呈現等細節，以確保開發過程中都能有效執行，符合產品目標和品質要求。
當然，你也可能會遇到自走砲型的工程師，完全照著自己意思去開發，完全不看PRD的，通常有這種情況，就是公司沒有制度、沒有養成「職能分工」的文化，主要的問題，還是在老闆身上。
確保測試工程師的準確驗收
測試工程師在產品開發中扮演著守門員的角色，也是公司品質的最後一道防線，他們需要確保產品在正式推出前的每一項功能都能正常運作，那麼，他們的根據來源是什麼呢？那就是要符合PRD的定義。
在前期，測試工程師會仔細分析PRD文件，接著，測試工程師可以開始寫Test Case，當開發完成可以進入測試階段時，能以此PRD基礎進行功能、邏輯上的驗證。
PRD還能做什麼？
記錄變更
需求管理，在產品開發過程中，需求的變更是不可避免的，PRD作為一個動態的規格文件，能夠幫助團隊追蹤需求的變更，並確保所有成員都能夠及時獲得最新的資訊，從而減少因溝通問題更而導致的混亂和誤解。
累積知識
如同之前提到的，可以讓新人快速上手，對於新加入團隊的成員來說，PRD提供了一個快速了解產品的途徑。通過閱讀PRD，新人可以迅速掌握產品的目標、功能需求和設計原則，從而更快地融入團隊並開始貢獻，而不是自己摸索產品有什麼功能、用猜的、用口耳相傳的。
同時，PRD文件，還能確保產品知識的傳承，當產品經理或其他關鍵角色離職時，PRD成為了知識傳承的重要工具，讓後續接手的團隊成員可以依賴PRD快速熟悉產品的歷史和迭代過程，確保產品開發的連續性。
PRD文件怎麼寫？
以下，只是一個範例，請依照自己的狀況來寫，基本上就是有多少時間做多少事情，雖然老闆、主管不願意聽這些理由，但實際上也是實話。
修訂追蹤表
為了保持PRD文件的清晰和準確性，對文件的每次修改都需要記錄，而這樣的表格是向團隊展示更改發生的具體位置，避免他們每一頁都要看到底改了哪裡，同時，此記錄對於回顧和自我檢討也非常有幫助。
背景簡介
撰寫PRD中的背景簡介有助於明確界定產品的發展緣由、與公司業務的關聯，並呈現對市場的深入理解。
背景部分說明了產品構思的來源和必要性，價值部分展示了產品在市場中的定位和其實現的可能性，而目標則提供了一個清晰的視野，確立了產品發展的方向和遠景。
這些元素合在一起，為團隊提供了共同的理解基礎，增強了團隊對專案的承諾和方向感，這有助於凝聚團隊目標
當然，你要寫的有引人入勝有故事性一點、讓人覺得做開發這個產品是有價值的，不要讓人覺得開發這個到底要衝三小。
功能清單
功能清單是PRD的核心部分，因為這裡能明確定義產品必須具備的功能和特性，用列表呈現時有助於確保開發團隊理解產品的需求和期望。
功能流程
在PRD中放置流程圖能夠直觀討論、思考工作流程或用户操作流程，幫助團隊成員理解產品的功能結構和交互邏輯，且還能能夠使複雜的過程一目了然，這有助於確保開發過程中的各項功能和需求得到完整實現，某種程度還能讓某些單位畫押同意、認同、吞下去這一段流程他們要協作。
流程圖不會畫？請參考我這篇「流程圖｜產品經理必學的流程圖畫法與應用」文章。
功能結構
功能結構圖依功能的不同，用視覺化的方式呈現出來，這樣做有助於團隊對產品有一個整體的理解，還能確保在開發過程中不會漏掉任何功能或頁面。
你需要畫出讓人清晰識別出各功能模塊之間的邏輯關係，因為這可以為所有團隊評估所需工作量提供了參考。
頁面設計（wireframe）
Wireframe的用途主要是在產品開發早期階段，為網站或APP界面提供一個基本的結構視覺化概念，它專注於排列頁面的功能元素，包括頁面的布局、功能分布和用戶如何與界面互動，且不涉及具體的設計細節如顏色或圖形。
要注意的是，因為這裡你動到設計師的工作範圍，一些設計老屁股會在需求會議上狂電你為什麼要這樣設計，而你只要進行產品的基本架構設計，並在設計和開發過程中促進團隊成員間的溝通和協作即可。
最終設計師產出來的UI稿，你的Wireframe也要一起同步更新，以免工程師跑來問到底要看誰的。
記住！wireframe（線框圖）要去掉Look and feel（視覺和感覺），重點是確認產品邏輯。別被外面那些乙方公司用Axure做的漂亮demo給騙了，那是他們用來營造懂高層需求、要確認現在的UI高層買不買單，跟產品經理實際開發產品不一樣。
畫wireframe時，重點包括以下幾點
定義
清晰描述功能是什麼，例如搜索按鈕的位置與行為。
資料來源
指出資訊從哪裡來，可能是用戶上傳或後台提供等。
交互
涵蓋各種互動方式，如點擊、長按等（UI/UX的範圍一定要和設計師討論）。
邊界
描述特殊情況下的表現，如無內容時的顯示方式（總之要想到各種Corner Case，因為好的QA工程師一定會測到）。
驗收標準
設定標準，因為好的QA工程師一定會「正面測一次、反面測一次」找出你的邏輯問題。
哪裡有PRD範例？
先分享我自己的PRD範例：
PRD範例一：https://bit.ly/44g8wyU
PRD範例二：https://bit.ly/3OIJgff
PRD範例三：https://bit.ly/3r5RZ39
再分享Hustle Badger提供許多公司的PRD範例：
例如Asana、Amazon、Figma、Square，可以在這裡找到所有PRD範例。
為什麼美國公司PRD範例都是寫字居多？
從Hustle Badger所提供的PRD範本來看，這些公司的產品經理在寫PRD時，似乎是傾向於使用大量的文字來詳細描述內容，我判斷這與文化背景、工作習慣以及專業標準有關，我「個人猜測」以下是幾個主要原因：
文化和溝通習慣
美國的商業文化強調清晰和詳細的溝通，文字描述被認為是表達複雜思想和概念的有效方式，通過文字，產品經理可以清楚地傳達背景、目標、需求以及預期的結果，確保所有相關方對文檔的理解是一致的。
法律和合規要求
PRD需要符合嚴格的法律和合規要求，詳細的文字描述有助於避免歧義，提供一個清晰的紀錄，以便在必要時用於法律或合規審核。
專業標準和行業慣例
文字形式的PRD已成為一種標準做法，因為他們認為文字能夠更精確地描述技術細節、需求規範和功能預期。
亞洲國家寫PRD的特點
大量使用圖片和圖表
尤其在中國的互聯網公司當中，產品經理寫的PRD裡，會看到大量的圖片、流程圖、線框圖和表格，主要是要用這些視覺元素用來簡化文字傳達定義，幫助團隊更快速理解需求。
協作工具的影響
大量使用各種線上遊協作工具，而這些工具鼓勵使用視覺化、模塊化的溝通方式，因此，PRD經常與這些工具整合，並採用簡單、明瞭的格式，方便快速分享和反饋。
速度和靈活性
亞洲國家公司，其工程團隊和產品團隊，往往都在極高的速度下進行，因此，會要求PRD能夠快速迭代和更新，所以PRD會更加模塊化、增加靈活性，這種方式比較允許團隊在開發過程中迅速適應需求的變化。
為什麼PRD會有這種不同？
我個人猜測，這些不同的格式主要來自於文化和工作方式的差異，美國人喜歡把事情講得很清楚，確保每個細節都不會被忽略，所以他們會寫很多文字來解釋。
而亞洲更喜歡直接用圖片和簡單的說明來告訴大家該怎麼做，這樣可以更快地行動，遇到有問題的地方，再進行快速的溝通。
就好比講故事一樣，有的人喜歡仔仔細細描述每個場景，而有的人喜歡用圖片來幫助大家更快地理解故事，這兩種方式各有各的好處。
我比較喜歡使用Wireflow方式
我真的很感激當年遇到的工程師，他們認為規格要畫出來，要畫到「點擊了什麼之後，要出現什麼畫面」的程度，所以，光是那一個APP，我至少畫了上百張的規格，那段時間奠定了我能快速產出規格的基礎。
在那個時候，各家公司的文件寫法我大概都已經參考過了，最終，看到了Nielsen Norman Group (NNG)公司所寫的一篇文章「Wireflows: A UX Deliverable for Workflows and Apps」，讓我接下來幾乎都是用這種方式和團隊來溝通。
科普一下：
Nielsen Norman Group (NNG) 是一家專注於用戶體驗設計和研究的公司，由Jakob Nielsen和Don Norman兩位大神創立，什麼？這兩位大神沒聽過？
十大易用性原則聽過吧？Jakob提出的，Don Norman door是指那些設計不良的門，讓人們不容易理解該如何打開或操作的門，這個名稱來自於Don Norman的書。
而他們兩創立的NNG，提供用戶體驗（UX）培訓、諮詢服務以及產出實證研究的文章、影片，他們在UX領域的深度研究和洞見著稱，許多文章經過多年之後仍然非常值得一看再看。
Wireflow是什麼？
Wireflow是一種結合了Wireframe和流程圖的設計方法，它用來幫助團隊更好理解一個步驟或是流程，你可以把它想像成每一張圖就是一張UI，點擊了什麼功能之後，它會告訴你每一步該怎麼走，並且用圖片來展示每一個畫面和交互邏輯。
Wireflow的用途
- 視覺化流程：它可以顯示從一個畫面到另一個畫面的過程，並且標示出每一步的互動。
- 簡化複雜性：當有很多步驟時，Wireflow可以把這些步驟用圖示和箭頭清楚地連接起來，讓大家很容易看懂。
- 協作工具：團隊可以用Wireflow來討論和改進用戶體驗，確保大家對流程的理解是一致的。
舉個例子
假設你正在設計一個購物網站，Wireflow可以幫助你展示用戶如何從首頁開始，點擊產品、加入購物車、進行結帳，直到最後完成購買的整個流程……。
每一個畫面都會被畫出來，並且用箭頭連接，告訴你用戶在每一步會看到什麼。
簡單來說，Wireflow就是用圖來告訴你「當用戶做了這個動作後，接下來會發生什麼」，這對於設計複雜的系統或服務非常有用，尤其是有閱讀障礙的工程師。
要深入了解產品經理的核心技能，請參考我們的詳細指南：產品經理的核心技能