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

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

一、學習理解思維圖

二、學習理解詳細描述

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

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

（1）按需求提出的形式

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

（2）按需求設計的范圍

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

（3）按需求設計的用途

產品性需求：基于產品業(yè)務功能需求的改進，這也是產品經理一般負責的需求。

約束性需求：基于頁面展示或者其他考量，限制頁面展示的數(shù)據(jù)條數(shù)或者模塊。PRD上完成注釋。

技術性需求：產品會基于業(yè)務擴展性提出數(shù)據(jù)調用的方式和實現(xiàn)方式，比如某個數(shù)據(jù)寫死，某個數(shù)據(jù)需要實時從哪幾個表讀取。同時技術部門也會考量提出技術性需求補充。

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

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

（2）WPS畫流程圖，畫交互圖，我用的都挺順手的

（3）PS基本很少用，高保真的交給UI吧，希望大家都有UI。

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