做產品原型設計有哪些需要注意的問題？
不同的角色是不一樣的,如圖.AxureRP比較專業, Balsamiq Mockups 比較快速(線框圖,可以讓你不那麼注意細節).
受邀。1、交互要清晰表達。一個按鈕點擊後的交互雖然用面板的話，演示起來很漂亮，但是請讓拿到原型的設計和開發了解的更直觀，也就是把面板里的交互都放到外面來，哪怕單獨做一個按鈕的交互說明頁面。2、頁面邏輯表達清晰。所有的原型之前，如果可以，最好給一個頁面邏輯結構圖，說明上下頁面的邏輯；所有原型之中，如果可以，最好也給一個跳轉的邏輯說明，雖然可以單獨使用visio提供，但是不妨同時放到原型圖中。3、不要省略頁面注釋、描述。比如，hint雖然可以做在原型圖裡，但是並不妨礙你同時寫在頁面注釋中。4、不追求DEMO演示的華麗，而追求接手者能夠明白了解你的設計意圖。5、最關鍵的，畫之前先弄清楚給用戶的是什麼，畫之後看看哪些地方不必那麼複雜，交給交互和開發人員之前，想清楚，如果是一個急需上線的東西，而設計和開發可能告訴你有難點或不能原樣交付的時候，你的優先順序和你所能退讓的底線在哪裡。
原型存在的意義是以盡量地的成本快速把腦子裡的概念實例化，拋出來給大家討論溝通，投放給小範圍客戶做測試。
故在製作過程中應當注意：
1、成本低：
製作速度要快，能夠把頭腦里主觀的想法表達出來就好2、表達清楚：
產品策劃的原型要能表達用戶需求場景 交互設計的原型要能表達產品架構，任務操作流程，每一步操作的反饋 視覺設計的原型要能表達視覺風格3、快速迭代：
原型要便於修改，高度彈性。在拋給大家討論或給用戶測試後，收到一些反對意見，要能低成本地快速修改。總的來說，原型是一種思想。它有點像素描，先有大框架，再吸收意見，逐步細化。最終投放的產品，其實也只是原型的一個階段而已。
生命不止，產品的迭代優化不息。分析畫思維導圖（紙筆），構思畫線框圖（紙筆），做交互用Axure RP。
一些做Mockup的經驗分享：1、在構思好之後，先在左邊工作區將頁面結構列出來（命名），這樣容易劃分模塊並方便你和Engineer溝通時定義數據結構的雛形和ER圖；2、大量靠譜的交互要用Dynamic Panel做，想做的出色就必須掌握；3、按照你要設計的Feature功能區域，將做出的多個Patterns放在一起轉化成Master組件，定義的清晰，積累的足夠，以後的設計就像搭積木一樣方便；4、定義Widget Style可以方便你快速調整樣式，這在原型誕生後不斷調試很有用；5、希望優化你的Mockup視覺時，使用專門的獨立取色軟體，吸取要參考的色彩Hex碼，不要糾結於調色板；6、建議對所有要進行交互的Widget、Dynamic Panel、Master、Style養成良好的命名習慣（駝峰或下劃也應統一），方便管理和區分；7、為什麼要注意以上的細節？因為養成這樣的習慣符合模塊化思維，做產品就是做工程（我可不建議文藝范兒），工程就要嚴謹有序，在大工程量級時，模塊化前期不快，但中後期的優勢明顯；8、快和穩要兩者兼顧，不快則增加機會成本不能在工程實施前進行快速驗證，不穩（核心邏輯有問題或缺少足夠的實施規則）則增加返工成本和重構風險，迭代是核心思想；9、在內網搭建Axure RP多人協作工作環境（SVN），可以有效的將WBS之後的獨立頁面或Feature分配給合作者，Teamwork的效率會提升，且Mockup風格保持統一；
10、沒有一次可以Okay的「最終」原型，Usability Testing和AB Testing是少不了的。但前提是Mockup要細化到足夠的程度；1、表達布局結構2、表達邏輯流程3、表達跳轉關係4、表達狀態模式5、輔以文字說明6、不必過度交互效果
首先解決給誰看的問題。一般來說產品的原型，都是給領導或者投資人看的，並不是給技術開發、設計師看的。因此，要了解老闆或投資人的偏好。一般情況下，這類人為了節省時間，需求都是圖形化的。根本沒時間看詳細的流程圖和大段的文字描述。所以，框架圖（線框圖）+3分鐘的當面講解，是必須要做的。
1. 有需求概覽和更迭記錄2. 每個模塊的需求單放一個頁面3. 每個模塊需求內變更的每一點都用帶序號的氣泡標出，並在右方或下方按序分別說明4. 前台需求與後端需求分開說明，不要摻雜在一起，讓客戶端與伺服器的開發清晰的知道自己要做什麼5. 前後台的交互邏輯要說明，異常邏輯要考慮周全，包括但不限於字元長度、網路異常、數據為空時的各種情況6. 涉及到後台功能項的，一定要牢記「增刪改除」是四大基本操作，同時要考慮到不同數據項之間的關聯關係，比如數據項A要被應用到另一個數據項B的配置上，那麼A是不能隨便刪除的，要刪除需要先移除後面的配置項才能刪除。7. 涉及到前台功能的，要考慮後續要監控哪些指標項，並列好數據埋點需求，做好統計參數規定8. 所有功能的迭代，最好左邊是修改前的頁面，右邊是修改後要做的頁面，以便開發清晰了解改了哪些點9. 不要做交互效果，開發不知道哪裡有交互效果，也不會去一個個試著點開看，就畫出所有情況下的靜態頁面就好了，對自己對開發都省時間
最近面試產品經理時最苦惱的就是大多數PM拿畫原型當自己的看家本領。絕大多數PM對於原型的使用都是錯誤的，直接導致無效的團隊推動力。造成這個現象的最根本原因是自己本身缺少目標感——不去深思產品成功後應有的模樣，而去追求過程中的自嗨。
關於產品原型，你要記住兩點：
1. 產品原型是產品成功路上的墊腳石，就是要吸引大家來踩，踩過去了團隊才能往前走，踩舒服了，團隊走得快！
2. 通過一份文檔來解決問題的想法是幼稚的，文檔最大的價值是信息沉澱以方便日後回顧，當更多時候是因為大多數人都不願承擔責任。
所以你在設計和使用這塊「墊腳石」時，一定要首先注意：
1. 當前團隊處於什麼階段?目標是什麼？接收對象是誰？
2. 不要拿產品原型或文檔去說事兒，要開放，要就事兒論事兒
3. 千萬不要愛上自己的原型，你愛的是用戶，而且要讓團隊知道
有了上面的認知基礎，我們就能將下面一些具體技巧運用到位。目前大多數PM朋友接觸到的都是由leader或者老闆直接派給的，非常具體的推進任務。對於資深PM來講可能不是問題，因為要麼早已離開，要麼早已「打成一片」，什麼細節問題，一場球一頓分飯就能解決。
分享一下我作為產品新人時自己的一些技巧吧。應該是八年前的樣子，我第一次加入到一個人數不多的互聯創業團隊中。沒有人告訴我產品原型和文檔應該怎麼寫，在實際的推進中我產生了這幾方面的困惑：
1. 不知道要寫多細。到現在都清晰記得我問身邊的技術大牛要不要標清字型大小時他甩來到白眼。
2. 無法用一份原型來統一回答技術與設計夥伴的問題。比如Axure很適合做頁面邏輯的表達，但無法表達出數據以及介面結構。現在很多原型工具也有這個問題，雖然能讓你低成本拿到demo，但無法對數據結構進行討論，影響PM對於成本以及未來可能性的把控。
3. 總會有人產生疑問。會上定會下改，今天定明天改。
那是一個黑暗的時期，不僅工作量大還非常沒有效率——所有的改動都好像很急很重要，但並沒有對產品最終的效果起到明顯的推進作用。感覺自己就像一個整天到處救火隊的消防員，成天被點火的人愚弄。那時真的很討厭那些點火的人，可又不知道這些人是誰。是同事？老闆？難道在可以刁難我？但我們私下還真的挺開心的。而且大家還給了我很多建議，最多的一句就是「再多想想」。
當時我有一個習慣，就是回復完所有當天郵箱里的產品反饋再下班。記得有天晚上，公司剩我一個人，很疲憊地看著反饋列表時，發現了一條誇我們產品好用的評價。我不知道那條評價被我反覆看了多少遍，一個原因是確實激動，另一個原因是用戶並沒有寫出到底是哪個功能做的好，他只說目前只有我們能夠幫助他隨時找到身邊的商家。我突然明白了眼下最重要的事情是什麼——回復郵件表示感謝之後，繼續問他還有什麼不方便之處。
那晚上，我的腦海里出現了一幅圖，左邊是一個用戶，右邊是他想要的蘋果，中間是一個迷宮。我要最快地帶他走出迷宮，拿到他渴望的那個蘋果。
我發現之前我的做法都是錯的。我把團隊夥伴和老闆當成了我的服務目標——他們本應是站在我身邊一同為用戶服務的人。我們如何才能一起行動呢？其實很簡單，我們要一起面對用戶的問題。換句話說，我們面對的問題必須是來自用戶的。
後來我主動找公司進行如下改動——
1. 搭建redmine, 建立用戶問題庫（現在的工具很多，推薦confluence）
2. 僅針對問題進行討論。如果建議來自同事或老闆，我也當做用戶一樣對待。
3. 針對每個問題進行原型提案，大家直接拋磚，甚至工程師也可以一起提原型。
4. 最終由我來主持會議確定優先順序，並按順序打包成版本計劃——路線圖出來了！
這個帶來的直接效果是，團隊與我站在同一戰壕，都對如何更高效地解決問題產生興趣。初次之外還有幾個非常棒的效果：
1. 我不用再寫繁冗的產品文檔，僅根據問題進行提案，組織討論。
2. 我開始使用手繪來表達原型，因為足夠了，更多的細節設計師會跟進。或者他的主意更好。
3. 團隊非常清楚眼下的重點，知道要做什麼，大家關係更加融洽了。
我終於品嘗到了作為一名產品經理的成就和愉悅感。在多年之後，我才從《每個偉大的產品背後》這篇文章中再次確認產品經理無授權管理的深意：
1. 不要做團隊最厲害的人，要做最會發現問題的人。
2. 不要在意文檔的質量，要關注團隊使用文檔的動機。
3. 產品經理是管理崗，要讓團隊中的專業成員得到參與感，並發揮長處。
確實，完美的文檔並不存在！從此之後，我永遠只是最快拋磚的人。拋得越快，團隊跑得越快！
這個問題偏大。如果從選擇工具切入，我覺得選好工具很重要。之前看過的文章挺好，推薦一下：
我們在日常的軟體設計中經常會涉及到原型的設計。設計一個原型，無非就是三個目的：第一個目的是拿著給自己看的，為了方便之後的下一步設計；第二個目的是給開發看，說服開發，完善軟體；第三個目的是拿著給客戶看，讓客戶滿意，推動合作。
但是，在工作中經常有些小白同學拿著應當給開發看的原型去給客戶看，導致客戶不滿意，談判過程異常艱難；也有一部分人拿著應該給客戶看的東西去找開發，結果卻效率低下，有的會被開發拒絕，部分情況可能導致更嚴重的溝通問題。更有甚者拿著該給自己看的東西去給開發和客戶看，後果請自行腦補。那麼，究竟該用什麼工具做什麼原型給誰看？今天熊先生就來跟大家簡單討論一下，在目標明確的情況下，我們到底該怎麼辦。
一、給自己看
重點：草圖
工具：白板、紙筆、Balsamiq、Xmind
既然是給自己看的，那就沒什麼多說的了，隨心所欲的記錄下一切可能的想法，保證自己能看得懂，也就足夠了。這個階段里，外界的干擾越少越好。簡單方便的紙筆和白板就成了最好不過的工具，它們不會限制你的思維，任你想出無數想法。如果你希望把這些線框圖更有效的整理出來，可以使用Balsamiq，這款工具雖然沒有交互設置，但是其素描的風格相信也會為一些用戶提供靈感的來源。而且Balsamiq作為原型設計工具，組件雖然不是很多，但也完全可以滿足線框圖的要求了。當然，有些時候為了整理自己的頭緒，你可能還需要類似Xmind這種幫助思考的腦圖工具。
二、給開發人員、有經驗的客戶看
重點：交互
工具：Axure RP、Justinmind、Mockplus、UXPin
一千個讀者節就有一千個哈姆雷特，傳統的產品文檔雖然不是文學作品，但是一千個開發也會按照一個文檔給你做出一千個效果。如果你還在使用靜態的線框圖+文字描述的方法給開發看產品文檔，那麼熊先生建議你儘快試試上述四款工具。敏捷開發的情況下大多數團隊會採用原型+PRD的方法，之前幾百頁的文檔可能在加入了原型之後就變成了十幾頁。而且傳達的意思也更加的直觀，減少了誤解、提高了效率並加快了節奏。四款工具中Axure、Justinmind在功能上來說相對更加的全面，而Mockplus和UXPin則是比較輕快。個人還是比較傾向於後者，Mockplus、UXPin在功能上基本滿足了原型設計的需要。在某些特定的功能點上，比如變數和判斷，沒有做到Axure和Justinmind那麼完整。但是實際思考一下，花費了十幾分鐘甚至更久來設置一個判斷的交互，其實可能一句話的備註就說明問題了。同樣的，對於懂得軟體設計開發的客戶來說，時間寶貴，用最快速的方法表達出最接近客戶想法的設計不僅是對客戶的尊重，也是對你的工作專業性的肯定。所以，內行進行溝通的時候，Mockplus和UXPin這種更加輕快靈巧的原型設計工具在原型與備註相結合的情況下，往往會創造出更快、更好的效果。
三、給完全不懂的客戶看
重點：精緻度
工具：Origami、FramerJS
然而畢竟還是有一些會做生意但不懂軟體設計的客戶，這些客戶可能要你做一個99.999%接近真正App的原型。這個時候請使用上述兩款工具。為什麼這種不僅可以保證精緻度，還可以保證高保真的工具我到這個時候才拿出來？原因很簡單，兩款工具中，前者步驟相對複雜，後者基本依靠代碼。現在的產品開發過程可能真的不會給你這麼久去專研一個原型的效果，除非你是碰上了一個一竅不通卻又要求極高的客戶。這兩款工具無論是畫面效果還是交互動效都可以與真正的App相媲美，做到以假亂真的效果。不過由於要求高，時間成本高，不建議日常使用，可以留到最後以應防不測。
只有一點：做出與最終產品完全一致的靜態程序或頁面。包括每個功能模塊和所有界面細節。這個ProtoType與最終產品唯一不同就是它是死的、沒有動態數據。這個過程可以使用各種框圖、流程圖，但重點是最終呈現的成品，而不是各種框圖。用什麼工具也不重要，重要的是這個ProtoType必須經得起所有人的長期檢驗和質疑，一旦各個環節的人都覺得ok了，就不再大改。這樣做可以保證產品不被技術束縛，不為技術妥協，一切以最終成品和用戶為導向。
1.先腦圖把信息結構理清楚——信息架構2.再visio把流程、交互理清楚——產品邏輯3.根據前2步再畫原型。個人覺得一上來直接畫原型是不對的，容易有信息遺漏，也經常要反覆修改
要注意的問題還包括用什麼工具
我們在日常的軟體設計中經常會涉及到原型的設計。設計一個原型，無非就是三個目的：第一個目的是拿著給自己看的，為了方便之後的下一步設計；第二個目的是給開發看，說服開發，完善軟體；第三個目的是拿著給客戶看，讓客戶滿意，推動合作。
但是，在工作中經常有些小白同學拿著應當給開發看的原型去給客戶看，導致客戶不滿意，談判過程異常艱難；也有一部分人拿著應該給客戶看的東西去找開發，結果卻效率低下，有的會被開發拒絕，部分情況可能導致更嚴重的溝通問題。更有甚者拿著該給自己看的東西去給開發和客戶看，後果請自行腦補。那麼，究竟該用什麼工具做什麼原型給誰看？今天熊先生就來跟大家簡單討論一下，在目標明確的情況下，我們到底該怎麼辦。
一、給自己看
重點：草圖
工具：白板、紙筆、Balsamiq、Xmind
既然是給自己看的，那就沒什麼多說的了，隨心所欲的記錄下一切可能的想法，保證自己能看得懂，也就足夠了。這個階段里，外界的干擾越少越好。簡單方便的紙筆和白板就成了最好不過的工具，它們不會限制你的思維，任你想出無數想法。如果你希望把這些線框圖更有效的整理出來，可以使用Balsamiq，這款工具雖然沒有交互設置，但是其素描的風格相信也會為一些用戶提供靈感的來源。而且Balsamiq作為原型設計工具，組件雖然不是很多，但也完全可以滿足線框圖的要求了。當然，有些時候為了整理自己的頭緒，你可能還需要類似Xmind這種幫助思考的腦圖工具。
二、給開發人員、有經驗的客戶看
重點：交互
工具：Axure RP、Justinmind、Mockplus、UXPin
一千個讀者節就有一千個哈姆雷特，傳統的產品文檔雖然不是文學作品，但是一千個開發也會按照一個文檔給你做出一千個效果。如果你還在使用靜態的線框圖+文字描述的方法給開發看產品文檔，那麼熊先生建議你儘快試試上述四款工具。敏捷開發的情況下大多數團隊會採用原型+PRD的方法，之前幾百頁的文檔可能在加入了原型之後就變成了十幾頁。而且傳達的意思也更加的直觀，減少了誤解、提高了效率並加快了節奏。四款工具中Axure、Justinmind在功能上來說相對更加的全面，而Mockplus和UXPin則是比較輕快。個人還是比較傾向於後者，Mockplus、UXPin在功能上基本滿足了原型設計的需要。在某些特定的功能點上，比如變數和判斷，沒有做到Axure和Justinmind那麼完整。但是實際思考一下，花費了十幾分鐘甚至更久來設置一個判斷的交互，其實可能一句話的備註就說明問題了。同樣的，對於懂得軟體設計開發的客戶來說，時間寶貴，用最快速的方法表達出最接近客戶想法的設計不僅是對客戶的尊重，也是對你的工作專業性的肯定。所以，內行進行溝通的時候，Mockplus和UXPin這種更加輕快靈巧的原型設計工具在原型與備註相結合的情況下，往往會創造出更快、更好的效果。
三、給完全不懂的客戶看
重點：精緻度
工具：Origami、FramerJS
然而畢竟還是有一些會做生意但不懂軟體設計的客戶，這些客戶可能要你做一個99.999%接近真正App的原型。這個時候請使用上述兩款工具。為什麼這種不僅可以保證精緻度，還可以保證高保真的工具我到這個時候才拿出來？原因很簡單，兩款工具中，前者步驟相對複雜，後者基本依靠代碼。現在的產品開發過程可能真的不會給你這麼久去專研一個原型的效果，除非你是碰上了一個一竅不通卻又要求極高的客戶。這兩款工具無論是畫面效果還是交互動效都可以與真正的App相媲美，做到以假亂真的效果。不過由於要求高，時間成本高，不建議日常使用，可以留到最後以應防不測。
1.不要做得太漂亮，不捨得刪了。2.及早與其他人溝通，越早越好。
紙筆畫出線框圖，快捷易理解。體現產品理念，交互流程。待進一步確定方案後 ，細化原型。不同版本間需要有明確的備案。在一個產品從初始設計到最終定稿開發成可用的產品，總結設計稿，有別樣的收穫。
按我目前的工作體會來看，做原型的時候如果是在已有的產品上改動局部或增加新功能，那麼改動點可以微調出多種方案，給上級看的時候有個選擇空間，畢竟要審方案的人都比你有經驗，自己也沒有能力敲定最終方案，所以不如給幾種自己比較滿意的讓其選擇。
我的建議只有一點，保持良好的歷史版本記錄習慣，哪怕只修改了那麼一小揪揪的東西...
主要的還是要正確展示產品所想要表達的思想，不要過度重視交互效果
先可用，後好用。
第一步 先把產品定位搞清楚 還有核心的設計思路.
作為表達產品思路或提交產品需求的基本產出物，如果產品人員有較為充裕的時間，建議做到美觀和細緻，否則對於接受演示方會感覺產品不專業，對需求實施者會產生誤解，對於注重用戶體驗的老闆來說更是無法接受的，如果只用於自己整理思路則另當別論。下面舉例說明一些曾見過的原型粗糙問題：
排版粗糙
1、線頭未閉合，畫到邊界前就終止了，手繪還可理解，但總軟體繪製就說不過去了。2、元素溢出邊界，比如時間屬性，超出原型界面邊線。3、文字緊貼邊線，未給足內邊距。4、該對齊的元素未對齊。5、該居中的元素未居中。6、多個列表項的高度不一致，有25像素的，有23像素的……7、上層與下層元素本該重合的線條未重合，反倒形成了一個更粗的邊框。8、主次文案的字型大小及字色未作區別。9、表單等文案不齊整，有兩字的、三字的、四字的、五字的……如果辭彙量豐富，儘可能更換名詞促成整齊，比如：用戶名、密碼、手機號、身份證號碼、E-mail，可以統一為：用戶名稱、登錄密碼、手機號碼、身份證號、電子郵箱。10、有廢棄或多餘的元素捨不得刪，非要用中劃線或佔位符臨時遮蓋，對閱讀者造成干擾。原型不模擬
1、原型字型大小太小，在原型圖中首屏可容納200字，而根據實際情況只能容納100字，造成信息顯示預期未達成。2、列表內容都是重複或不真實的，比如標題項都寫為「標題」，未按真實文章標題長度來展示，無法直觀表達截字或折行效果。如果是實名制平台產品，用戶名就不要列一堆不切實際的名稱如「藍精靈」、「堂吉訶德」……3、列表項時間參數都是一樣的，無法直觀感受到列表是否需要按時間倒序排列。4、用想當然的圖示表達需求，比如畫一條橫線就完成了播放器進度條的示意，進度如何體現？是否需要拖拽操作？缺乏一致性
1、每個原型界面整體尺寸需一致。2、同一功能在不同頁面叫法不同，如「搜索」、「查詢」、「檢索」、「找一找」……3、數據單位寫法不統一，如文件大小有的用1M，有的用100kb，可統一為1MB與100KB，要麼1M與100K。4、時間格式不統一，有的用2017年9月10日 8點6分 有的用2017-09-10 08:06:325、界面用語風格不一致，如「請您稍後重試」、「親，請一會兒再試哦」……6、彈窗及提示樣式不一致。7、選用圖標的風格需一致，盡量用一套圖庫。規避以上問題並不需要耗費大量時間，僅需養成良好習慣。推薦閱讀：
TAG:產品經理 | 產品設計 | 交互設計 | 用戶體驗設計 | UXdesigner | UXDAward2012 |