产品经理和设计师之间最常见也是最尖锐的矛盾就是，设计师把花了很多心血做出来的稿子放到产品经理面前，产品看了一下，觉得非常陌生和超出预期，说：“这都是些什么啊”。

(- -#)，(- -’)，此处无声胜有声。倒不是说这里面谁对谁错，都挺辛苦的其实，但为什么总会落得如此尴尬呢。

世上配合最好的其实就是自己的手配合自己的脑袋。脑袋怎么想，手就怎么画，画出来的丁老头再丑也觉得很亲切，恩恩，是我的好作品（星星眼）。只是等到两个人合作的时候，就有些麻烦了。因为，让“设计师的手”精致地受控于“产品经理的脑袋”，每次画完看一看，觉得对就继续画、错就改的敏捷调控是不现实的。

祸起，在于一些沟通中有很多弊端，唯有解决这些问题，才能让团队和谐地高唱“同一个梦想”。

一、产品没有意识到要讲的其实是故事

常见的产品经理提需求的方式往往都是在需求文档里直接写“在Feed上增加一个转载按钮，点击后可以填写转载理由”。这种描述方式其实已经是一个很具象的解决方案了。然后这份包含数十条如此描述需求的文档会被贴到内部需求管理网站上，或者通过邮件发给设计师。

设计师拿到这份文档，通常会觉得很憋屈。哎，忍忍算了，拿人钱财替人消灾。然后拿着这份需求文档在现有界面上去改。但往往会发现产品说这些具体解决方案其实在实现时是有很多细节冲突的。于是，设计师要先逆向YY出这个功能背后的用户需求，然后再尝试在与各种细节不冲突的夹缝中找一个新的解决方案。把这个稿子拿给产品看，产品就会楞一下，说“这是什么…”。(- -#)，(- -’)

其实很多产品经理没弄清自己最大的价值点。作为产品经理最该做的是发现生活中用户各种不知道该怎么满足的需求，然后把这些很有挑战也很有价值的用户需求委托给资源方来帮忙想办法解决。这个需求应该以尽量生活化的、讲故事的方式来表达，与任何具体的解决方案无关。这样设计师可以很明确地知道要解决什么问题，设计也就有了出发点，而且是产品经理给的出发点。所以在这一环上，产品经理交付的接力棒是一个好的故事，传情地描述用户的困难即可。

一个故事最核心的内容应该包括: <什么样的人><在什么样的情况下><想要满足何种需求><他/她会尝试某种方式（或找不到任何解决方式）><但所需要的成本是*****><我们来解救他/她吧>。