產品經理和設計師之間最常見也是最尖銳的矛盾就是，設計師把花了很多心血做出來的稿子放到產品經理面前，產品看了一下，覺得非常陌生和超出預期，說：“這都是些什麼啊”。
(- -#)，(- -’)，此處無聲勝有聲。倒不是說這裏面誰對誰錯，都挺辛苦的其實，但爲什麼總會落得如此尷尬呢。
世上配合最好的其實就是自己的手配合自己的腦袋。腦袋怎麼想，手就怎麼畫，畫出來的丁老頭再醜也覺得很親切，恩恩，是我的好作品（星星眼）。只是等到兩個人合作的時候，就有些麻煩了。因爲，讓“設計師的手”精緻地受控於“產品經理的腦袋”，每次畫完看一看，覺得對就繼續畫、錯就改的敏捷調控是不現實的。
禍起，在於一些溝通中有很多弊端，唯有解決這些問題，才能讓團隊和諧地高唱“同一個夢想”。
一、產品沒有意識到要講的其實是故事
常見的產品經理提需求的方式往往都是在需求文檔裏直接寫“在Feed上增加一個轉載按鈕，點擊後可以填寫轉載理由”。這種描述方式其實已經是一個很具象的解決方案了。然後這份包含數十條如此描述需求的文檔會被貼到內部需求管理網站上，或者通過郵件發給設計師。
設計師拿到這份文檔，通常會覺得很憋屈。哎，忍忍算了，拿人錢財替人消災。然後拿着這份需求文檔在現有界面上去改。但往往會發現產品說這些具體解決方案其實在實現時是有很多細節衝突的。於是，設計師要先逆向YY出這個功能背後的用戶需求，然後再嘗試在與各種細節不衝突的夾縫中找一個新的解決方案。把這個稿子拿給產品看，產品就會楞一下，說“這是什麼…”。(- -#)，(- -’)
其實很多產品經理沒弄清自己最大的價值點。作爲產品經理最該做的是發現生活中用戶各種不知道該怎麼滿足的需求，然後把這些很有挑戰也很有價值的用戶需求委託給資源方來幫忙想辦法解決。這個需求應該以儘量生活化的、講故事的方式來表達，與任何具體的解決方案無關。這樣設計師可以很明確地知道要解決什麼問題，設計也就有了出發點，而且是產品經理給的出發點。所以在這一環上，產品經理交付的接力棒是一個好的故事，傳情地描述用戶的困難即可。
一個故事最核心的內容應該包括: <什麼樣的人><在什麼樣的情況下><想要滿足何種需求><他/她會嘗試某種方式（或找不到任何解決方式）><但所需要的成本是*****><我們來解救他/她吧>。
二、文字不是講故事的最好方法
大家都聽過“下班順路買一斤包子帶回來，如果看到賣西瓜的，就買一個”的笑話吧。產品用文字去表達自己的想法時，有很多信息是會失真的。設計師接收到這些文字，再去逆向理念產品的想法，想象出的就是另一個故事了。
《餐巾紙的背面》以及《Frog Collective Action Toolkit》都提供了表現力更強的講故事方式。諸如草稿、漫畫、視頻，都是可以用來表現用戶需求場景的，比文字更加高效，引發誤解的概率也低。
我們常會說這段文字的畫面感很強，但我想並不是所有的產品經理都能寫出這樣的文字，所以，爲什麼不直接用畫面來講故事呢：）具體我就不寫了，兩本書裏都有，妥妥的。
三、設計師沒有及早確認自己的理解
設計師從產品經理那裏領了聖旨，但其實還有一個風險點，就是以爲自己理解了產品大人的旨意，但其實不盡然。最好的方法是設計師能夠立刻用於語言或者更加可視化的方式，將自己的理解複述一遍給產品經理。否則，你真的會在碰見賣西瓜的以後，買回一個包子來。
設計師最擅長的東西就是把抽象的東西具象化。既然有如此神技，其實也可以在領完旨後，不要急着立刻奔回座位開畫，而是先當面隨手畫一些非常簡易的示意圖。在這些示意圖上，你可以演示一下在未來，用戶將會怎麼解決他們的需求。產品立刻就能明白，你夠不夠懂他。要想別閉着眼在錯誤的道路上越走越遠，最好的方法是儘早睜開眼，確認好大方向。
四、設計沒有發散出多種設計
產品經理說學逗唱都用上了，講了一個好故事，給接下來的設計定了一個精準的起點。下面就該設計師露臉了。
對於一個用戶痛點，提供怎樣的解決方案最有效，其實是非常迷茫的（指着競爭對手的產品界面說“我就想要個這樣的頁面”的產品經理咱們就不說了）。這就非常需要設計師能夠發散思維，向多個可能的方向試探觸角，努力探求各種有希望的方法。這樣，產生創新的突破性方案的可能也會大一些。
產品經理其實揹負了非常大的壓力，他們要賭上自己的事業前途來向投資者要到人力（嗯，就是設計師、工程師們）物力來實現一個未知的夢想。設計師要是能碼出一排各式解決方案給產品經理說您隨便挑，看哪個“最”好，無疑是能幫助產品經理提升極大信心的（星星眼）。
願此文可以幫助產品經理和設計師這對死冤家的爭吵少一些，我們本是吉祥如意的一家。