老板说字体要大要红色，其实是想引人注意，进一步提高点击率和转化率。所以无论是设计师还是甲方 ，在提出/接到需求时都不应该简单粗暴地执行，反复沟通找出最本质的需求才能让彼此都满意。多说无用，直接来看@米_亓 在工作中的真实案例。
转到交互岗已经有一阵子了。原来在做产品的几个月里没少和技术、设计进行沟通，每当自己把意思想法传达下去的时候，反馈回来的结果基本都要进行进一步的修改，这种返工和修改在产品快速迭代的过程中很浪费时间。当时自己没有觉得表达有问题，已经把需求的目的结果都表达清楚了。可能是自己没写过代码、没做过设计所以在一些专业的术语的表达上，方案实现方式的选择上存在偏差，导致技术、设计没有完全按照自己设想的预期做出结果。
要是这么说，产品经理只要学习了解一些设计的基本原理并且能看懂简单的代码，是不是这种沟通就不会存在障碍了呢?当我在设计岗上工作了一阵子后发现自己不仅仅是在工作职能上进行了转变，更是一种团队中角色定位的转变。所以产品要将需求的预期结果交代给设计的时候并不是懂设计(不要对比这么强烈;颜色太跳跃等等)就能把结果表达的很清楚，更多的是站在设计的角度将原始的需求转化后传达给设计。
下面我举一个这周工作中的小案例。
一天我接到了产品提的一个需求，“我们后台新加入了一个功能，能不能给我设计几个好看的图标。我自己做了几个方案总觉得不好看，你给我设计一下吧。毕竟后台我们自己用不面向用户，不用太精细，谢谢啦!”然后随手甩给我一张图。
▲ 产品经理给我的示意
打开看到这个demo后并没有一下将焦点集中在想要修改的icon上，而是把自己当做是用户思考地图上面这几个东西我能用它们来干些什么。可能是从产品转过来的缘故吧，并没有像其他设计师一样只把产品给我的需求做好就行，我必须要明白我这么做能给用户带来什么功能和方便。所以我思考片刻后，找到产品接连问了以下几个问题“地图上的字和icon是可点击的按钮还是提示?它们分别能实现什么样的功能?用户能得到怎样的方便?”
“是可以点击的按钮，可以让用户实现手动标记位置和自动定位间切换，定位之后可以保存”，这时我大概理解产品想要什么了，是一种功能的切换和对于结果的保存。那完全可以不用Button的形式去展现，用Tab会更好，不但能实现功能的切换并且能让用户知道当前选择的功能。至于保存结果下方已经有“保存”的button了，所以没有必要在地图上再加保存功能。于是我输出了下面的图：
▲ 第一次修改结果
产品看过之后表示这不是她想要的结果，我只是想在自动定位定不准的情况下可以手动进行修改，打开页面时已经存在定位为了防止误操作是不能修改的，然后如果想修改定位可以选择“手动标记”。这中间还有其他沟通的环节，然后我输出了下图：
▲ 第二次修改结果
产品不要求再改了，这一个小工作算是搞定了。
虽然是个很简单的工作但是中间付出了不少沟通成本，所以觉得有必要拿出来总结一下：从最初的“给我设计一个好看的icon”—>“可以在定位时手动自动切换”—>“用户可以修改自动定位不准确的位置”。其实最后还有一个最终的需求“我要后台定位准确”。前三个都是产品在这次任务中向我表达的需求，我在充分理解第三个需求后便可做出产品经理想要的结果。最后的那个需求是这个产品的最终需求，但作为设计师充分理解第三个足矣。
▲ 我在充分理解第三个需求后便能做出产品经理想要的结果
再举一个例子，是来自百度设计总监史玉洁在一次演讲报告中提到的。老板提出来一个需求“我要设计师给我在这个页面下方加一个大的、红色的、醒目的按钮”。细细分析一下，把这个需求按照上面例子的格式写出来便是“我要一个大的、红色的、醒目的按钮”—>“用户可以有欲望去点击”—>“我只是想提高这个页面的转换率”。
▲ 告诉设计师，看到这个页面用户想要去点击这个按钮
第一个是表达层面的需求，即使产品再懂设计也只是可以提出一些意见，而不应该对设计层面的东西指手画脚。如果你说颜色不好看，形状太小这些设计层面的问题不如从用户角度说明这个问题更让设计师信服。最后一个是整个产品层面的需求，可以让设计师去参加产品需求会议去了解，在产品快速迭代中不必再重申产品层面的需求。第二个是站在设计师位置以用户角度提出的需求，也是设计师真正能理解的需求。所以给设计师提出的需求一定要用设计师的需求语言。
设计师尤其是交互设计师本身就是个定位很模糊的职位，因为在产品整个开发的过程中，各个环节都会影响到用户体验(这个词实在是太大了，工作越久越不敢轻易脱口而出)但是设计师是最能站在用户角度去考虑问题的岗位。产品需要为用户考虑体验问题，但是产品更需要去权衡整个框架，包括开发周期、实现方式、运营方式等。权衡各个问题的比重而不会完全将产品的重心放在用户体验上。工程师使用的开发技术也会影响到用户体验，但他们更多把重心侧重在产品的实现、逻辑、可修改性等等方面。所以在产品开发的各个环节设计师是把手用户大门的角色，他们的存在就是在团队中争取更多的资源为了用户。
这么说来就不难理解为什么在给设计师提需求的时候应该多站在用户角度，以设计师的角色去给他们提需求。
最后回到文章开始所说的，并不是了解设计和技术就能和他们进行无障碍的沟通。更多的是要理解各部门在开发中所扮演的角色、负责的首要任务。设计师们在得不到明确的需求时应该多去和提需求方沟通，引导需求方将随口提出的需求转化成属于自己角色的需求。往往了解产品业务的聪明的设计师会对别人提的需求有更好地理解，而不是片面的只听到了“需求”，会根据业务推导出属于自己角色层面的需求。让设计师参加产品需求会议就显得格外重要，而很多团队只是把设计师当做干活的美工，在不了解业务的情况下增加很多沟通成本。
▲ 聪明的设计师在了解业务后能推导出属于自己角色层面的需求
今天主要是以设计师的角度通过工作中的事情和自己平时所看所学思考的一些问题。团队中的交流沟通实在是一个大的话题，还会牵扯到很多其他因素，我会随着工作经验的积累慢慢再对沟通问题做进一步深入讨论。
