做出高保真原型還需要再寫 PRD 文檔嗎？
剛入行，好多東西都不懂，按我的理解PRD文檔就是為了說清楚產品設計思路，既然這樣，那麼高保真原型能否替代PRD文檔
讓我來總結下我司產品設計流程發展歷史
1.我沒有來公司之前老闆自己做設計和原型
他的步驟是在筆記本上畫wireframe和userflow,然後自己寫html+css，設計基本就是用css在做
因為是在做自己的產品所以基本不需要和任何人溝通，只要在他腦子裡過就可以了...
2.後來老闆太忙沒時間自己做，於是他畫wireframe和userflow，我來做mockup，他仍做html+css
省了一部分時間，因為在和clients溝通的時候如果只用wireframe和userflow，客戶是很難理解的，還是mockup更直觀。我們用github來做everything，PRD就放在github issue里，clients可以看到所有工作記錄，很多同事是remote work 也可以跟進進度。
3.後來老闆開始更忙，連html+css也沒時間做，於是出wireframe+workflow，我做mockup，前段來implement。這段時期是最混亂的，老闆一個人全包的時期，他直接一邊prototype一邊design，所以所有邏輯上的錯誤都可以及時被修正，而如果缺少了prototype環節，會出現非常多的漏洞，這段時間我司作品慘目忍睹。
4.後來老闆看不下去，建議我學前端，變成像他一樣的全能選手，我拒絕了，我認為樣樣通實際上樣樣都做不好，還是應該分工明確，問題的關鍵在於設計師和前端的溝通工作沒有做好，這是我的弱項，我不善於團隊合作，性格內向，我能做出很好的mockup但是一旦到了implement環節，前端只能做出40%的效果，當時我司前端比較注重完成功能性，好不好看他們不在乎。
5.後來我開始把mockup做的非常細，嘗試把每一個步驟解釋清楚，老闆那邊也不斷給前端上課，告訴他們把功能實現是遠遠不夠的，我們需要最終成品和mockup儘可能靠近。
這段時期我們仍沒有prototype，我只是在mockup里把flow做進去，還是會有很多漏洞，有些小漏洞前端就直接自己按自己想法改了，大的會溝通一下，但是離「無間合作」還差的很遠很遠，我當時就睜一隻眼閉一隻眼只要老闆不提我就懶的折騰，因為害怕增加前端的工作量。
6.我漸漸的發現prototype和PRD的重要性，prototype幫助自己輸通邏輯，prd幫助團隊溝通，而當時我沒有找到一個好的做prototype的方式，所以注重把精力放在prd上
到了這個時期，我們基本可以把工作到70分了，雖然交互上還有很多很多問題，因為沒有prototype，很多交互/用戶體驗相關的工作我們其實做的很少很少,這也跟我們產品性質有很大關係，系統太複雜，對交互的重視就會降低，但我不認為做企業應用就要完全忽視體驗，現狀只是因為目前大多數企業應用的甲方只求吃飽，不求吃好。具體不清楚，我們不做國內客戶，所以沒那麼多困擾。
7.目前的階段，老闆認為在做mockup之前可以先做prototype，所以我不參與phase1的製作，由前後端完成，先實現功能
phase 1完成後開始做mockup
（左是prototype，右是mockup）
phase1中的一些邏輯不通的地方我們會在mockup環節試圖一起改進，順念做concept添加簡單的新功能
我也開始用marvel來做一些簡單的prototype，用來檢查自己是否有邏輯上的疏忽
總之我覺得高保真原型和PRD都非！常！重！要！
PRD比較簡單，在sketch里畫示意圖，在github里逐條解釋即可，就跟編輯這條答案這麼簡單，不斷的edit解釋清楚，理清綱要。
prototype做起來比較煩，我實在不愛用axure，marvel和invision在核心功能上其實遠不如axure好用，但貴在輕，可以導入sketch，同步dropbox等等，分享起來也比較方便，複雜的交互可以用AE，但我實在懶=_= ，其他的一切比較火的做prototype的主要還是偏重移動端，我也嘗試過用keynote，但keynote也不是特別好用，還有我覺得很快就會有人去開發好用簡單的軟體出來的哈哈哈哈
對了，之後有空我會把內容好好整理下放到專欄里去，速度很慢但敬請期待 Guideline #0 - 摸索期 - Work harder - 知乎專欄
英文版 Designing UI Guidelines
http://weixin.qq.com/r/SUzy6onEvNTDrc2J9xlb (二維碼自動識別)
高保真原型只為在溝通中更為直觀的讓UI，開發了解你的功能需求。
內嵌的邏輯，細節，設計思維都還是得用PRD來講清楚的。
我個人認為：
高保真原型只是一個溝通的橋樑，具象化需求。
實質的邏輯還是得用PRD交代清楚。
即使做了高保真的原型，也一定要寫PRD。
但是不一定就要用Word來專門寫個文檔，
用寫PRD的思路在原型上寫，我覺得是最好的解決方案。
1、為什麼做了高保真的原型，也一定要寫PRD？
高保真的原型，只能表達UI和部分交互，
而邏輯和一些分支條件的交互不能完全表達。
舉個例子：註冊功能。這個頁面算是高保真原型了吧：
給不懂技術的領導看，這個頁面估計還行，
要是給開發前端UI測試看，這裡還缺少大量的需求描述。
一個完整的註冊功能需求描述應該包含如下幾個部分：1）邏輯規則。例如：
- 手機號碼長度11位、只能以13x開頭、不能重複註冊
- 驗證碼重新獲取時間為60s，驗證碼有效期為20分鐘
- 獲取驗證碼後，未收到簡訊，可以獲取語音驗證碼
- 語音驗證碼獲取流程
2）交互規則。交互規則需描述「在什麼條件下，給用戶什麼樣的反饋」
- 條件為各種事件，例如單擊、失去焦點、滑鼠移入、載入、刷新等
- 反饋為各種展現，例如顯示彈窗、關閉窗口、打開網頁、文本框旁邊文字提示等
另外，一些信息展示的功能還需要描述數據規則，如文本長度，數據來源，排序規則等。
2、為什麼在原型上寫需求？
在之前的一個答案里（如何寫一份易用的產品需求文檔？ - 覓路客的回答），我提到過，需求的描述方式有2種，一種是用例描述方式，一種是功能描述方式。而在原型上寫需求，就是功能描述方式。在原型上描述需求有2個好處：1、產品在設計頁面的同時，能迅速的把考慮到的需求細節以備註的方式在原型旁邊表述；2、對於閱讀者來講，原型圖+文字的描述更容易被理解。見過很多開發測試，在看PRD文檔的同時，也會對照著原型看，因為PRD文檔裡面的截圖+文字描述的方式看起來相對要費勁一些。
總的來說，在項目時間允許的情況下，我是比較贊同做高保真原型的，它能更直觀傳達產品的想法，也更容易被別人理解。《啟示錄》一書作者就建議描述產品需求只需要高保真原型+注釋就可以，完全不需要文檔，以下是書中的一些觀點：
產品說明（需求）文檔的主體應該是高保真原型，由它體現產品的功能需求、信息架構、用戶體驗、交互設計、視覺設計。高保證原型最大的優勢是可以用於測試。
與其花幾個星期撰寫冗長的Word文檔，既沒人讀，也無法測試，還不如和設計師一起創建原型。
先明確一個問題：你寫文檔是做什麼用的？
隱含問題1：團隊規模有多大？
隱含問題2：開發流程是什麼樣？
隱含問題3：產品多大？周期有多長？
文檔的作用一般來說有三個
1 明確設計
2 製作依據（技術美術測試）
3 迭代參考
在既定的需求下，你需要用確定的方案來滿足需求
這個方案要充分考慮到產品的大小，團隊規模和開發周期
同時，要由技術來實現，那就必須遵循技術的開發流程
在不同的情況下，需求文檔的樣子是大相徑庭的
一般來說，互聯網產品崇尚敏捷開發，快速建立原型快速體驗快速提交反饋修改意見快速迭代
在一個高效的開發節奏下，文檔是趕不上開發的，因為你應該多花時間去思考和設計
但這並不是說文檔就可以不寫，可以先做關鍵記錄，然後回頭補充文檔
即使文檔比開發慢，也要補充文檔，因為今後的修改也要有參考
這就是為什麼一定要寫文檔的原因
再說所謂的高保真原型，這種原型更多的是用來輔助前端和美術做界面開發和功能流程開發用
對於後端邏輯和網路狀況處理的描述不如寫文檔來的方便
比如說你要給每天第1個、第11個、第111個...第111111個登陸的用戶發獎勵，獎勵內容是xxoo...
這種需求你幾乎沒辦法用高保真原型表述出來，或者實現代價很高，或者理解成本很高
反而文檔簡單直觀
這樣的功能實際上有很多，比如統計用戶行為（並非所有的統計第三方SDK都提供），根據不同用戶屬性進行不同的行為（微信官方朋友圈廣告）等等很多很多，基本都是非文檔描述不清楚
所以說，做產品寫文檔應該沒有什麼爭議
只要根據實際情況調整執行策略，把文檔寫的滿足需求，不耽誤開發，不影響合作，不給後續維護迭代製造麻煩，夠用，好用，就可以
產品賺了錢，擴充團隊，美化文檔~
恩恩~不一定。
高保真原型有兩個作用，一是幫助 PM 理清設計思路。對於新手設計師，設計時容易丟三落四，高保真原型需要考慮整體導航結構、內容、按鈕、跳轉鏈接…把這些都過一遍起碼不會遺漏功能點，一些明顯的矛盾之處也容易發現。不過對經驗豐富的 PM，所有的細節都誠然在胸，這一點就不太重要。
高保真原型的另一個作用是溝通，如果相關方對整個系統都不了解，那麼一個高保真原型能幫助大家快速理解。不過如果相關方都對背景足夠了解，那麼原型也不是必須的。
相對而言，文檔的左右是描述原型里無法提現的內容，包括設計目標，數據預估，運營策略，一些原型圖上無法提現的細節邏輯。因為畫圖的速度終歸沒有寫文檔快，所以對於能在文檔上提現的內容，我本人更喜歡寫到文檔上。
我個人的偏好是中低保真原型加文檔，高保真原型由設計師產出。供題主參考。當然需要了。
需求文檔除了具有讓你詳細定義需求外，還具有備檔的用處。線框圖==框架
PRD==邏輯
說一下我是怎麼寫PRD的吧。
利用原型
原型PRD
之前有分享過一篇分享，關於我的PRD文檔結構介紹我的三年產品基本功（PRD）|將交互、業務邏輯、需求欄位撰入文檔得到了不少朋友們的支持，但除了用word之外，不少產品工作中因為時間、項目進度、團隊氛圍等種種原因每個PM在工作中，梳理PRD都會用原型或word進行梳理，今天將自己的原型PRD進行分享，方便大家根據自己的需求來選擇性製作。
一、我需要的原型PRD控制項
首先說明過下常用的原型PRD控制項，包括交互說明我都會採用以下控制項進行說，就算是複雜的交互說明，也可以通過以下控制項進行注釋和說明；
1.注釋面板
2.注釋說明
3.邊界線
4.標註點與注釋點
以上控制項都是自己做的，稍候文後我會附帶下載地址，方便各位朋友下載。
頁面交互與注釋說明
頁面prd
以上是按照頁面交互與頁面PRD進行分開描述，那麼接下來就為大家介紹下，如何去進行描述相應的欄位或功能。那些地方需要注釋、那些地方需要說明異常情況?
二、關於頁面的說明
在這裡，最重要的就是頁面路徑；頁面的路徑表示當前的操作會讓該頁面走向那裡，會回到那裡；讓開發、測試、設計人員是否需要考慮全局統一、是否當前的頁面在測試版本中有錯誤，也能幫助PM去驗證其頁面的走向是否符合用戶預期。
標明每個頁面的走向，這裡需要值得注意的是，關於頁面的命名也要注意。0-1中，很多功能體系涉及到無數個頁面，因此我們以功能的分化，讓頁面的列表更加清晰
將頁面進行分級後，按評審的時候也可以將頁面一個頁面的進行評審，一個頁面一個頁面的過，保證不會遺漏或者不會出現大的問題遺漏。
當然，相信不少朋友採取以原型頁面跳轉來進行頁面表示，保證設計或開發可以知道整個功能的頁面情況是怎麼樣的。
但是這裡有疑問的是，往往我們從0-1的時候，頁面太多不能在一個地方把所有的頁面全部展示出來，為此我建議按功能分頁面，比如上面說的以功能A進行區分，將頁面進行單獨的鏈接展示。
【按照登錄功能來表示頁面跳轉】
三、頁面功能說明
【我的標註說明】
以上是對ICON的標註說明，這裡需要注意的是「狀態」標註
如果一個ICON因交互行為會有不同的狀態或條件（如登錄狀態、未登錄狀態）那麼需要在標註著名。
【標註說明不同狀態】
狀態可以通過當前的頁面條件或者用戶交互狀態，頁面條件在不同的產品業務有不同的判斷方式
而交互方式往往就以下幾個：
根據不同的交互行為，有不同的提示，可以通過這樣的方式進行表達。如果交互行為涉及到不同的頁面，可以用如下表達方式。
【交互表達】
很多朋友說，產品經理應該把交互的效果儘可能去完成，但是真正的在工作中，其交互的效果因為第一費時間，第二需要不斷的去修改、修正。
如果一張圖就能表達事情，為什麼要費這麼多周折去做一個視頻呢？
善用當前的交互狀態與頁面切換，加上文字描述，可以很快的讓開發或設計同事知道你的意圖或效果。
在移動端的交互形式就那麼固定，安卓隨著版本不同可能會有一些區別，但大體用戶都有感知，有使用過。IOS因為系統的普及和更新覆蓋率遠超過安卓，因此IOS的交互行為也同樣能夠理解
至於最難的，就是WEB的交互形式，這一塊原型中的說明也可進行完善。
自己的個人微信號：574319420 可以多交流！
需要
你的產品理念 規劃 策略 流程 目標等等都不是原型能體現的 而且 原型不利於測試
從輸出接收方也就客戶的角度上來說，程序只需要一份文檔，prd的表現實在太弱，還是原型靠譜，可以在原型上補充大量的說明達到和prd同樣的效果。
若是同時存在兩份或者以上的文檔，會讓程序和測試、前端都崩潰，比如文檔過多而導致的 遺漏、比如文檔多份之間的邏輯衝突。
一個產品經理在高保真上花太多時間是得不償失，原型圖和PRD的目的也完全不一樣。
能簡單使用axure的話，不建議做成高保真，因為那真的沒卵用。還是在原型文檔裡面寫寫文檔吧。
所謂的高保真原型其實是頁面驅動開發模式。而PRD的作用類似於法律，PRD用於約束產品和開發雙方都要履行職責，因此，在大的公司里，PRD的作用還包括問責。無論你的原型有多麼的高保真，PRD必不可少。
當然，如果是小公司。有了原型，PRD的作用就沒那麼明顯了。像阿三那種雜技練得再厲害有啥用？打起仗來分分鐘藥丸～～
原型和PRD完全兩回事！兩回事！兩回事！
原型只能讓對方知道你想讓產品長什麼樣（主要是設計獅看），而PRD才能告訴對方不同功能模塊之間的邏輯和規範（主要是程序猿看），缺少了PRD，程序猿在幹活的時候根本就抓瞎了，最終產品出來還指不定啥情況呢。
推薦閱讀：