產品經理應該先寫需求文檔還是先畫原型？是應該正向思維，還是逆向思維？為什麼？
RT
我其實不理解為什麼這麼多人會從複雜的地方入手。也不理解為什麼一來就進入細節。
在原型、PRD之前，不能用TXT簡單寫個大家都看得懂的目的，羅列一下需求和功能點么。----------------------------------腦圖那東西，高低版本不兼容，複製粘貼不方便。到底有多少條數不清楚。不一定比TXT好使。先做模型，再畫原型，最後PRD
模型：對產品形態結構的梳理，包括功能模塊，邏輯關係，信息架構，業務流程等，可以用腦圖，use case圖，業務流程圖來表示，根據不同產品，產出物的側重點不同。但模型很必要，是可以幫助產品經理將一個想法，或是腦子中的模型梳理清楚，在做這些工作的同時，可以及時發現自己沒有想清楚的細節，這些是指導後面產品設計師(或產品經理)進行原型設計的。同時，描述模型的產出物可以做為傳遞，幫助別人理解你的產品形態。
軟體：MindManager，Visio原型：即畫出產品layout，即不包括界面設計和視覺元素在內的產品細節形態的線框圖，包括導航邏輯體現對應的信息架構，交互流程，頁面布局，功能任務點，頁面(流程)跳轉邏輯和較為明確的文案設計等。一個高保真的產品原型，不僅是所有的完整的「線框圖」，還同時要有對應的注釋內容，很多產品設計師(產品經理)不注意這一點，沒有注釋內容一樣不利於傳遞，因為原型除了在做用戶測試外，還是要給界面設計師和工程師看的。
軟體：AxureRPPRD：即我們說的產品需求文檔，這個東西在快速發展迭代，產品導向的互聯網公司中的主要作用是存檔，備案和忽悠大老闆。他主要是由上面兩個部分組成，要說再重要的就是加上一些前期調研的內容，比如用戶調研結果，競品分析等。如果你的模型和原型做的足夠明確，你會發現，工程師或是界面設計師跟本不會去看PRD。產品評審的時候，你打開一個30頁的word文檔，第一頁是目錄，第二頁是行業背景……你不覺得這是耽誤大家的寶貴時間嗎？當然，不能否認，寫出一份規範高質量的PRD也是產品經理的基本素質之一。軟體：Word應該說原型是PRD的一部分吧..
我習慣的做法：
1. 整理思路
2. 畫原型3. 寫需求文檔（PRD），寫的時候你會發現你原型裡面有很多地方沒有考慮到4. 完善原型5. 完善需求文檔原型是對需求文檔的補充，需求文檔是對原型的解釋說明這個問題比較複雜，需要分開來談，首先說明下需求把它分為用戶原始需求，產品需求，軟體需求；對於原型我們思考將其分為低保真原型如手畫草稿和高保真原型( 包括體現了核心交互設計)。
如果是在企業內部或企業信息化軟體，一般是首先能夠收集到用戶原始需求，我們根據用戶原始需求進一步整理為產品需求。這個需求文檔是在前的，產品需求裡面核心內容即產品架構，產品組件和核心功能說明等。有了這個後我們一般會先開始畫原型，這個時候是偏高保真原型，有了原型後再開始寫軟體需求規格說明書，在寫需求過程中發現原型有缺陷會進一步對原型進行調整。可以說軟體需求和原型基本是相互促進和完善的過程，中間有很多細小的交叉迭代，但是一般情況下還是原型在先。
簡單總結下就是用戶需求和產品需求在先，(原型+軟體需求)多次迭代完成。
如果是互聯網行業，可以看到很多時候很難拿到完善的用戶需求並進一步整理為產品需求。如果從產品經理層面來說，很多時候是你有想法想做一款產品，或者說更高的領導給了你一個產品構思讓你去考慮是否可以研發為有價值的產品。
在這種情況下我們看到產品需求或者說更粗點的叫產品方案一定是在先的，產品方案或PRD畢竟可以更快的輸出轉化為文檔。有了產品方案或PRD才容易進一步決策這個產品是否做。要知道在這裡做這個決策跟原型一點關係都沒有，更加重要的是產品能否吸引用戶帶來用戶價值。如果這一點都過不了，根本就沒有必要在原型上多花時間。這個時候的產品方案更多用於決策，裡面包括了PRD的內容，但是可能並不是很細化。
所以對需要快速響應的互聯網行業，產品方案在先用於決策。其次再考慮詳細的產品需求和原型哪個在先的問題。這個時候其實沒有完全必要的先後順序，我們可以這樣理解，即經驗豐富或結構化思維能力強的，需求和UI分工細的，一般會先完善完整的PRD，再交付到其它崗位去做原型。而對於新產品我們都還在探索階段的，則一一定是先原型，通過不斷的原型細化來準備把需求想清楚。要知道做原型很多時候就是在細化需求。做原型細化需求更是以用戶驅動的方式。
很多時候我們看到由於產品需求和原型思考結合的太緊密而很難將工作分給兩個人做，這個時候往往是產品經理全部一起做，那麼這個時候原型可以理解為偏低保真的原型，可以手工畫的，也可以是axure畫的，只要能夠和需求完全結合起來，把想到的需求完全通過原型驗證滿足即可。
低保真原型後，產品經理可以根據低保真原型詳細的定義產品需求和軟體需求。而低保真原型可以交付專門的交互設計團隊轉化為高保真的原型。兩者可以並行做，做後可以進一步在高保真原型基礎上嚴重已經細化後的所有需求是否都可以得到滿足。
最後，沒有必要太多考慮誰先誰後問題，但是要意識到原型是幫助我們思考需求，細化需求的重要手段，畫原型的過程往往就是需求細化的過程。我的團隊，我通常的要求PM這樣做1，用最快時間先給出直接可上線的高保真設計原形（由PM完成）2，給出簡單版本需求說明3，和工程師討論細化，明確不確定的需求。4，和UI設計師一起完成最終上線的UI設計（包括交互）
5，根據確定的UI設計方案，完成MRD說明書。
6，和工程師確定最終版本.取決於做什麼類型的產品，以及所處的產品階段。
通常的模式都是由抽象到具體，先定方向，列需求，再逐漸細化，一步步由初步設計、細化設計、快速原型、中高保真原型這樣下去。
但是「重劍無鋒，大巧不工」，武功招數，又哪裡有定勢。在一些情況下，這個過程反過來其實也可以，特別是那些相對比較「扁」的產品。
先有大致的需求構想，都不需要寫文檔，再一下子深入到具象，頭腦中映射出最終的產品形態，然後回過來結合場景與目標，梳理需求，如此反覆。這樣同樣是一種可行的方式。只是各有利弊和適用的環境、人罷了。
—— 2017年9月更新 ——
學習 UI/UX 和產品設計
1、UI 和 UX 設計師的課程表
2、UI、UX交流QQ群：633293003，會定時舉行公開課和答疑。歡迎大家加入。
1 整理需求列表2 梳理產品中各功能流程3 低保真原型，保證流程順暢4 高保真原型，優化用戶體驗5 整理需求文檔（PRD）6 改進原型、完善需求文檔
1. 想清楚
2. 按照用戶的使用流程, 列出關鍵點.(word也行,viso流程圖也行)3. 原型圖(viso, mockup啥都行)4. 和UE RD FE討論. 請團隊每個成員理解我們要做的目的，以及為什麼，接受任何針對需求和實現方式的建議和質疑。
5. 反思。 修改流程圖和原型圖（解決不可實現部分，OR反思採納大家提出的更好建議）6. UI設計，修改7. 再次開會確認細節最終版本。8. 確定排期，milestore9. 開發10. QA PM UE分別從各自的方向以及整體項目效果上進行測試。11. 上線。唯一的困難： 對人要求極高，尤其是PM。能否掌控好整個過程和節奏，能夠把握重點的表達和闡述，同時用OPEN， 客觀，勇於自我否定的心態看待自己的設計。無條件發自內心相信每個團隊成員，調動起團隊每個人的積極性為這個產品做到最好貢獻自己的力量。
高壓力下的大項目完結之後study和出去吃飯HAPPY。
挺難的。
還在不斷的改進中。一想，二動筆，三和RD碰，四寫需求，五齣交互、UI，六評審
這個要看和其他團隊的配合和默契度，一般來說：
初次合作的話，最好現有個PRD作為依靠，要不然容易發散，再逐步討論完善PRD和原型設計；有過合作或者是修繕，出個原型討論比較合適，否則PRD的修改也確實是讓人頭大的事情。合作過很多次，很默契了，直接出原型就可以了，這時候寫PRD是一件很奢侈的事情，如果涉及到後續產品接手的問題，直接熟悉產品比看PRD來的容易的多。當然如果是大公司，資源允許的情況下應該還是做足流程。1、需求功能點整理分析2、概念設計
3、業務流程
4、低保真線框圖5、高保真線框圖6、PRD我先來說個真實經歷的故事
-------
這2天工作室在和客戶的合作中，也在產品討論的溝通中遇到了同樣的問題。
AIUX在與國內多家知名互聯網公司合作時採用的方法都是以原型為討論出發點，切入到產品設計中。
但就在昨天，和某合作方的技術，初次就某新產品（還未開發，屬於0-&>1階段的）方案進行框架討論時，技術大大要求說，
這種產品原型的方式沒法進行討論，你把需求文檔做出來，以前我在的X公司（BAT的某家）產品經理就是這麼做的。我一會兒給你發個文檔，你參考那個寫…
PRD………
PRD………
PRD………
聽到這個陌生卻又熟悉的訴求時，秉持著客戶是上帝，要衷心為他們的體驗負責的某艾，卻不禁一陣惶恐：
為什麼初創公司必須要做PRD呢？
為什麼基於產品原型無法溝通呢？
為什麼第一次就要陷入到功能實現細節討論呢?
……
產品流程並沒有適用於每個團隊的萬能招數，與之相比，更重要的是團隊成員間的全心信任與互相配合。如果創業團隊能在過程中找尋到一套最適合自己的配合方式，無論是PRD也好，產品原型也罷，就算是紙面原型，都可以發揮出巨大的價值。
* 後續提到的PRD在一定程度上，和大家口中提到的MRD，BRD，基本屬於一類產物，即產品需求說明文檔。後面不再贅述。本回答只想就如何有效地溝通產品進行發散討論，不針對任何人或事。
的確，在互聯網初期，各個大公司跨部門團隊協作中，PRD發揮了舉足輕重的作用。不可否認，一份書寫詳細的產品說明文檔，可以在產品迭代過程中，對每個功能模塊的思考更加全面充分，避免後續潛在的撕逼和可能出現的問題。
但為什麼PRD的形式，會逐漸被產品淘汰呢？
『啟示錄』（被譽為創業產品人必讀作品之一）的第18章，作者Marty Cagan 用整整一章，來闡述『安息吧，紙質說明文檔』的觀點，他不提倡PRD的理由，概括下來主要有以下3點：
1. 花費了大量時間撰寫，卻鮮少有人仔細閱讀；
2. 大部分的文檔並未提供必要的細節，也沒有任何關鍵信息（基本淪為一種幌子）
3. 產品經理需要更加完整地去考慮產品的完整體驗，而不僅僅只是功能需求
究其根本，隨著創業勢頭的興起，小而精的團隊，緊密的合作方式成為主趨，快速落地一個MVP（Minimum Viable Product 最小化可用產品）產品，去實踐和驗證市場的反饋，產品的速度和敏銳度尤其重要。
而在這過程中，產品用戶體驗及創新設計的討論更為重要。產品說明性的PRD文檔雖然看似詳細，但臃腫固化，不能給參與者提供更多發散及討論價值，尤其在產品定義的初期階段。 它每次製作時花費的人力、時間成本，寫了許多卻是廢話的描述性文字，以及抽象瑣碎的功能需求陳列，並不能很好地作為溝通載體存在。
那麼基於原型式的產品討論，有什麼優勢呢？
（截圖來自 dribbble中的@Didi Medina，如侵權，隨時刪除）
原型看似簡單，實際上是產品設計師 對著一大堆功能需求列表，結合用戶體驗和交互流程，完整思考消化後，構建的一個可視化邏輯主體。和單純的PRD相比，它擁有更加形象的表現方式，有助於團隊中的各個角色建立一致化的理解。
以好產品著稱的企鵝家，也在提倡原型溝通，根據 前手機QQ 高級產品經理 胡澈在《締造企鵝》一書，第180頁《原型的力量》一章中也提到：
原型最大的作用是就把想法可視化、具象化，把溝通的成本降低，可以讓更多人來關注背後的想法…
為了更好地理解這段對於產品原型使用的說明，某艾和作者胡澈同學基於此問題，有了進一步深入的討論。
在其中胡澈同學特別指出：
不同工具有不同用處，我這裡想表達的是，抽象與具象的結合。PRD其實是非常抽象的東西，但又需要具體到每個細節；原型則是相對具象的東西，從宏觀角度來解剖產品，又不夠具體。
對於一個團隊來說，先從宏觀入手，再細化到每個細節，對於每個環節的人來說，都是一種降低信息傳遞的噪音的溝通方式。原型相對PRD，是更好降低信息不對稱，避免需求理解不一致的工具。
實際上，基於原型的產品設計方式，也可以看做UCD產品流程（Uer Centred Design 以用戶為核心的產品設計流程）中核心的 Prototype 和 Evaluate 兩個階段。 這種產品設計方式，2009年開始流行，並因它快速靈活的方式，逐漸成為各大歐美互聯網公司的主流模式。
下圖為UCD流程的參考模型，有興趣的同學可查閱，本文暫不做展開。
那麼創業團隊應該如何基於原型，進行一個完整的產品迭代設計呢？
拋磚引玉，先來介紹下AIUX工作室在產品諮詢的過程中，如何使用產品原型的方法，與合作方一起協作，將產品從想法落地執行到具體的項目呢？
該方式是在工作室與諸多知名互聯網創業公司合作的過程中，基於以上的UCD產品流程，總結歸納的3個主要步驟：
*為了方便大家對每個步驟進行理解，以下的圖例以某艾曾主操刀的『全球首款特效短視頻App』的錄製流程的產品設計為例，進行說明。
1. 需求討論及定義階段結合產品的具體用戶和使用場景，清楚地知道產品體驗優化的重點所在，或是產品想要達到的目標。基於以上的討論結果，羅列需求List，每個功能用簡短的story描述出即可，無需做長篇大論的闡述.
（截圖是作者的思維塗鴉，模擬用戶使用過程，整理出了4個主要的用戶訴求）
整理思維以及弄清楚用戶使用場景的思維草圖，基於以上的手繪，可以和團隊形象地描述，產品的大致思路。
（截圖來自Medium的@Alan Klement，如侵權，隨時刪除）
可供參考的Story模板，當什麼場景下，我想做什麼，這樣我可以達到什麼目標
2. 產品邏輯框架梳理，原型草圖討論階段當拍攝視頻後，我想在當前視頻預覽界面直接添加跟蹤特效，這樣能更加迅速直觀地查看到視頻處理後的樣式
根據功能列表，用思維導圖定義產品的邏輯框架。如果產品的整體邏輯以平面結構型為主，先輸出討論產品的基本原型框架討論；如果是任務流程型，則以流程的方式呈現原型。
當上述討論無問題後，產品設計師根據信息架構中的重要功能節點，完善產品原型和流程，並按照各個平台的用戶行為規範原則，考慮界面上具體的用戶使用方案。
（以上截圖為錄製過程的原型初稿，示意了關鍵步驟的產品設計）
這個階段的團隊討論，根據AIUX工作室的經驗，會經過3個迭代過程：
原型初稿：原型文檔化，可與團隊更加明確，對產品的理解是否一致；
交互流程：在原型初稿的基礎上，補充邏輯跳轉線及重點功能的說明。基本上可算做交付稿，可召開產品終審會。
產品終稿：在完整交互的方案上，補充完善終審會上提及到，所有開發關注的細節和技術細則說明
需要注意的是，一般產品終稿在布局時，都能將開發關注的細節補充在原型圖的可見區域，但針對一些重要的功能描述，如許可權設置，支付規則，完整數據說明等，最好是以新建表格文檔的方式，作為補充。
以上，就是AIUX對於原型產品設計的理解。針對於創業公司中，產品設計究竟是使用PRD或者是原型，你怎麼看？ 歡迎關注我們AIUX Studio的公眾號，發表你對此問題的看法。等你來喲~
http://weixin.qq.com/r/80hietLEAo99rZYZ9x3h (二維碼自動識別)
1、需求列表2、功能概念3、邏輯結構4、原型5、需求文檔提交給技術和視覺
1.先了解清楚需求2.用腦圖畫出產品的功能點3.畫原型圖4.出需求文檔是按照從宏觀到微觀，從簡單到複雜的順序來進行的。這樣能保證產品設計有層次有流程，不會亂。
分享一下我們現在用的策劃分析流程：a 需求文檔（這個主要用於收集這個領域信息和設計的初步構想），這個環節與用戶，老師（理論），競品，程序等相關環節產生溝通。b 概念設計稿（這個服務在用戶心目中的感知，以及提供服務的主體流程），這個節點上與編輯（內容框架），程序（可實現行），產品（產品設計意圖），概念交互設計（用於形象化所要提供的服務概念稿）c 這個產品系統功能設計完成後各個節點需要完成的任務資源清單，以及最終的美術效果圖（用於了解哪些工作會影響人員工作的安排，以及最終結合在概念中的效果）。
從你的這個提問中，我是否可以認為要做的產品已經明確下來了？如果是，我的做法是先寫需求文檔，再畫原型，最後回過頭來再修改需求文檔。書寫需求文檔是整理思路和細化流程的一個過程，這個過程可以再次過濾掉不太合實際的想法，或者補充原來沒想到的步驟。畫原型，我認為是將需求文檔進一步細化的過程，一般來說，還包括了提示方式與部份交互。這個過程是將文檔變得可見，在欣賞自己做的原型時，也容易發現之中存在的問題。所以最後，把畫原型時發現的問題補充回需求文檔。至此，需求、原型一一對應。當然，過程中會與各類人員分工合作，這些上面的朋友都回答了，我也不多講，大致相同。
- 當我們有了一個產品的大致想法之後，可以隨手拿起身邊用的最習慣的工具（導圖、TXT、紙等）記錄下重要的關鍵詞或者解釋。
- 試著找幾個小夥伴，闡述自己的想法，並能試圖打動別人。
- 還是建議用導圖，把具體的一些結構圖做出來。
- 對著結構圖，畫產品原型草圖，這時候不要進入細節。主要的功能邏輯，界面布局表達出來即可。
- 與小夥伴們演示草圖，獲得他們的反饋。（此過程可反覆循環，並同時修改導圖）
- 進入原型圖完善細節。
- 給小夥伴們演示原型。（可反覆循環幾次）
- 拿出word這個神器，對著原型圖把功能需求描述充分。流程圖、用例圖可在此階段同時完善。（記住PRD是給開發人員和設計師看理解功能設計，只要能保證別人拿著這份文檔，可以理解你的邏輯即可。）
- 跟蹤設計師和工程師工作進度，確保他們真的理解了需求，並能完整的實現出來。
- 與運營人員指定運營細節，然後進入無限的試錯、修訂、發布更新，直到你變得越來越牛逼，產品達到預期效果，或者被開除。
TXT - 腦圖 - 交互初稿 - 腦圖調整 - 交互初稿調整 - 相關人員討論確認 - 交互定稿 - PRD/直接在交互定稿上標註業務邏輯
我們的流程是這樣的：1.思維圖，確定架構和模塊、功能列表2.原型3.和研發討論，修改原型；4.PRD初稿，審核通過；直接用streber以任務形式創建PRD5.發現問題以streber 議題方式討論，修改原型，議題轉化為任務6.測試驗證迭代，streber 跟蹤bug
既要有正向思維也要有逆向思維，正向就是一步步推演用戶的需求，逆向思維是在推演過程中不斷反問，這真是用戶的需求？這樣通過正向推理，逆向反問，不斷推敲，直到自認為找到用戶最真實的需求為止.你想問的應該是先寫PRD還是先畫框圖的問題，一般來說當明確用戶有這個需求之後，是先畫線框圖，線框圖的內容包括產品的功能、框架和基本操作流程，然後寫PRD，後面的具體細節可以交給交互設計師，然後形成高或中保真原型圖，假如沒有交互設計師，就直接將所有細節一步搞定，最後寫PRD。哥喬斯認為PRD不一定非要寫，高保真原型配上文字說明足夠了。當然寫PRD的最大好處不是研發看得明白，而是PRD以用例的形式呈現，有利於後期的項目管理。
推薦閱讀：
※在產品設計中運用到的軟體工程知識有哪些？
※如果你是易信的產品經理，你會怎麼規劃 3.0 階段的易信？（ 原題是怎樣規劃1.0的易信）
※互聯網產品經理的培訓哪家好，也可以推薦其他的？
※產品設計實際操作過程中，都是先做原型的嗎？