產品轉型-簡易PRD學習梳理

2 評論 6382 瀏覽 61 收藏 7 分鐘

在產品經理工作過程中,原型設計必不可少,那么在設計產品原型的時候有什么技巧和方法論?本文系統梳理了相關PRD學習的知識,希望對你有所幫助。

最近為了獲取面試機會,會被問到如何設計原型,有哪些方法論。因此系統整理下自己掌握的原型設計知識,歡迎各位大佬補充指正。

一、學習理解思維圖

二、學習理解詳細描述

2.1 PRD的目的還是為了詳細闡述需求

所以我按需求的類型來闡述我對每類需求的PRD設計要求;在我的常用需求分類里有三種分類形式。

(1)按需求提出的形式

  • 不完整的需求:需求提出方一般只提出部分概念,他也不知道要什么。所以需要產品經理有極強的業務支撐,進行需求完善并進行相應設計;PRD也需要注重完整:完整的業務方向、完整的流程圖、完整的注釋,從而訴請產品設計的概念。
  • 缺乏用戶參與的需求:用戶提出需求后極少參與需求溝通甚至不參與,因此無法通過頻繁交流獲取需求的詳細信息。此時產品經理需要尋求溝通,并極其慎重對待每一次需求溝通機會。PRD需要注重細節控制:清晰展現需求設計過程每個備受爭議的細節,并提供建議性的方案描述(成本充裕情況下可以有多個),從而讓用戶在一次需求討論中就可以確定想要的方案。
  • 不切實際的用戶需求:用戶基于自己的最高期望提出需求,一些時候是不符合產品的設計方向;這種需求需要先思考,是否可以進行引導和降級,提供基于軟件的方向和思路。PRD需要注重目標導向:深度理解殊途同歸,在目標不變的情況下,進行產品方案設計,可以將不符合自己產品設計方向的通過外部對接或者制度協同的方式變相實現(可以通過成本導向闡述、也可以打感情牌闡述),最終完成客戶的需求期望引導和實現。
  • 變更頻繁的用戶需求:對待這類需求需要先理解需求變更頻繁的原因,是業務形態多變還是初始需求覆蓋面不廣,需要通過詳盡的用戶調研并設想更多的場景用例來進行應對。PRD需要注重階段管理:深刻理解用戶業務,將用戶變更的需求視為一個需求,作為需求實現的不同階段;因此需要闡述不同階段如何進行銜接、轉變,需要做哪些預置動作。
  • 不再被需要的需求:需求不再被需要,是業務暫停了還是時效過了?所以在需求設計過程中,需要充分注意需求的保值。PRD需要快速交付,保障需求的準確準時交付,來不及就直接靠嘴說。

(2)按需求設計的范圍

  • 業務需求:負責一個業務的重構,涉及多個業務頁面或者流程更改,此類需求涉及的范圍更多,需要關注頁面與頁面的交互。PRD一般注明業務目標,業務流程圖,各頁面結構功能模塊,按頁面交互順序排列。
  • 功能需求:一個業務頁面下某個功能的補充,部分業務功能也會涉及和其他頁面的交互。PRD一般注明功能的位置,與這個業務或其他業務頁面的關聯邏輯。
  • 優化需求:某個業務或者某個功能進行邏輯或者細節優化,也有bug的修復優化。PRD一般需要列舉優化的前后對比,bug導致的問題和修復的效果,做好優化目標描述。

(3)按需求設計的用途

產品性需求:基于產品業務功能需求的改進,這也是產品經理一般負責的需求。

約束性需求:基于頁面展示或者其他考量,限制頁面展示的數據條數或者模塊。PRD上完成注釋。

技術性需求:產品會基于業務擴展性提出數據調用的方式和實現方式,比如某個數據寫死,某個數據需要實時從哪幾個表讀取。同時技術部門也會考量提出技術性需求補充。

2.2 PRD原型我常用的幾個工具,AXURE、WPS、PS

(1)AXURE一般都是有多個頁面需要交互的時候會用下,在進行常規產品設計時可以預置自己的設計模板,每次在基礎上進行設計,事半功倍。

(2)WPS畫流程圖,畫交互圖,我用的都挺順手的

(3)PS基本很少用,高保真的交給UI吧,希望大家都有UI。

今天就寫到這了,希望各位大神們可以評論指正不足的地方,萬分感謝。

本文由 @藍白羽0414 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 我很贊成PRD是為了詳細闡述需求這個觀點,看了很多PRD文檔,感覺他們寫的就像競品分析一樣,PRD不應該就是闡述需求,做出解決需求的方案的嗎

    來自山西 回復
    1. PRD就是吧需求功能交互都寫清楚交給開發,讓他們看的明白。

      來自河南 回復