產品經理和交互設計師意見不同的時候，該怎麼決策？

12-26

先引用一下我翻譯的Marty Cagan著作 Inspired: How to Create Products Customers Love 中的內容：

以我的經驗來說，產品團隊內部產生重大分歧的大部分時候，並非是對當時情況的事實有分歧，而是因為每個人對目標和目標的優先順序別有不同的理解。
在作產品決策之前，應該先確定決策要解決什麼問題，讓大家在以下幾個要點上達成共識：

究竟要解決什麼問題？
要為哪類人物角色解決這個問題？
產品要達到什麼目標？
每項目標的優先順序是什麼？

回到這個問題，產品和交互意見不同，那麼雙方是否有溝通過對某個做法的處理是針對地解決哪個需求的？對於那個需求的理解，你們達成一致了嗎？交互設計師理解了真正的需求和問題所在了嗎？交互做出的設計是否能解決那個問題？如果交互設計師確實明白產品的需求，那麼產品人員應該去了解交互設計師從專業的角度是如何考慮的。
一切從真正解決問題，滿足產品重要的目標和用戶需求出發。

引用一年前我與老大的郵件交流：
------------------------------------------------------------------------------------------------
misa:

交流一個問題：產品設計、視覺設計討論或評審時，
各方出現意見分歧，誰來最終決定？

設計，的確是人人都能參與；關於「好用、漂亮」，每個人理解都不一樣。似乎，每個人都有發言權。但最終，誰來拍板？

目前的產品任何環節的評審，幾乎是全民參與的，全民投票拿主意，少數服從多數。

這樣的決策方式，看上去很保險，全民通過，但其實很不靠譜，很危險（至少，對於設計，是危險的）。

這樣的決策，不過是，各方不斷的妥協。
每一次，妥協，妥協，只有妥協。
妥協出來的產品，必定是個垃圾產品。
逐漸，產品失去鋒芒，設計師失去鋒芒，團隊失去鋒芒。

我一直認為，專業的事，專業的人來決定。

一個問題，出現不同觀點時，個人認為，理想的決策方式是：
1.每個人都可以提出自己的觀點，主任設計師來收集建議；
2.但最終決策，在於主任設計師。

既然，設立設計師這個職位，既然招了這麼個設計師進來，那麼，就
該給設計師足夠的信任與許可權，並且通過制度與流程來保證。
這樣的決策形式，看上去有風險，但卻是安全的。或許，設計師會犯錯，但這是新生團隊成長過程必須付出的代價。但如果老犯錯，這個設計師就有問題了。

有了信任與許可權，設計師因此得到信任感，被認同，成就感。同時，他回饋給團隊的是激情，自我的提升與改進，對成員的尊重、信任。整個團隊也能健康的發展。
（當然，這個對設計師要求也比較高，足夠的能力、經驗、判斷力，同時也要足夠的謙卑，能聽取他人的建議，而不是「一意孤行」；所以，建議公司近期擴張，招設計師時，一定是，寧缺毋濫，精選。）

個人近期混戰的感受，寫的有點亂。

另外，我比較喜歡的團隊氣氛是：作風低調，產品霸道。

更新：
近期的一點思考：風格之爭

@史飛說的不錯。但是相信樓主的事情成為問題，是因為有交叉。比如產品相信這個按鈕能提升活躍，但是視覺認為放這個按鈕影響美觀。

這時，其實換個角度考慮，問題也很好解決：
為產品發布的結果承擔責任的人，做決策。

責任和權力一定是對稱的，這是基本的管理原則。

創業公司應該是開放的文化，初期團隊配置未必很完善（產品經理，用戶研究，交互設計，視覺設計，原型製作這五方方角色不太可能也沒有必要苛求都有非常好的人才），從我們的切身體會看，面向行業應用的（客戶有相對明確的業務需要的情況下），通過科學的決策流程和機制（參見INSPIRED

究竟要解決什麼問題？
要為哪類人物角色解決這個問題？
產品要達到什麼目標？
每項目標的優先順序是什麼？

），充分討論，不以職位高低、是否強勢為決策依據，每個成員學會傾聽別人的聲音，真理只會越辯越明，在這樣的氛圍中，民主集中，產品負責人最終決策；
但是面向公眾用戶的個人應用產品，尤其是原創類的應用，產品團隊幾類角色中最具備該產品目標用戶的經驗的人的意見應該占較大權重，如果還是爭執不下，找到具備超級用戶體驗師能力的第三方，結束爭端，統一思想。
很多產品經理受「偏執狂才能生存」思想的影響，但如果方向性偏差，給產品、給項目帶來的損害是無法彌補的。很多人知道 Steve Jobs Office Sayings "有好的想法要堅持，不要被其他人的觀點的雜訊掩蓋了你真正的內心的聲音"這句話，但還有下一句:"當你的想法站不住時，立即大度的丟棄，這其實是一種堅持"。

看了好幾個回答，說的都有各自的道理，尤其是OurDearAmy 提出來對於為什麼有分歧的解釋，但是我想題主想要問的是，如果真的出現分歧的話如何去negociate到最終能做決策並且move forward，這裡就涉及到幾個不同層次的問題：

首先要明白的是，本質上任何決策都沒有對錯之分，只有在這個時刻和場景下是不是最合適之分。
其次，作為設計師，我們可以問自己一下幾個問題：
1. 我們是否真的明白PM的立場，為什麼會有分歧，分歧點在哪兒里
2. 我們是否真正從各個方面思考過設計要解決的問題，如果是的話有沒有事前考慮到PM會提出來分歧意見，如果有想過，設計中能不能address the problems?
3. Prioritization：在我們心裡，這個問題是否真的重要到我們無法『退讓』的程度，或者說某種程度上是我們思考的不夠全面
如果上面的問題都思考過一遍，得到自己的答案之後，很有可能所謂的『分歧』也不再是分歧，而是另一種Idea, 結局可能就是PM和設計師一起Push出來一個更好的產品。其實PM和設計師並不是站在對立面上的，而是不同的角度看待問題。一個成熟的設計師，會選擇合適的battle to fight for.

至於關於決策的問題，也不應該當做是single decision來看待，而是一連串的行為，現在這一刻看起來是讓步的決策，很有可能就是為了下一步bigger impact做的鋪墊。

我也奉上一封郵件。
------------------------------------------------------------------------------------------------------
大家好，

今天下午產品討論會上，我和產品經理就產品設計的細節問題發生爭執。
首先向各位參加會議的同事道歉，我當時有些激動，所以中途離席。我感覺到產品管理的流程或方法產生了問題。我是對事不對人，我並沒有針對任何個人有任何偏見。我也不是對任何異見有所不滿——相反，我很喜歡不同思想的碰撞——而是大家是否有權利發表意見，特別是在產品會議上就用戶體驗的細節問題，誰應該是最終決策者。

我們公司一直秉承的互聯網公司的平等、開放文化，大家崗位不同，只是術業有專攻，而沒有高下之分。
我們的立場是一致的，都是為了做出更好的產品——這是我們召開產品會的前提。
大家可以就具體問題各抒己見，最後做出最接近正確的產品決策——這是我們召開產品會議的目的。

當前我們的產品實行產品經理責任制，產品經理對於產品的一切相關問題都要考慮，要填補各個部門之間的業務空白，責任和壓力都很重。產品經理對產品的成敗負責，會像愛護自己的孩子一樣去愛護自己的產品，這是非常值得倡導的。而頭腦風暴的會議是有必要的，產品、運營、開發、測試、設計、用戶體驗、運維等各部門的積极參与集思廣益，往往會從不同角度帶來不同的思維方式，帶來很多創造性的新見解，並且可以大大降低因為個人盲區或失誤而犯錯的風險。

一個月前我離開具體的產品經理崗位，受命對所有產品的UE負責，但至今UE部門尚未建立，所以無法按照常規的流程，從一開始的信息架構、交互設計的階段介入（更談不上早期的用戶研究階段了），只能抓一些關鍵環節上的問題評估和跟進。我自知對於UE絕對算不得專家，許多產品經理比我對於UE都有獨到見解，而且每個人對於UE都有自己的體會，所以如有任何建議不妥，歡迎大家隨時批評指正。

以上算是交代了背景材料：）
下面我從微觀和宏觀兩方面來討論今天所遇到的問題。

一、會議上的一個爭議問題
一）下面這個界面是兌換流程的最後一步，請各位把自己假想為一名為了想要的收費應用已經努力賺了足夠積分，現在正在嘗試兌換獎品的用戶，當點下一個「兌換」按鈕，通過扣除積分的確認，切到這個界面，你第一眼看見時，可否預期自己該怎麼操作，是否在哪裡感到什麼問題嗎？（請大家用十秒時間思考一下，若想到不明白的問題，可以回復。）

1.這個頁面的主要功能，大家的看法是一致的：用戶點擊「立即使用」，然後跳轉到Appstore完成下載安裝；而會議上的分歧在於：當前這樣的設計是否易用。
2.我認為這裡的主要問題是：「複製」等輔助功能干擾了主線功能。用同理心去判斷，用戶可能的疑惑會有：
1）「複製」按鈕用來做什麼？（會議的時候有位同學提到，複製按鈕在平時的App里是很少看到的。複製按鈕放在這裡顯得突兀。）
2）是否只有「複製」之後，才能「立即使用」（去往Appstore需要粘貼或輸入兌換碼）？
3）「分享返回積分」是把兌換碼分享給朋友，還是把得到兌換碼的消息告知朋友？
4）兌換成功了，為何還要有兌換碼？（語義不精確）

通過詢問產品經理，我了解到，設計「複製」按鈕，是為了讓用戶可以複製粘貼到備忘錄或簡訊、郵件、其他App，以供保存兌換碼或分享給朋友。而在Appstore，是無需粘貼或輸入兌換碼的，數據可以直接傳遞過去。
我從產品和交互兩方面來說：

1.複製保存到備忘錄、分享兌換碼給朋友的功能，是否是主流用戶的需求？

產品設計時，我們必須要考慮主流用戶特徵：他們為完成某項任務而來，永遠不會產生學會所有功能的想法。口頭禪：「我的手機只要能打電話、能發簡訊就行了。」（《簡約至上》），具體到這個兌換頁面，我們要從兩方面的權衡：
1）用戶在兌換時候的主體需求是什麼，最期望達成什麼效果；
2）產品經理在定義功能時，最期望用戶完成哪個任務。

對於問題1），我認為大多數用戶是希望儘快完成兌換流程，得到自己想要的應用的。
從需求層次上來說可以這樣衡量產品：有用性（通過用戶研究和產品需求定義來保證）、可用性（通過BUG測試來實現)、易用性（通過交互設計來優化）、樂用性（通過對用戶情感依賴、用戶價值實現等方面來完成）；
這里先說有用性、易用性兩個概念，它們是結合具體使用場景的相對概念。這裡的複製按鈕，儘管對於少數希望複製下來保存到備忘錄里的用戶來說有用，省去了一步長按複製的過程，要易用一些，但對於大多數用戶來說，卻是不友好的干擾選項。這時我們要權衡的是，會去複製並保存到備忘錄的用戶有多大比例？

第2）個問題，我們期望用戶把成功兌換到付費應用的消息分享給更多人知道。所以下面那個分享按鈕，也是可以保留的。但可能要重新命名一個更適當的名字，避免分享的歧義。

2.完成分享或保存的需求，這樣的設計是否易用，可以怎樣優化交互設計？

會議上臨時討論的方案是去除複製按鈕，如下：

這樣雖然只是去除了一個按鈕，但已經大幅改善了任務流程的用戶體驗。
當時設計師、張老師、幾位前端同學，在這個方案的基礎上也補充了一些滿足分享或保存的小眾需求的辦法：支持長按複製，或者直接拿本子記下來。
我認為這是可以接受的。為什麼？因為這不是任務的主要功能。
用戶可以容忍邊緣需求不被滿足，但不能忍受主要功能的糟糕體驗。產品經理要緊緊抓住的是針對典型用戶群、典型使用場景的功能定義。這是我的一個觀點。回想一下我們訪問過的網銀界面、機關政府網站，為什麼那麼難以使用？因為他們總是在擁擠的界面隨意塞滿文字鏈接和按鈕！這些按鈕必然是在某些場景下有用的，但卻嚴重干擾了主要流程。再看看我們手中的iPhone，這樣簡潔的產品設計，究竟割捨掉了多少小眾需求？

二）會議上對於具體問題的爭執，其實沒有錯的，大家觀點不同是因為角度。這裡我只討論一下從職責不同的角度看到的問題。
1.會議上，相關的產品經理指出這是一個小問題，不值得反覆爭議。
a.這個問題不是邊邊角角的小問題，而是這個產品核心功能的最後一環。
這個產品的賣點，就在於免費得到應用，在於可以兌換付費應用。而這個步驟，就好像足球場最後的臨門一腳，這裡的體驗不佳，真不能算是小問題，因為這裡影響到了用戶後續使用這個產品的驅動力。
b.這個問題三天前我單獨與產品經理溝通過，當時意見未統一，於是決定會議上決定。那麼在會議上我再次提出這個問題，是希望這個問題得到解決。希望產品經理同學理解。
2.退一步說，這個問題從產品定義者的角度來看，可能是小問題。但對於用戶體驗來說，就不是小問題。這種局面，可能會發生在很多場合，比如產品和技術溝通時，UE和UI溝通時，等等。
這個時候我建議的一個法則是：當發生爭議時，認為一個問題次要的部門，讓步於認為這個問題重要的部門。
原因也好理解，術業有專攻，不同領域應該相互尊重。我這裡就不贅述了。

二、關於UE部門

鑒於大家對UE的工作的認識程度不同，我自己的理解里，淺談一下UE是什麼，做什麼，以及怎樣和PM等部門配合。由於水平有限，不妥之處請多指教。

1.UE（User experience）是什麼
用戶體驗，就是用戶在使用產品時候的切實感受。強調用戶體驗，簡單的說，就是以用戶為中心的設計。
這一概念已經在互聯網業內廣為認可，特別是針對大眾的產品，用戶已經養成了越來越挑剔的習慣，因為大多數產品都是可替代的，只要他們感覺不爽，立即會叛離到競爭對手那裡去。

在一般的用戶體驗概念里，我想強調一點，那就是沒有愚蠢的用戶，只有愚蠢的產品。
我們經常會想當然的以為一些小白問題不會被用戶遇到，因為這些問題太愚蠢了。但大多數用戶其實就是小白，他們沒心思去琢磨遇到的問題該怎樣克服，或者提出改善以及，而只是容忍。當他們感覺不值得容忍時，就會流失。那我們該怎麼做？莫以善小而不為，莫以惡小而為之。

2.UE與誰有關
重視用戶體驗，其實是產品隊伍里所有人都要有的思維方式和習慣，而不僅僅是交互設計師。
其實用戶體驗早已經滲透我們的工作之中了，產品經理、前端工程師、UI設計師、測試，這些部門都經常會和用戶體驗打交道，甚至後台的S同學，也會自主的考慮到用戶期望看到的數據是按什麼演算法排序這樣的問題。UE部門只不過更專註於此，在公司里優先站在用戶角度考察問題。（在沒有UE部門的時候，產品經理肩負此任，從用戶著眼思考）

3.一般的流程
規範流程的目的是而是為了減少失誤，控制產品的質量。先說一下通常講到的UE的五個層面（《用戶體驗的要素》），以及這些層面通常有誰來負責。

　　表現層：視覺設計——UI部門
　　框架層：交互設計——交互設計師(UE部門)
　　結構層：信息架構——信息架構師(UE部門)
　　範圍層：產品需求——產品部門
　　戰略層：市場需求——市場部門

通常的產品設計流程，自下而上對應這五個層面。
也就是說，先有市場需求分析、用戶研究，然後是產品部門負責功能定義，提交PRD，然後由UE完成交互設計原型，然後交付UI和開發部門。

具體到我們的工作，我們不必完全按照這個流程來走，因為很多角色我們暫時是沒有的，可能以後也不會有，我們不能套用其他公司的流程，而該自己摸索一套流程。

4.UE不是產品經理的敵人
用戶體驗部門，不對產品經理負責，而是對產品負責，目的是協助產品經理一起改進和完善產品。
但因為很多方面會有職責交叉，意見的不合與摩擦，在任何一個公司都是難免的。而僅靠流程和制度去規範，是不能解決所有問題的。因為大家的工作範圍難免有穿插，憑藉制度和流程來嚴格區分職責和許可權，往往是低效的。我認為比流程更重要的是方法，態度，以致公司文化。我非常強烈的倡議大家共同相互影響，培養一種開放、兼容並蓄的討論文化，能互相補充、互相進步，這是我個人的期待。
當然我也明白項目進度、效率等方面的因素。
其實最後歸結一個詞——妥協。
（也許人人都想成為喬布斯一樣的獨裁者，可是有幾人有他的鑒賞力判斷力？況且連喬布斯也說了另外一句：）

附上另兩個進一步的方案稿

---------------------------------------------------------

一些參考：
UE是什麼樣的一個部門UE是什麼樣的一個部門
UED應該向產品負責，而不是向PM負責。UED應該向產品負責，而不是向PM負責。
如何使用App Store兌換碼
如何使用App Store兌換碼（ Redeem Code ）？

好扯淡的一堆回答。
xx方法，xx需求，xx調研，xx目標。你們最後看看結果是什麼？？

誰背kpi，誰對結果買單，誰說了算。

簡單粗暴有效。

基本上還是目標（或理念）及優先順序的原因，兩種方式：

畫出所有可能性的交互方式（產品方式），一一討論優劣。
原型測試，測試完了再改。

如果是定位問題，老闆說了算
如果是功能問題，產品經理說了算

如果是交互問題，交互設計師說了算
如果是視覺問題，美術設計師說了算

每個職位都有每個職位的工作範圍，下級不能越上級的權，上級同樣不能越下級的權，還有同級之間也不能越權。

產品經理為產品負責所以一切就都得產品經理說了算？如果按這邏輯，老闆對公司負責，所以一切終究是老闆說了算咯？再追溯一下，老闆也不過是給大股東打工的，那最後是不是要去問董事長啊？

拜託，職業點好不好，老闆做定位、產品經理確定功能範圍、產品設計師模擬產品形態、產品工程師決定內部邏輯、交互和前端決定交互方式、美術設計師做視覺包裝…無論一個公司的崗位設置得是多是少，環節就是這些，每個人管好自己那一塊，不該自己管的別自作聰明。你就說「這個按鈕要突出」就得了，用紅色還是用黃色少插嘴了，你那麼能耐你怎麼不用PS做圖啊，你真覺得自己比別人都強嗎？

記得白鴉曾經寫過一篇博客：UED應該向產品負責，而不是向PM負責，寫的非常好！地址在這裡：http://ucdchina.com/blog/?p=1

各抒己見，據理力爭，並且，讓專業的人做決定。
大概就是 we give chocies and u make the decision。

從有爭議的方案的核心訴求點，解決的核心問題，效率影響，有爭議點功能的優先順序等多方面進行博弈吧，最終拿解決方案。不贊同某個人拍板，畢竟每個人都有各自的專業視角以及自己的專業盲區。

回答里一堆扯談的。尤其那個貼郵件內容出來說明一個按鈕對錯的那位。

我的觀點是必須是產品經理決定的。毫無疑問。
原因有下：
只有產品經理才掌握這個項目、這個業務最多最全的信息，在整個項目中只有產品經理才具備最全面權衡利弊輕重緩急的判斷分析力。換一句話說，產品經理由於角色的特殊，只有他才最具備全局思考的能力。
這所謂的全局是指產品經理確切知道產品必須在那個時間點上線去服務業務目標、產品經理有全盤的產品迭代規劃、產品經理知道每個版本里最重要要完成什麼事情。
絕對不可以是誰專業誰決定。
必須且只能是專業的人給產品經理給出最專業意見，由產品經理思考後做出判斷和決定。
這要求產品經理必須足夠優秀，能根據交互設計師給出的專業意見做出正確的判斷。
但即使產品經理不聽交互設計師的建議，做出了錯誤的決定，怎麼辦？
作為有水平的產品老大會給空間這個產品經理去試錯，錯多了，就換一個能做出正確判斷的優秀產品經理來做。但無論產品經理水平如何，決定權還是產品的。

也不是沒遇到過這種情況，我的看法是：

這個情況也比較普遍，為什麼會說到產品經理和交互設計師，因為在很多公司裡邊，產品經理和交互設計師他們的職位劃分沒有那麼的明確，一定程度上是有一定的模糊界限的，比如說有些公司產品經理會做線框和圖，而有些公司這些事情是交互設計師去乾的。

那麼，當兩個人同時都干，或者都不幹，或者都是一個人做了之後另一個人指指點點的時候，這就是意見不同的時候，那麼在這個時候，提倡的應該是文明溝通，抵制胡撕。

這個其實最根本還是看你們溝通上是不是出了問題，大家還是先講道理，根據事實去講道理，就是說你有沒有用戶調研，是不是符合設計原則，是不是達到我們的目的，從這個環節理性判斷，雙方好好溝通一下。如果這樣還沒解決，可以去找上級協調，因為上級的戰略眼光比較高一些，更全面一些，這個時候他們可以去做決策。

我自己遇到過這種情況，但是我遇到的還比較講道理，我會先聽聽他的看法，聽完之後如果真的是我沒有想周到，我勇於承認，如果說他確實說的沒有道理還死不承認，那我就堅持自己，因為堅持自己不是說死磕或者犟，因為你做出的設計就是你的作品，你以後是要對它負責的。如果最後實在不行，就找到主管或leader來協商解決。

謝謝！希望能夠幫到你，有興趣的小夥伴也可以加我威信好友，一起學習交流哦！

誰專業聽誰的？

這是扯淡，當你做一個創新產品的時候，誰比誰專業？

我贊了「誰背KPI聽誰的」那個答案，因為這個答案是最接近正確答案的答案。

如果需要一個完美答案，應該是：
誰明白這產品是什麼，誰做決定。

事實上，多數人根本不知道自己做的產品是什麼，這些人可能包括產品經理、各種設計師、各種工程師。你讓那些不知道產品是什麼的人決定產品設計？

有的時候，整個團隊都不知道自己在做什麼。

有的時候，做產品就是在追問「這個產品是什麼」的過程。

當然，現實中，為了做好產品，一切決策都該聽產品經理的。

為了公司生存，就該聽CEO的。

一個前提，無論哪個角色製作、參與設計，乃至他擁有某些職權。
都必須是用戶，重度用戶。
必須投入很多的思考和理解進去.....

否則，沒有任何一個設計，是好的。

如果你說我是錯的，那你最好證明你是對的。
每個爭議說出理由，能說服別人不？做自己專業的事，聽別人的建議，做自己的決定。如遇KPI的，誰背誰老大，這種情況下離垃圾產品不遠了。

產品和交互都應該服從產品需求層面，
有分歧：
1、看分歧點在哪裡
2、把每個人的觀點列出來，看誰的更加接近產品需求
3、不要主觀判斷，以客觀的實際情況對比
4、以上還不能斷定，那麼把上面的情況拿給帶三方看，請第三方給一個判斷
這種事最好不要一個人說了算，產品的成功不是由一個人來決定的，所以問題也不能由一個人說了算，團隊最好可以站在客觀的角度分析問題，這樣才是解決問題的根本。

如果是顯著的不同，肯定是有一方錯了，要麼兩方都錯了。

如果沒有顯著的不同，那就誰大誰說了算。

很多時候，快速解決問題、上線、再修改比磨嘴皮子重要。

最好的辦法是：誰對結果負責，誰拍板。