起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識淺談產品方法論的二三事
編輯導語：一套正確的方法論對于產品設計整個過程來說十分重要，可以有效地針對不同場景去處理解決問題，本篇文章作者分享了有關產品方法論的相關內容，從四個方面詳細講述了其中的要點以及具體的方法，一起來學習一下吧，希望對你有幫助。
提起「模板」，其實質是一種別人解決問題的「方法論」，是針對特定場景的標準化處理辦法。與其去想著如何套用別人的方法論，不如去創建自己的方法論。一套自己掌握的方法論，是更適用我們個人的成長體系、能力模型、所處環境的。
一、為自己的設計辯護
“偉大的設計往往取決于你怎么說”在《設計師要懂溝通術》中尤其令人印象深刻。
無論是從事UI設計、交互設計亦或是用戶體驗設計，當然還包括產品設計，溝通在實際場景中是十分重要的，因為你面對的需求方，一方面往往是不具備專業素養的，另一方面很難在短時間內與你達成共情。
而對于產品設計，也是一直高頻出現的場景。無論是需求的發起方，還是方案設計的交付方，三方之間通信的橋梁無他，就是溝通。
1. 面對不同角色，說不同的話
設計出一套優秀的產品方案是很困難的，描述設計同樣不是一件容易的事情。
我們所面對的都是和我們所持不同立場的一群人，需求評審的強度往往不亞于一場辯論。
產品經理向要每一位開發，測試以及很多沒有產品設計經驗的需求方去闡明自己產品的設計方案，并且要讓他們信服自己是對的，這群人很可能包括方案的你的老板或者其他決策者。
通常情況下沒有相關專業知識儲備的決策者會選擇那個聽上去最合理的方案，所以方案的表述對于最終方案的確立至關重要。
2. 需要關注評審中的溝通技巧
初入職場的產品經理和經驗更豐富的產品經理之間的差距不僅僅是他們解決問題的能力，還有一點還在于他們能否用一種讓人心服口服、并促使人們同意的方式來闡述他們的方案是怎么解決問題的。
從理論來說，最好的方案應該被推崇，然而事實并非如此，需求評審很容易變成方案的批判會，每個人都好像是在告訴產品經理這個方案不夠好，需要怎么去調整。
最終，那些能夠說服別人“這樣的方案更合理”的人會脫穎而出。
所以產品如果沒有辦法說服別人為什么他們要這么做，就不得不按照他們不同意的方式去修改方案，原因很大程度都是因為他們沒有辦法去為自己的方案進行更有理由，更加充分的辯護。
3. 說服別人，有時候比方案本身更重要
有些人可能會覺得，這么主觀的決策有失公允，甚至成了需求評審的辯護大會，各自說各自的一套陳詞，那么對于一些有著出色能力卻不善言辭的產品經理而言，打擊無疑是巨大的。
因為我們需要保障產品的一致性，例如產品的核心操作方式保持一致，這樣就可以有效地降低用戶的學習成本，避免不必要的思考等等因素。
我們這種所謂面面俱到的考慮，并不會讓所有的人受益。在產品開發生命周期的各個角色當中，每個人都在為自身的利益在爭取，產品所面對的，其實是多方面、多維度的矛盾。
所以我們不得不去依仗溝通的技巧，去完成產品的這些考慮。
4. 一點感悟
我不會去講述，你該如何如何去做，每個人的性格、處事方式、面對的場景都是不同且復雜的，相當于在含有無限個參數的X元Y次方程中尋找一個最優解。本文更多的是強調溝通的重要性。
實踐——反饋——總結方法論——實踐驗證——糾偏——完善自己的方法論。
提煉出別人方法論里的長期不變的部分，作為“公理”，作為日常解決問題推理的起點。
產品就是對現實世界的建模。
二、去偽存真，挖掘深層次的需求帶來更好的用戶體驗
俗話說不打無準備之戰，在我們評審或者分享我們的設計時，光靠溝通技巧肯定是不足以去支撐的。
做產品最重要的就是去挖掘需求，在實際工作中，我們有來自各業務方的需求，有內部系統的需求等，但并不是所有的需求都是真實的。
同樣做產品不要被表面需求所蒙蔽，比如當我們去分析一個東西的時候，需要不斷去剖析背后的真實想法。
1. 提出假設
我們設定一個需求場景：用戶A在上海工作，安排明天去出差，需要買一張火車票去北京。
我們可以知道用戶A的基礎需求：買一張從北京去往上海的火車票我們需要提供的能力。
創造出一個能買火車票的平臺，使得用戶可以完成在平臺上完成查詢，購買，訂單等基本功能。
那這樣就足夠了嗎？
2. 開始不斷挖掘需求背后的故事
當然滿足基本需求是已經完成了，那如果我們能提供更好的服務會怎么樣呢？
下面開始挖掘上層需求：不僅可以查詢到當天各列車的信息，同時包括車次、途徑各站點及發車時間、票價、剩余座位、車次狀態等。
那我們如果提供這樣的服務會怎樣呢？用戶A可以借助這些信息，更合理的安排自己的行程。
再如果，我們提供了價格更優，行程時間更短的特價機票呢，用戶是否會選擇修改出行方式呢？通過良好的服務為他的下一次出行選擇本平臺而創造潛在的機會，就會帶來長期-低頻的留存。
三、正確看待馬斯洛需求層次理論
1. 如何分析真正的需求
美國心理學家亞伯拉罕·馬斯洛（Maslow.A.H.）從人類動機的角度提出需求層次理論，該理論強調人的動機是由人的需求決定的。
而且人在每一個時期，都會有一種需求占主導地位，而其他需求處于從屬地位。
人的需求分成生理需求、安全需求、歸屬與愛、尊重需求和自我實現五個層次。我們通過需求層次理論做支持，以便于我們更好的分析。
想要獲得商業化的前提就是讓用戶接受我們的價值，在我們的產品中體會到獲得感并能夠持續使用產品，并探索出產品性能與用戶滿意度之間的良好關系。
每個層次的概念或者說明網上已經有很多了，在此也就不再深入贅述，建議多結合業務或實踐去理解，而不是生搬硬套，這樣能更好的加深印象。
現有網上的馬斯洛需求層次理論是多少層，各說不一，有堅持最基礎5層的，也有6層的甚至7層、8層理論。
2. 眾說紛紜的“馬斯洛需求層次理論”
- 6層理論——在自我實現的上層新增《自我超越》的需求，以達到心流體驗。游戲策劃肯定知道，游戲設計中很重要的一個設計就是心流，心流是指人們在當下的一種情緒體驗，此時此刻，人們對某一活動或事物表現出濃厚的興趣并完全投入其中。精神分析學家 弗洛伊德在《心理動力論》中提到的精神三大部分，本我、自我、超我用來解釋意識和潛意識的形成和相互關系，也是支持6層理論的基礎。
- 7層理論——在5層的基礎上，自我實現的需求前增加求知需求和審美需求，其實也就是將成長性的需求更加的細化所建立的。
- 8曾理論——在7層的基礎上，增加自我超越的層級。
完整版本的馬斯洛需求層次理論是多少層，各說不一，也不用爭論，我們做工作，應該形成自己的一套思維體系和完善方法論，馬斯洛需求層次理論只是一種借鑒。
況且，需求分類不止有馬斯洛進行過分類，還有很多分類方法，我們做產品不光要有人本主義理念，唯物主義也有其產品哲學參考價值的。
我們的產品落在哪個層級上面，針對這個區間，再進行詳細和科學的分析，才是更合理的。
四、以用戶為中心的思想去解決問題
1. 什么是以用戶為中心
接下來我想介紹一下以用戶為中心的產品設計理念，UCD（User-Centered Design） 譯為“以用戶為中心的設計”，這是一種設計方法，也是我在做產品初期、對產品意識形態都比較模糊的時候作為一種啟蒙的解決方案模型。
我之所以使用這套理念，是因為在我的產品初期階段，習慣于先去夯實產品基本功底，比如很重要的產品原型的設計能力，但最重要的是我剛開始工作的職責范圍還需要肩負起交互設計師的內容（當然也可能是很多公司的常態）。
UCD的方式不局限于界面設計或設計技巧，而是通過不斷融合用戶的思維，將初期階段的產品設計不光局限于功能設計上。
UCD 的核心思想非常簡單：在開發產品的每一個環節，都把用戶列入思考范圍。UCD 提供的是多階段問題解決方案的模式化思想，要產品owner站在用戶的角度去思考，如何使用產品進行分析與假設，還要模擬出在真實的使用環境下進行測試、并不斷“校正”產品。
2. UCD設計的主要流程
一個完整的設計開發項目大致分為6個階段：
1）第一階段：基礎調研——尋找和評估機會。
①競品分析 ②市場調研 ③決策因素 ④創新 or 優化 ⑤商業可能性
這個階段的產品輸出是MRD市場需求文檔，包括用戶調研數據，市場分析數據，競品分析報告等。
不過根據個人實際工作經驗來說，這個階段不會由新人去或者說在現在版本迭代這么快速的進程中，這個階段往往是由老板或者你的上司決定，你所做的不過是些無足輕重的輔助材料。
2）第二階段：定義產品——廣泛聽取意見，收集用戶需求，規劃產品走向，探索出具有功能性和設計性的產品。
Kano模型作為分析用戶需求對用戶滿意影響的工具，在此階段可以很好的解決對于用戶需求優先級的排列。從而確定你的產品MVP（最簡化可行產品）形態，從而對你的用戶進行告知，并根據用戶對你的反饋來不斷修正你的需求。
這個階段的產品輸出是PRD中的需求說明部分，包括內容excel的規劃清單等。
3）第三階段：交互設計——功能之間的縫合劑。
此階段交互非UI交互，而是功能交互，你需要將需要實現的功能通過線框圖進行串聯并說明功能間的交互方式，能夠讓開發團隊對整個產品有個大致的方向。
這個階段的產品輸出是PRD中的交互設計部分，包括線框圖等。
4）第四階段：原型設計——描述用戶界面中元素及之間的邏輯和關聯，形成一套完整的、可模擬的產品原型。
更注重UI交互，交互的元素顆粒度更細，如果說上一階段是系統/功能之間的交互，那么此階段就是組件/元素之間的交互。
這個階段的產品輸出是PRD中的交互設計部分。
5）第五階段：詳細優化——不斷打磨細節，將設計中的要素標明。
需要將你的設計抽絲剝繭般的描述出來，你描述的越細致，后期同開發的矛盾越少，返工的幾率也就越小。
這個階段的產品輸出是PRD中的功能描述部分，一般需求文字結合設計圖進行詳細的描述。
6）第六階段：微調維護——進行可用性測試，評審通過后開始Debug你的產品形態，直至輸出完整產品。
這個階段的產品輸出是產品上線前的驗收與上線后宣講等準備工作等。
與其他產品設計理念不同，UCD 對用戶使用產品能做什么、想做什么、需要做什么的思考方式來優化產品，而不是強迫用戶改變使用習慣來適應產品。
五、后記
在軟件工程中，設計模式是一套代碼設計【經驗的總結】而產品方法論是一種思維模式，可以類比于軟件工程中的設計模式，在需求設計中【合理的】運用方法論可以[巧妙的解決很多問題]，但又不完全相同，方法論沒有具象的框架，需要在抽象的世界中不斷具象需求，以應對各種未知的挑戰。
作者：WāngWénhào；
本文由@ WāngWénhào 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議。
是否還停留在偏執行階段
指的是哪方面呢
當我們去分析一個東西的時候，需要不斷去剖析背后的真實想法，而不是表層含義
是的呀，有時候多深挖一層，會了解到意想不到的東西