筆者從整體上講了畫原型這件事的要點，以及如何通過畫原型體現出產品經理的專業性。
記得面試產品時，面試官曾經提過一個問題：「你覺得身為產品經理，你的專業性是如何體現的？」
如果只是會畫畫原型，寫寫文檔，那麼你一年和十年的產品經驗，其實沒什麼區別。
後來在工作中，也會經常想起這個問題，會反思「身為產品經理，我該如何體現我的專業性？」也有了一些自己的收穫感悟，以後再說。
今天主要是針對產品入門的新人，比如0-1年的產品經理。解決如何儘可能完善地畫原型問題，不至於因為疏漏太多被頻繁Diss。如果你正好有這個困惑，OK，看這一篇就足夠了。
一、比畫原型更重要的，是在畫之前想清楚要做什麼
很多小白剛入門的時候，包括我自己，會特別注重體驗，特別是一些細節交互、頁面展示，覺得一個好的產品應該是外在完美無瑕，內在賞心悅目。
其實，出現這種情況大機率是這個階段的產品經理，除了外在體驗層，其他的也說不出點什麼，比如業務流程、底層邏輯、商業模式這些高大上的內容。
有一個建議，可以幫助小白稍微進階一步：就是要有意識地讓自己變成以目標為導向的產品經理。
不論是負責一個功能模塊還是負責一個整體項目，你的每一步行動一定是有很明確清晰的目標驅動，而不是我覺得應該怎麼樣，我認為這樣會更好。
以目標為導向，會讓你從細節中抽離出來，更關注整個流程的關鍵節點，有助於把精力花在關鍵節點上。宏觀角度看問題的產品經理一定比微觀角度看的成長更快一些。
再說畫原型，不用在意是畫上草稿紙還是使用Axure/Sketch/墨刀，找一個你認為順手的就OK，絕沒必要太過於重視。工具的目的是為了讓你提升使用效率，而不是深入的學會使用工具。
因此，在畫原型之前，你的腦子裡應該很清晰的知道你要畫什麼，你每一個主頁面需要哪些元素，主流程是什麼樣的，原型只是將你的想法可視化。所以，產品經理的價值腦中想法是99%，原型呈現是1%。下面我們直接進入畫原型階段。
二、畫原型的步驟及檢查清單
講這部分內容之前，有兩個想法，產品經理應該早點知曉：
- 即便是最牛逼的產品經理，也無法輸出滴水不漏的原型。所以，原型在輸出時，有所遺漏是再正常不過的事兒了，要接納它，沒必要因為這個而否定自己。這個很重要。
- 最終影響一個產品/功能成敗的，是你是否打中用戶的那個點，是否解決了用戶某個問題。所以，多花精力在主流程的關鍵節點上。只要主流程不頻繁發生變更，那剩下的就是些細枝末節的完善。
所以，畫原型，第一步把主流程捋順畫出來，剩下的就是查漏補缺，達到相對完美狀態的原型，是專業性體現的第一步。
主流程就不多說了，如果產品小白主流程有問題，那說明基本的業務能力不過關，不是這裡可以解惑的。接下來我就重點介紹下從哪幾個方面查漏補缺。
1. 頁面所有元素，都一一列舉，有明確的規則和說明
這是產品設計輸出文檔時，養成的習慣。一一列舉，可以最大化防止漏掉細節內容。特別是對於產品小白，可以用這樣的方式開始你的工作之旅。
2. 考慮文本最多展示幾行、最大字數極限、超過極限該如何處理
即便是信息化的今天，文字仍然是最核心的呈現內容。因此，只要是文字，就需要考慮文字的行數/字數/極限值處理，如果能形成約定俗成的規範當然更好了。否則測試在這些小問題上追著你不放，就很尷尬了。
3. 頁面的每一個元素都要想清楚是否支持動態可配置
考慮到以後的擴展性，每一個功能區域是否動態控制顯隱，元素內容是否可靈活配置，文案是否支持動態修改。這些都是在產品設計時需要考慮的。
當然，一般情況下，大家約定俗成的是不可動態配置，因此，需要動態配置的時候，一定要明確標出來。否則做到最後想改動，可就沒那麼容易了。
4. 考慮可觸發區的狀態：業務場景不同，狀態也會不同
主流程一定是正常狀態，但是業務場景不同，狀態也不同。比如最基本的可觸發、不可觸發，還有隨著業務進程不同，展示不同的業務狀態，這個要想全，作為對主流程的信息補充。
- 業務狀態：行為發生前/行為發生中/行為發生後
- 數據狀態：有數據、無數據
- 時間狀態：未開始/進行中/過期下線
5. 考慮設備、版本、平台三個系統級別的影響
設備：是否要兼容平板電腦、小屏手機，是否存在橫豎屏切換。基本就這兩個關鍵點。
版本：這個很重要，因為很多產品小白很容易忽略。在設計的產品是否要兼容老版本用戶，如果無法兼容，是否會影響老版本用戶的使用。如果需要兼容，當下的設計是否能支持到，是否有強制升級的必要。特別是在做原有功能優化重構的時候，這個問題更需要慎重考慮。
平台：這個考慮多見於H5開發。因為需要用一套代碼適用於多個平台，要考慮H5與APP的平台差異性。比如返回方式、分享觸發，以及體驗的流暢性。
6. 是否有必要新手引導，換一個視角審視功能
對於新用戶，是否有必要做引導說明，從而達到了解新功能、快速上手的目的。
7. 讓人頭疼的網絡問題，也是必須考慮因素之一
考慮到網絡慢、網絡加載中、加載超時、中斷、重新加載、4G與WIFI切換等等一系列情況下出現的場景並設計出合適的解決方案。當然，這個在做過一兩次後，一般可以形成一套約定俗成的網絡處理方式。像這種全局頁面都涉及的規則，單獨拎出來會更清晰。
8. 登錄狀態與用戶角色
考慮到業務是否有必要區分登錄用戶與遊客用戶，在何時觸發登錄。業務的用戶角色是否存在多樣性/階級性。多樣性指平等維度下，不同的角色。比如護士、醫生。階級性，比如普通用戶、VIP用戶等。
9. 反饋提醒機制是否完善
比如常見的toast反饋提示、二次確認機制等。這個就不贅述了。
10. 是否過度設計，每一個元素是否為必須元素
從用戶視角看整體功能，是否頁面每一個元素都為必須元素，是否存在為了設計而設計的嫌疑，是否真正做到了MVP，是否可以讓整體功能更加極簡。
基本上做到上述金十條，你被Diss的機率能降低很多很多，接下來是畫完原型之後，會有很多的後遺症。因為，畫原型只是第一步，如何讓你的原型被更多相關人員所熟悉認可，並且能夠按照原型輸出你預期的產品效果，才是最關鍵的一環。
三、畫完原型的後遺症，最佳解決方案
需求交付後，就到了產品最常見的一個環節——改需求。
改需求無須避諱，原因很多——或是業務調整，或是自己的疏忽大意，或是大boss的突發奇想，太多了，所以很正常。
而且，你細品，其實產品被Diss，不能說80%，起碼有50%不是因為改需求本身，而是因為改需求的同步或者處理方式。
好吧，這個數據也是拍腦袋定的，關鍵是如何解決這些後遺症。
以下是幾點很實用的建議，源自本人總結的血淚教訓：
1. 改動任何一個地方，一定要著眼於全局，充分考慮這個地方對全局帶來的影響
這個很重要，特別是需求評審-交底之後，只要有改動，第一時間一定是先考慮影響面。甚至有些影響，需要核心研發人員參與評估。
2. 涉及到後端控制台設計，一定要先和控制台的使用者（大多數是運營人員）溝通，畢竟能直接接觸到服務用戶
這個可能沒有太多的借鑑意義，但是，如果能一步到位，做出運營人員操作流暢的內部配置控制台，本身有助於產品工作效率的提升。
3. 產品沒有標準答案，但是也絕不能模稜兩可
畫完原型後一定有很多不確定的地方，一定要提前確定好——可以從目標導向去考慮，也可以參考競品。實在不行可以找同事商量，上司敲定。
但是，切忌模稜兩可，沒有明確的結論。
把結論交給研發、測試去猜、去盲目做，是產品最愚蠢的決定。
產品，是要給用戶確定性的。
這個很重要，這裡面的用戶就包括了和你合作的UI、研發、測試，也是衡量一個人是否靠譜很關鍵的一個因素。
4. 改動同步給每一個人，是原型輸出後優先級最高的事情
當完成需求交底後，就意味著你的原型進入執行階段。
當執行階段有改動，比改動本身更重要的是如何同步，否則後期的撕逼無窮無盡，你也會被印上不專業的標籤。
而同步的方式，至少要做到當時忘記之後仍可追溯，因此寫在原型里/寫在說明里/發到群里@相關人員。
放心吧，一定會有人沒看到而遺漏。因此，最好的方式就是郵件同步相關人員並在群里提醒。大家因為改動未同步帶來的情緒要比改動本身大很多很多。所以，不需要懼怕被貼上頻繁改動需求的標籤，而是第一步先確保把同步工作做好。
如果改動影響較小，那當然OK，同步後皆大歡喜。如果改動了主流程相關，一定要及時與研發交涉，以便提前得出對排期的影響。這個對整體進度把控很重要。
5. 產品經理要帶些鋒芒，學會否定別人的想法
在這個人人都是產品經理橫行的時代，如果你按照上述步驟做了自己該做的原型方面的工作，仍然有人各種不滿和抱怨，甚至對你的原型內容提出質疑。
不要怕，產品是質疑成本最低的工作。吐槽質疑再正常不過，如果合理，虛心接納。如果不合理，直接否定。這個職業，本身要帶些鋒芒。
END
好了，這篇文章到這裡就結束了。回顧產品經理之路，恐怕大多數人花最多精力的就是畫原型和跟疊代了。因此，如果是小白，可以讀讀，提升自己的基本功，不斷成長。如果不是，也可以讀讀，對照自己的日常工作，提升下專業度。
希望這邊文章能通過我被Diss的教訓，幫大家儘可能減少被Diss的次數。
新年快樂！
本文由 @御風而行 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。