首先PRD面向的大多是設計與技術人員，設計師更多依賴于原型進行交互或視覺的設計，因此看這份文檔的人就會偏向技術人員。他們不太關注產品的商業需求和市場愿景，更多的是關注界面、功能、交互、元素等等內容，因此PRD文檔是一份詳細的產品功能需求說明文檔（這句話有份量！）。 ? ? ?PRD是產品中最底層和最細致的文檔，我們腦海里構思的是成品產品的界面功能的邏輯線框圖。
第一步：用思維導圖梳理出信息結構圖 ? ? ? ? ? ? ? ? ? 信息結果也是服務端技術人員創建數據庫的依據。
第二步：依據思維導圖羅列出的信息結構，我們以用戶的視角進行一步一步的模擬操作，繪制出產品結構圖和用戶流程圖（其實就是很詳細的功能圖，腦海中要能模擬出產品的一個流程）
第三步：原型設計（手繪原型、灰模、交互原型） ? ? ? ?原型設計幫助我們更細致的思考，并做出各項需求的評估，同時也是將自己腦海里的想法進行輸出，通過原型設計，就可以進行產品宣講了。相比于之前的文字描述，原型則更加清晰產品的需求，設計、技術或老板也能夠更加直觀地剖析產品的意圖。
由于移動產品的交互需求復雜，原型設計軟件難以高效地表達需求，因此移動互聯網產品的設計通常是交互原型加交互文檔組合成PRD文檔。
第四步：撰寫PRD文檔 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? PRD文檔沒有標準的規范，也沒有統一的模板，但是有兩項是必不可少的，那就是文件標識和修改記錄。文檔在撰寫過程中可以不斷修改完善，但如果正式發布或交給其他成員后，一旦有修改就必須標注出文檔的修改內容，備注修改記錄。
PRD常見三種形式：Word、圖片pdf、交互原型 ? ? ? ? ? 產品交互原型已經是很完善的產品Demo了，因此我們只需要加上元素的標注，這樣到處的文檔比word更直觀易懂，這是非常高效的說明方式。
第五步：用例文檔（UML用例圖、流程圖） ? ? 在產品和技術領域里都有UML的技能知識，而對產品人員的UML則更多的是指用例圖—用戶流程圖。 ? ?用例文檔是由多個用例組成的一份文檔，主要用于技術開發與測試使用，用于講解某個環節的功能邏輯，例如用戶注冊、活動報名等等功能都是需要用例輔助說明的。用例文檔的寫作時間在原型設計之后，通常和PRD文檔同步撰寫。
一份完整的用例文檔由以下四個部分組成：1.注明使用產品的各個角色（參與者）和角色說明； 2.以用例圖的方式注明角色們在前后端的用例關系；3&4.以流程圖的方式注明角色在各個功能環節的活動過程、并撰寫各個功能環節的用例描述。
表格說明
4.1用例名:此功能環節的名稱；4.2用例編號:此產品中該用例編號；4.3行為角色：參與或操作該功能的角色；4.4簡要說明:最少文字描述一下該功能的需求；4.5前置條件:參與或操作該公能的前提條件；4.6后置條件：執行完畢后的條件結果；4.7流程圖:該功能的角色活動過程：3中給出
