產品設計實際操作過程中，都是先做原型的嗎？

01-07

大家在產品設計實際操作過程中，都是先做原型的嗎？沒有原型，直接設計的比例有多大？
對大部分公司來說，在進行UI設計前，原型需要做到什麼程度？
在UI設計完成後，是直接開發，還是先做高保真原型，然後再開發？

了解下普遍情況，多謝回答～
————————————————————
補充一下：
問這個問題是因為，之間呆過的公司在產品方面沒有正規的流程，也沒有產品經理崗（因為是數字類媒體和廣告公司，不是科技和IT公司），給自己或客戶做產品的時候，什麼情況都有，比如：
1，用word畫線框圖，就扔給設計了
2，用白紙畫些框就扔給設計了

3，產品調研、市場需求分析做完，列出頁面構架後，就直接扔給設計了（連線框圖都沒有）。設計做完所有頁面，用inVision直接做高保證原型給客戶確認，然後不停地改，改到滿意再給技術。（設計師吐槽比較多，因為工作量實在巨大，且沒有清晰的思路）
最近要自己做些項目，除了開發的部分都自己來做，包括調研分析、策劃、用Axure做原型、AE做交互、Sketch+PS+AI做頁面。然後交付給開發。我想知道什麼樣的流程是效率較高且相對條理清晰的？跟客戶也能減少溝通成本？
調研、分析、人物畫像等，以及設計的環節，我之前都參與比較多，就是中間的銜接部分，想探討一下什麼樣的流程比較好。
（畢竟按全套流程做下來，周期比較長。原型上花太多時間做得很高保真，耗時且佔用了設計的發揮空間。但是沒有原型的話，溝通也是問題。如果是給客戶做，需要內外部都做確認的話，情況就更複雜了。）
謝謝各位大佬的解答！

視覺設計前一定是要有原型的，只不過這個原型可能是產品的產出物、交互的產出物、研發給的產出物。

產品-&>交互-&>視覺-&>研發

這種模式適合產品需求比較明確、研發沒有風險、主要的不確定性在交互、視覺的情況。

2C 產品比較適合這種方式，適合職能型組織結構。

產品-&>研發-&>交互-&>視覺-&>研發

這種模式適合產品需求只有部分明確、研發存在較大風險的項目。

項目從 0 到 1 時比較適合這種方式，適合項目型組織結構。

核心要點都是把風險大的工作前置。

在產品功能需求明確、有標準的視覺交互組件庫的情況下，工程師在無交互、視覺介入的情況下也可以做的很好。後台系統類的項目，設計師提供一些規範就可以了。

原型主要是給開發團隊和產品經理本身對於要完成的這個產品一個比較直觀的感受

如果配合得好，又不是什麼很新的設計，低保真就夠用了，甚至可以直接出交互稿，手快的設計師直接就出設計了，有問題也可以微調，在移動開發時很常見

高保真原型主要是給大領導看的或者只是炫技

有的敏捷團隊，原型加上少許描述文字就是prd，有的開發跨了團隊，需要完整的文檔，原型只是輔助。有特別的情況我在白板上畫完功能拓撲大家就可以開始幹活兒。

互聯網產品講究快速迭代，有時候為了快，不要太糾結於流程和細節。團隊配合時間長了會有體會。

未必先做，但是在某個階段還是一定要有，就看個人的闡述能力。

實際的項目中，如果能夠使用文字描述清楚自己的意思，那麼其實打電話IM說明是最快的。但是很遺憾，我遇到的大多數產品都是這樣自己認為，所以還是倡導在最初的溝通，就能夠應用簡單的原型表達清楚自己的改變。

如果是闡述功能，那麼其實可以藉助其他同類型產品，或者修改截圖，或者告訴別人跟這個一致。

如果是界面設計細節，就算是手繪，只要能表達清楚，那麼還是畫出來。我曾經用摺紙的效果來向客戶說明了界面操作的簡單的動畫。

總結來說，個人認為原型是一種工具，一種圖形化語言，目的還是為了提高效率，所以需要大家依據實際的項目情況自己權衡何時引入最為合適。

原型不是為了做而做，做的目的一般來說有幾個：

團隊內節約溝通成本：以相對比較小的成本做出的原形，跟全體對齊細節，比開發完之後迭代修改更省時省力。
彙報用：尤其在大公司，很多項目在申請立項時，靠幾頁ppt其實很難讓老闆明白你的意思。這個時候有原型可以快速準確的傳遞信息
裝B用：等項目做成功了，你要給外人分享你的成功經驗，原型是一個非常好的過程交付物

其實還是看人，別人告訴你的方法是死的，而你是活的

我自己的邏輯一般是這樣，以1周的時間（7days）為例，C端產品

1。競品收集

2。競品拆解

3。競品分析

4。競品重新組合新產品

5。用戶路徑推演

6。 XMIND規劃明晰的功能點

7。開會評審56，包含可實現難度

8。完成步驟7，重新開始56

9。結合7，開始排布優先順序，使用TAPD

10. 畫草圖，給UI，評審

11. 重複10若干次

12. 開始在TAPD上面注入文檔說明和邏輯控制文檔

13. 等待開發，準備好紅包，掃碼改需求

B端或者後台產品，邏輯比原型更加重要。

簡單的回答

原型其實就是交流溝通的載體，通過原型把產品設計交代清楚，達成共識就好。

根據不同的展示對象，原型的保真程度滿足了展示對象的需求即可。

你可能沒有理解原型的概念。

按照保真度（就是接近實際的程度），有低保真，中保真，高保真原型。任何階段都可以產出原型。不能說有了原型再設計之類，原型本來就是設計過程的一部分。

原型的作用，一方面是說明和理順，另一方面是驗證。只要實現這兩個目標，其他的都是路徑。

例如，如果你設計了一系列頁面，把他們串在一起，這就是一個具備某種保真度的原型了，能夠幫助你實現目標。現在很多軟體都能輕鬆的幫你實現。至於這些頁面是什麼程度的，甚至是交互稿，還是視覺稿，都是可以的。

如果你問是不是開發前一定要做到最高保真的原型，答案是未必，只要別的方式能夠把前面說的兩點目標實現就可以。比如，直接通過草圖、線框圖等展現出來（溝通+驗證），同樣可以。

從開發角度說一下，當然有原型是最好的，但原型的好壞不在於是否高保真。對於開發來說，原型的作用是能讓我能清楚理解整個用戶流程、交互邏輯和一些數據屬性（比如表單域的值類型長度限制等）。所以，對於不同的項目原型要求也不一樣，如果有現成的視覺組件庫而且項目又不是很複雜，可能給我一個純文字的需求描述都可以做。

一個適合團隊的原型稿，需要團隊間共同磨合後才知道。軟體工具只是輔助，產品經理愛用啥用啥，只要能表達清楚開發需要的東西就行。

實際操作過程中，都是先做原型的嗎？

原型是在UI設計之前的。但在原型設計之前，還有需求分析，需求評審等重要的工作。如果是新項目，用戶調研，市場分析，業務模型搭建等流程都在原型之前。

沒有原型，直接設計的比例有多大？

很少。一般來說設計包含原型設計。

對大部分公司來說，在進行UI設計前，原型需要做到什麼程度？

對大部分公司來說，UI設計之前，原型只要能讓相關的開發、設計清楚要做什麼事情即可。如果是磨合成熟的團隊，低保真原型+簡單文字說明即可；如果團隊跨度較大，一般需要高保真原型+詳細說明文檔。

在UI設計完成後，是直接開發，還是先做高保真原型，然後再開發？

UI設計完成後直接開發。

高保真原型如有需求，一般在UI設計之前就做了。目的是為了向老闆、投資人彙報或者是市場調研的用戶反饋測試。這些環節都在UI設計之前。

==========================

看問題描述題主應該是對原型的概念沒有搞清楚。

原型一般分為低保真和高保真。低保真原型一般是簡單的線框圖或紙筆畫的草圖。高保真原型一般是有比較好的視覺和交互體驗的原型，能讓用戶直觀的體驗產品流程和細節。

原型的作用有2個：

一是對產品創意的驗證，有一個想法，可以快速的製作出一個原型來幫助自己或團隊驗證這個想法的可行性，這時一般用低保真+文字說明的方式足夠了。還有就是對於不了解產品的人，比如boss、投資人或者市場上的用戶，獲取他們的認可也是很重要的，這時就要用高保真原型去驗證。

二是對產品的解釋，就是向你的團隊說明你要做什麼事情。一般磨合好的公司低保真原型就夠用了。

沒邀也謝。先回答題主的問題。

1、原型設計準確的說是第三步。沒有原型直接設計的比例取決於這種無關緊要的頁面有多少，正常產品應該不會超過總頁面數的15%。

2、UI設計只是解決終止狀態下的視覺效果方案，而交互、體驗的效果就需要在原型中有所體現（有參考示例，描述準確，或者照抄某某，呵呵）

3、UI完成後，還需要進行兩件事。1是相關的體驗評審，2是需要與開發溝通是否具備開發條件。才能進入真正的開發階段。

---------------------分割線---------------------------------------

下面是我所管理的項目團隊的SOP，不一定適用所有機構或團隊。但應該有一些參考意義。

團隊規模，產品經理*4，設計*3，前端開發*10，後台開發*5，QA*2。其他還有很多配合我們工作的部門和同事，不詳細列舉了。

往複、確認、溝通的部分就不展開說明了。

階段一~

懶人專用先說總結：信息的匯總與整理。

1、需求收集

總歸來自3個方面吧。產品團隊，用戶訴求，領導要求。

2、需求分析，定義

需求核心是什麼，到底需要解決什麼問題，新功能還是優化。

這個需求在整個需求池中的優先順序。在下一個發布版本，或者迭代計劃中，能排到什麼優先順序。

階段二~

懶人專用先說總結：設計細節和與之相關的確認。

分支

完成前兩步後，會有先出計劃還是先做設計的選擇上會有一些區別。先出版本計劃再產生詳細的開發方案還是先完成詳細的設計方案，在根據需要排入相應的開發計劃。我傾向於先確認計劃，再進行詳細的產品設計。畢竟線上項目的周期或者市場的周期在每一個時間點對產品設計的側重或者傾向會有比較大的影響。

3、確定一個開發計劃

即這個版本到底要解決什麼問題，或者新增什麼功能，優化哪些項目，對應迭代內容包含什麼。

還需要確認一個備用策略，如果時間點或計劃任務出現不可抗力的變化，需要做哪些調整。減法的順序或者時間安排。

4、細化設計方案

確認功能點結構，數據欄位結構，頁面結構。

根據以上三個結構完成原型，需要包含基本的交互需求或說明。

根據原型與設計部門進行溝通，完成設計小樣，進行初審。題外話，如果在某個階段內的迭代，不需要重新定義材質和風格。如果是新項目或者大重構，則需要在第三階段的期間就開始著手制定設計規範或核心理念。

結構化數據埋點，或指定期望值。

5、評審確認

到達這個階段，有以下幾點必須要符合標準。

產品層面達到了需求初衷；

設計層面符合了體驗要求；

開發層面評估能夠實現既定方案（或達到同樣目的）；

預設的數據轉化可以被量化或能夠形成分析樣本；

階段三~

懶人專用先說總結：開發階段的必要支持，直到測試之前。

6、前期其他一些整備

確認開發計劃的時間點，一個活多個節點。

迭代策略為敏捷式還是最終式。

相關的測試用例編寫（主要根據評審確認後的產品需求），測試計劃，所需要的測試時間。

幾個時間點確認後，確認最終的迭代計劃。相關文檔定稿收錄，以便後續查證。

7、進入開發階段

這期間產品更多的是一些必要支持

比如出現了一些特殊情況（說明沒寫清楚，或者缺少標註切圖，個別異常規則的處理），比如一些策略的確認（用戶效果相同，實現方式變化等等等），比如老闆有新想法（不靠譜的想辦法扼殺，靠譜的去落地或者排入下次計劃）。

階段四~

懶人專用先說總結：驗收，清算，確認標準。

8、進入測試階段

開發自測屬於階段三，到階段四時，進入QA與產品的測試確認階段。

QA主要是針對邏輯，性能，異常狀態，測試用例的測試，即數據層。產品主要針對是否符合設計初衷或設計方案的測試，即使用層。此時可能有第三方參與進來，比如心急的甲方爸爸們，嘻嘻。

此時環境應該是內網環境或防外網環境。介面應為對應的測試結構，數據應為對應的測試數據。

9、清查處理

清理確認修改的項目，或需要調整的條目。清理老版本的遺留問題。

如果存在小範圍發布渠道，需要通過小範圍測試階段確認數據是否正常，程序是否健壯，用戶反饋是否正向。通常會由忠誠用戶和邊緣渠道充當此版本小白鼠。

10、確認是否達到發布標準

事階段四的終點，即確認是否達到發布標準，是否能夠作為渠道基礎包。

我不會告訴你們其實每個版本都會存在一些問題，只是根據復現的複雜度或清理的成本視情況決定是否要根除，畢竟時間有限。

階段五~

懶人專用先說結論：版本上線，跟進表現，收集反饋，形成後續報告。

後續都是一些再跟進的工作，通常會重點觀察1-2周。細節不想寫了。

新功能看使用率或到達率。其他看日誌和用戶評論或反饋。

1級數據以上的數據分析結果，要根據所處的市場環境或運營周期再繼續跟進行程後續方案。

BTW

其他一些產品方法論，莫名其妙的文章，亦或者是吸貓也可以來我的公眾號：HHHHXDX

http://weixin.qq.com/r/bilDW8jE-pWBrYw493x8 (二維碼自動識別)

根據實戰經驗說一下我的理解。

我負責的產品5月份從0啟動，6月份投入開發，7月份第一個版本，後面每月一個大版本，每周一個小版本的速度迭代。B端產品，做的是類分答、知乎的垂直問答產品，目前10萬DAU左右。

在這個過程中，什麼時候用到原型，什麼時候不用原型呢？

做產品規劃的時候畫原型。因為這個階段，老闆、運營、開發、設計、合作團隊都對產品沒有概念，所以必須通過原型圖，幫助他們快速理解產品。這裡的原型是你希望打造的目標產品形態，不用太細節，將主要的功能頁面和業務流程畫出來即可。
第一個版本prd評審的時候要原型。同理，因為是第一個版本，所以需要讓開發、設計、測試對產品有直觀的認知，用原型圖幫助他們快速消化prd。這裡的原型是你要做的第一個版本的原型圖，最好儘可能細，可以丑但是邏輯一定要完整。
再往後的版本，如果沒有特別大的迭代變化和方向調整，可以視情況決定畫不畫原型圖。我在這個階段就基本不畫原型了，因為和開發、交互已經合作的比較好了，大家對產品目標的認知一致，發展方向的認知也統一，所以靠prd就可以支撐開發了。同時，我會在prd評審前就和交互溝通好需求，加快交互出圖的速度，基本做到prd評審後的1-2天內完成交互評審。

總之，原型圖在產品發展的不同階段發揮不同的作用，並不是每次產品設計過程中都要畫原型的。

有夥伴已經把原型的定位寫的比較清晰了，包括說明、梳理和驗證等等。我這裡想補充幾點：

1，「原型」的定義。不同項目階段，不同討論場景，不同思考過程，這三個差異性的背景下所產生的原型圖都是不一樣的。在思考初期，產品的原型所追求的要素里包含「速度」，因此，像一些童鞋說的，IM方式和手繪也是十分可能的。畢竟這時候，作為產品人員（尤其是主創），不僅要和總工溝通，還得和UI、UE都交代清楚——讓邏輯工作者明晰，讓創作人員有底。

2，原型圖的溝通屬性。試想，我們在日常溝通過程中，常常要翻閱過往聊天記錄，甚至會根據不同的聊天記錄迸發出新的談資。產品原型也一樣。隨著項目進行到後期，溝通的複雜度和信息量可能會偏小，但不排除有走偏的情況，所以，一套完整的、能夠伴隨溝通過程的、能夠服務於技術工作的原型圖才能真正具備高效的梳理作用和驗證基礎。

3，原型圖的運營屬性。現在一些軟體公司可能不被客戶要求寫MRD文檔和運營建議（這部分往往會被作為增值服務提供給客戶），事實上，當我們畫原型圖的時候，往往腦子裡想得一部分信息是和運營與市場工作有關的。即，做原型圖是「開腦洞」的很好方式。說回產品設計里，在實操里，如果不考慮運營的因素和市場的手段，那麼這個產品設計起來難度驟降，當然，這個方案也很有可能過不了。

所以，產品設計作為一個「靈魂出竅」的階段，做用什麼方式做原型是不重要的，只要原型能成為你的思考素材，並最終能成為項目的一部分，這就是很好的事情了。

這要看你們需不需要把原型發給客戶測試，如果不需要的話，原型就只是一個輔助溝通的工具，原型做到多細取決於你想在溝通中向開發團隊、設計團隊傳達哪些信息。假如口頭溝通就可以清晰的把需求描述清楚，不使用原型也是可以的。

產品設計的實際操作過程中，一定不是先做原型

我對產品設計的理解是為了實現某一需求提出一個相應的解決方案，進而將方案產品化的一個過程

這個過程在我的工作中是這樣的：

可以看到，原型已經處於整個產品設計的末端了，產品設計的精髓在於對需求的分析，提出一個可行的解決方案，而實際工作中，產品原型也不一定是必須的

UI、UE、研發等這些如果非要放在產品設計中的話，我覺得應該在原型設計或者產品需求文檔產出之後

以上是我在工作中的一點簡介，也希望各位大神給點指導意見

各種產品文檔主要兩個目的：

1非技術團隊知道產品最終解決什麼問題

2技術團隊知道最終怎麼做出來，代碼怎麼寫

於是產品流程里，不同狀態標準是什麼，狀態之間如何變化，各種條件怎麼計算，視覺怎麼畫，各種視覺元素的形狀顏色位置速度，全都溝通清楚了，工程師才能寫代碼

至於如何實現這兩個目的，怎麼溝通清楚，每個團隊都不一定，文檔長什麼樣子也不一定，人員素質不同，產品領域不同。

我見過有前端工程師敲厲害根本不需要UI設計，也見過設計師敲厲害根本不需要線框圖。

有人成了嘴炮大師，有人成了原型圖藝術家，都是時勢使然

以下是個人觀點，非常偏頗。

看產品經理是什麼樣的人，然後再決定怎麼做，一定要在可擴展上留好後手，用通用性比較高的方案。

如果是真正了解需求的產品經理，做出原型，討論修改迭代，反覆幾次就能精加工做效果了，即便甲方有什麼奇思妙想，也能說服甲方放棄，或者比較快速的集成到現有的設計中去。

如果是傳話筒的那種，先拖上一周再說，如果可以的話，讓他自己先畫個簡單的原型。一天三改，連改一個月，沒有定稿，覺得多出幾個方案客戶總有喜歡的，直到開發完才發現平台都不對的，這種產品經理不是沒有。

原型做到邏輯清晰，功能明確就行，高保低保沒有什麼太大區別，把功能與邏輯解釋清楚就可以了。

首先我理解的題主的產品設計一定是互聯產品的設計，主要是網頁，網站，app應用，及其其他的應用或系統的操作界面等。

都是先做原型，是個是基本的流程。設計原型的目的主要是幫助產品設計人員理清思路，直觀的表達產品設計的思想，方便團隊間的溝通。原型本身就包含很多種，最最接的是拿筆在紙上或黑板上畫出簡單的框架，每個頁面或者頁面元素部分之間的關係等。我自己的工作中這種方式多屬於討論階段。不能算產品工作人員的產出物。正式交給UI的應該還是使用原型製作軟體製作出來的原型，

主流的AXURE ，墨刀等甚至畫板或ps都可以了。工具不重要，重要是能較好的把你想法表達清楚。

問題二：原型需要到什麼程度

這個真沒有明確的規定，各個工作情況都有所不同，有的公司也是UI和產品人員自行定義，流程成熟的公司會進行明確定義，一般的交互原型包含，包含頁面結構圖，業務流程圖，交互狀態說明，然後就是每張的頁面了。一般很少高保真，因為公司的項目時間都比較緊，除對屬於結果要高不可控風險較大的項目。

問題三：什麼時間給開發

首先定原型，原型定好後，給一份給UI給一份給開發，一般這個時候產品開始開需求評審會議，確定研發和UI的工作銜接的問題和評估時間給出明確的排期，UI負責進行視覺設計，開發根據原型內容搭建基礎功能。等設計完成後，在給的研發，研發把涉及到UI的地方很程序進行結合，開發完成，進入測試，測試完成項目發版上線。上線後產品交付給運營或市場人員進行運營。

原型是設計驗證的一部分，如果有把握可以直接實現，很多時候程序員實現的也是原型

產品在設計的過程中，最開始是捋順思路，這個時候可以藉助的工具有很多，腦圖、PPT、文檔、原型等形式都可以。而原型不僅可以作為整理思路的工具，還承擔著將設計思路呈現給別人的作用。

複雜的產品邏輯對應的原型往往也是一步步完善的，原型也較為完整，目的是讓對接的需求方、設計、交互及rd了解你的思路，而簡單的產品設計直介面述或文檔也可以表達清楚，原型不是硬性要求，只是一個表達工具。問原型要達到什麼程度的話，應該是可以表述清楚你的思路的程度。

在UI設計完成後，是直接開發，還是先做高保真原型，然後再開發？

個人認為高保真原型往往是不必要的，除非一些公司有硬性要求。在產品對接到開發的時候，有一個誤區就是將原型與文檔直接甩給技術，產品的工作就算結束了，這是大錯特錯的。產品在開發過程中要時刻與技術溝通，包括產品落地的技術方案取捨，項目進度時間等問題。將繪製高保真原型的時間花在與技術同學更好的溝通上，會使項目推進的更加順暢。

也不一定，如果開發人員在你講解完要做啥後，做出來的是你要的就行了

做一個產品，需要幾個角色的協作，產品經理、ui、前後端研發等，通常一個人做不來；

協作需要溝通，原型方便溝通，如果一句話能講清楚，就不用做原型；

至於做到什麼程度，能講清楚就行，文檔、流程圖、腦圖、原型、PPT，哪個能講清楚用哪個

原型肯定先於設計，不用想。但要知道的是，原型前面的東西，比如需求列表、腦圖、流程圖。

個人習慣是，第一步把所有要做或可能做的需求用 Excel 列出來，第二步畫腦圖，腦圖是包含一定的邏輯性和層級結構的，第三步流程圖，所有的交互邏輯必須完整，有時候結構和交互簡單的需求也會跳過這一步，第四步才到原型圖，不管低保真還是高保真，每個頁面的內容要完整，每個可點擊的元素的點擊效果是什麼，路徑轉化的邏輯是什麼。

簡單說來，設計不需要邏輯，它只是對原型的美化。

我說的不想前面大佬說的那麼好

我沒在大廠待過，但是幸運的是做了兩個獨立項目

首先我覺得，「產品設計實際操作過程中」是指項目立項到第一版落地吧？如果是，那麼一定要做原型的，因為你不僅要給開發看，還要給設計看；於此同時你還要根據你的原型講解業務

其次，原型也是你自己梳理邏輯和業務流程的重要環節

在之後，在UI設計之前，你的原型起碼頁面是完整的，你的邏輯是完整的，業務是閉環的。

然後，我的做法是，在UI出完第一版後，後面會使用他們設計的頁面進行原型圖設計，勉強算是高保真吧，這個看個人吧，我覺得是有必要的。另外交互我現在也是做的越來越多

最後，沒有原型圖直接設計的，好像真的比較少吧，設計也是要了解大概的業務流程的啊