要活學活用，之前說的產品設計的內容，不要用一套自我主義思維打天下，強調下產品結構的幾種特點：矩陣結構【一個頁面闡述大量的內容，並不是有大量的分層，多個維度來統計能功能】，線性結構【某個骨幹流程按照某個線的方式，某個場景往下串】，層級結構【按照用戶自行選擇，需要乾的事情，做的層級，1.足夠偏，功能足夠的多。2.層級足夠的深，每次選擇的足夠少，統一認為第二種的用戶體驗比較好】。不要小看產品的結構設計，這是產品經理的基礎。結構設計是思考一個功能第一想的問題，不先想界面長什麼樣子，先想是什麼層級，什麼結構的產品，然後在想有幾個界面有幾個判斷。開始今天的內容，畫原型和寫PRD，主要是PRD和原型的對應關係，核心是說說PRD。
（一）回顧下上篇文章
- ① 交互所在層級
主要說了界面交互，低保真原型的設計。
- ② 交互設計三步走
（二）產品原型及需求文檔的撰寫
- ① 開發人員最討厭的PRD
PRD裡面講的邏輯限制開發了代碼，這塊就去查某個表，做某個參數，定義的變數都寫出來了，覺得很崩潰，照這樣寫出了問題算誰的，明明理解了業務，有別的方式不這麼做，用更好的處理方法，出了bug算誰的？PRD到底寫成什麼樣的，描述業務好不好。
- ② 產品設計階段
早期的PRD不叫PRD，叫開發規格，真的很限制人的，PRD是產品設計的第三個環節，根據原型設計進行討論，修正原型的正確性，也可以跟研發進行評判，對整個系統的開發工作量進行估值，需求文檔往往是後置的，一般來需求文檔就是需求評審之後，代碼就開工了。在原型設計之後研發就會做一些開發的準備。PRD也不能當飯吃，一堆人在寫PRD，寫了這些也不能產生價值，寫這些文檔幹什麼用呢。
- ③ 為什麼要寫需求文檔
- 需求文檔給誰看？
交互設計、視覺設計【需要了解場景進行設計】、項目經理【PRD認領，符合PRD管理規範的】、開發【開發的基本，開發需要PRD中將業務邏輯講清楚】、測試【依據PRD出測試用例的，怎麼進行測試，測試用例的變更和新增】、其他產品經理【講述可能有遺漏不如直接看PRD】、其他需要了解業務邏輯的人。
2.需求文檔的作用是什麼？
準確、直觀、完整傳達產品需求，保證各角色溝通有依據，保證產品質量控制有標準，存檔。
- ④ 需求文檔覆蓋的範圍
- ⑤ 需求文檔主要結構
- ⑥ 需求背景及目標
1.需求背景
讓項目參與者明白為什麼啟動該項目，如果來此競品分析，分析下競品，競品實現的功能是什麼樣子的。
2.項目目標
讓項目參與者共識目標，找到價值感。目標盡量量化。上線後驗證目標達到情況的依據。
3.編寫人
修訂日期、修訂人、修訂說明、修訂原因、修訂文檔版本號。
- ⑦ 功能列表
拆分成最小的功能點功能點之間相互獨立方便參與者理解需求，評估工作量
- ⑧ 功能點拆分
拆分：一定要拆出來一個功能的組合。一定有個優先順序最高的就是產品的靈魂，需求點。P0級的功能.P0是靈魂，沒有它就不是這個產品。P1和P2是對用戶體驗有絕對性意義的東西。P3是對產品的存活有決定性作用的東西，拉新留存。P4是錦上添花的作用。功能拆分的時候不光光的講有幾個按鈕，幾個值，首先優先順序。是不是拆分出來的每一個功能列表。
- ⑨ 邏輯展示
為什麼需要邏輯展示？彌補與程序員的種族差異，幫助自己梳理思路。不免需求遺漏，考慮不周。
多角色流程圖（泳道圖，跨職能流程圖：多角色，多系統，多模塊流程）
單角色流程圖（基本流程圖：單角色，單系統，單模塊流程）
流程圖：基本元素
基本結構：順序結構
選擇結構
循環結構
頁面流程，這是UED和前端最喜歡看的流程圖
- ⑩ 詳細描述
想不到那麼多情況怎麼辦？善用工具，幫助整理思路，表達清晰。向測試學習，多看測試用例，善於總結。
- ⑪ 數據需求
數據需求的採集標準
- 理論上所有用戶端新增功能都需要採集。
- 改動、優化需要進行前後數據對比
- 版本的核心數據指標
數據採集的類型基礎數據，交互數據，用戶路徑
業務數據，服務端存庫，用戶行為數據，前端埋點。
- ⑫數據需求
如果沒有BI支持，需要茶品經理自己定義埋點事件，不同的數據統計工具，不同的埋點的規範
- ⑬風控說明
可能出現的風險點和策略
PS：PRD是一個文件，文件是寫給人看的，文件什麼樣不取決於產品經理想寫成什麼樣，取決於讀者。大家認為好才好，為別人寫的不是為自己。文檔是核心：以表達為目的，讓查看的人清晰易懂，文檔完整性很重要，文檔表達方式靈活：axure、word、wiki、腦圖、表格，邏輯嚴密，表達清晰。產品經理技能宏觀至戰略，又能微觀至一個文本框的各種邊界和異常
原創文章，作者：投稿專員，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/314555.html
微信掃一掃 
支付寶掃一掃 