每一个产品都离不开需求。围绕需求我们可以看到一个协作的团队。产品经理提出需求，设计师将需求转化为设计，程序员根据设计实现需求。当这个协作链运转顺利时，我们便会看到一个高效的团队，同时收获一个快速迭代的产品。但很多时候这个协作链的运转并不顺畅，尤其是当需求出现问题的时候。

产品经理向设计师提出一个需求，要求设计师完成设计。在我接触过的多数企业中，这个环节的信息传递是单向的。产品经理表现得十分强势，设计师扮演的是支持性角色。因而，即使设计师认为产品经理提出的需求不合理，却也只能完成对不合理需求的设计支持。这样的状况会带来严重的信任问题，在产品经理和设计师之间的对话渠道会因此而关闭。当产品由于不当需求而出现负面影响的时候，设计师便会微微挑起嘴角，在心里默默说道：“我早知道会这样。”

要避免这种状况，便需要建立起关于需求的正确沟通机制。产品经理首先要将设计师看作自己的合作伙伴而不是助手，提出一个需求的时候除了要描述清楚这是个什么样的需求，更重要的是要描述清楚为什么这个需求是有价值的。表面上看这是产品经理向设计师解释自己的思路，而实际上这是确认产品经理确实对于自己提出的需求有明确的价值认识。

任何一个需求都是有价值的，只不过存在一个前提。那就是价值是对于特定用户而言的。今天的电脑操作系统尽管已经都是图形界面，但不论是Windows还是iOS都提供一个功能，那就是命令行窗口。很多用户甚至根本不知道这样一个窗口的存在。在这个窗口中，用户可以通过输入一串字符来完成系统的许多操作（例如dir指令可以列出当前目录下的文件名和子目录名）。对于普通用户来说，这个窗口是多余的。TA可以通过熟悉的图形界面完成同样的操作。但对于技术人员而言，命令行窗口就要比图形界面要有效率得多。而且有些高级功能在图形界面下并不提供，只能通过命令行窗口进行操作。对这些技术人员来说，命令行窗口就是非常有价值的。

正因如此，产品经理在向设计师提出某个需求的时候，必须说明这个需求是对哪个用户群体产生价值。这样才可以让设计师得以理解并藉由同理心而对需求产生有效的价值判断。只有避免公说公有理，婆说婆有理的不在一个频道之上的对话，关于需求的理解才能够迅速获得共识，产品经理与设计师之间的协作才能够建立在共识的基础之上。

用户不是简单的“用户”两个字，而需要是有血有肉可以视觉化的人。当需求与这样的人关联在一起的时候，需求就同样有血有肉。对于需求合理性的判断就容易多了。

来源：林敏UX