产品经理和设计师之间最常见也是最尖锐的矛盾就是，设计师把花了很多心血做出来的稿子放到产品经理面前，产品看了一下，觉得非常陌生和超出预期，说：“这都是些什么啊”。处无声胜有声。倒不是说这里面谁对谁错，都挺辛苦的其实，但为什么总会落得如此尴尬呢？
世上配合最好的其实就是自己的手配合自己的脑袋。脑袋怎么想，手就怎么画，画出来的丁老头再丑也觉得很亲切，恩恩，是我的好作品（星星眼）。只是等到两个人合作的时候，就有些麻烦了。因为，让“设计师的手”精致地受控于“产品经理的脑袋”，每次画完看一看，觉得对就继续画、错就改的敏捷调控是不现实的。
祸起，在于一些沟通中有很多弊端，唯有解决这些问题，才能让团队和谐地高唱“同一个梦想”。
一、产品没有意识到要讲的其实是故事
常见的产品经理提需求的方式往往都是在需求文档里直接写“在Feed上增加一个转载按钮，点击后可以填写转载理由”。这种描述方式其实已经是一个很具象的解决方案了。然后这份包含数十条如此描述需求的文档会被贴到内部需求管理网站上，或者通过邮件发给设计师。
设计师拿到这份文档，通常会觉得很憋屈。哎，忍忍算了，拿人钱财替人消灾。然后拿着这份需求文档在现有界面上去改。但往往会发现产品说这些具体解决方案其实在实时时是有很多细节冲突的。于是，设计师要先逆向YY出这个功能背后的用户需求，然后再尝试在与各种细节不冲突的夹缝中找一个新的解决方案。把这个稿子拿给产品看，产品就会楞一下，说“这是什么…”
其实很多产品经理没弄清自己最大的价值点。作为产品经理最该做的是发现生活中用户各种不知道该怎么满足的需求，然后把这些很有挑战也很有价值的用户需求委托给资源方来帮忙想办法解决。这个需求应该以尽量生活化的、讲故事的方式来表达，与任何具体的解决方案无关。这样设计师可以很明确地知道要解决什么问题，设计也就有了出发点，而且是产品经理给的出发点。所以在这一环上，产品经理交付的接力棒是一个好的故事，传情地描述用户的困难即可。
一个故事最核心的内容应该包括: <什么样的人><在什么样的情况下><想要满足何种需求><他/她会尝试某种方式（或找不到任何解决方式）><但所需要的成本是*****><我们来解救他/她吧>。
二、文字不是讲故事的最好方法
大家都听过“下班顺路买一斤包子带回来，如果看到卖西瓜的，就买一个”的笑话吧。产品用文字去表达自己的想法时，有很多信息是会失真的。设计师接收到这些文字，再去逆向理念产品的想法，想象出的就是另一个故事了。
《餐巾纸的背面》以及《Frog Collective Action Toolkit》都提供了表现力更强的讲故事方式。诸如草稿、漫画、视频，都是可以用来表现用户需求场景的，比文字更加高效，引发误解的概率也低。
我们常会说这段文字的画面感很强，但我想并不是所有的产品经理都能写出这样的文字，所以，为什么不直接用画面来讲故事呢：）具体我就不写了，两本书里都有，妥妥的。
三、设计师没有及早确认自己的理解
设计师从产品经理那里领了圣旨，但其实还有一个风险点，就是以为自己理解了产品大人的旨意，但其实不尽然。最好的方法是设计师能够立刻用于语言或者更加可视化的方式，将自己的理解复述一遍给产品经理。否则，你真的会在碰见卖西瓜的以后，买回一个包子来。
设计师最擅长的东西就是把抽象的东西具象化。既然有如此神技，其实也可以在领完旨后，不要急着立刻奔回座位开画，而是先当面随手画一些非常简易的示意图。在这些示意图上，你可以演示一下在未来，用户将会怎么解决他们的需求。产品立刻就能明白，你够不够懂他。要想别闭着眼在错误的道路上越走越远，最好的方法是尽早睁开眼，确认好大方向。
四、设计没有发散出多种设计
产品经理说学逗唱都用上了，讲了一个好故事，给接下来的设计定了一个精准的起点。下面就该设计师露脸了。
对于一个用户痛点，提供怎样的解决方案最有效，其实是非常迷茫的（指着竞争对手的产品界面说“我就想要个这样的页面”的产品经理咱们就不说了）。这就非常需要设计师能够发散思维，向多个可能的方向试探触角，努力探求各种有希望的方法。这样，产生创新的突破性方案的可能也会大一些。
产品经理其实背负了非常大的压力，他们要赌上自己的事业前途来向投资者要到人力（嗯，就是设计师、工程师们）物力来实现一个未知的梦想。设计师要是能码出一排各式解决方案给产品经理说您随便挑，看哪个“最”好，无疑是能帮助产品经理提升极大信心的（星星眼）。
愿此文可以帮助产品经理和设计师这对死冤家的争吵少一些，我们本是吉祥如意的一家。
