如果我说这个设计不好看，设计师会不会生气？
01
设计师，也是产品经理需要经常打交道的对象。
一谈到“产品经理”，大家很容易就会联想到产品经理的老朋友——“程序员”。
而“设计师”，却比较少被提及。
我在做需求时，至少碰到过3个业务同事，以为产品经理画完原型之后，就可以交付给技术部门开发了。
当我表示还需要设计师设计时，他们会一脸迷惑地指着我的原型，说：“你不是已经设计完了吗？”
如果说产品经理与程序员是“对抗与协作”的关系，那与设计师的关系，就要暧昧得多了。
设计师进行设计时，并不是简单按照产品经理的原型来就行了。
尤其是交互设计师，需要对“产品交互”负一部分责任。
所以，有时候设计师会就某个交互设计，与产品经理进行battle。
人人皆可怼产品经理，设计师也不例外。
甚至有一些公司，没有“产品经理”，直接让设计师来画原型，代行“产品”之事。
“设计师”，我们谈论得少，并不意味着他们不重要，也不意味着他们好相处。
某种意义上讲，设计师比程序员更不好打交道。
产品经理与程序员之间沟通的障碍，某种程度上讲，是因为“语言不通”。
但是，“技术语言”是讲逻辑的。
只要把逻辑说清楚，双方是可能达成共识的。
但是，“美”是不讲逻辑的。
我就是觉得不好看，你就是觉得好看，双方谁也说服不了谁。
产品经理与设计师之间出现分歧，要怎么处理？
今天就来简单聊一聊这个话题。
02
要谈“产品经理”与“设计师”，我们需要先把两者的工作职责给拎清楚。
以前流行过这么一种说法：“产品是产品经理的孩子。”
这仿佛是在说，“产品”是产品经理个人的东西。而团队的其他角色，则是在为“产品经理的产品”服务。
现在，这种说法已经没什么人提了。
但是，从一些同行朋友的言语中，我们还是能明显感受到这么一种“自豪感”。
甚至产品经理之外的不少人，至今也是这么认为的。
“只要是产品的事情，就是产品经理的事情。”
“产品经理需要为产品负起无限的责任。”
这样的误解，我认为，一定程度上，是“产品经理”这个称谓导致的。
“产品经理”这个词，完全不能反映这个岗位实际的工作职责，极具迷惑性。
以至于，至今我父母都弄不清楚我到底是在干什么。
要我说，叫做“画图仔”、“传话员”，就挺好的。
稍微想想，就能明白，“产品”肯定是公司的，或者说是老板的。
团队中的各个角色，包括产品经理，可以说，都是在为“公司的产品”服务。
每个角色，都有自己负责的模块，各司其职。
只不过，如果其他角色出问题了，产品经理需要连带着负一部分责任。
所以，产品经理能够对其他角色进行一定程度的“管理”。
这是“产品经理”这个角色的一点点特殊性。
但也仅此而已。
不能因此就认为，其他角色都是对产品经理负责的。
具体到“产品经理”与“设计师”。
产品经理的工作，基本是围绕着“需求”进行的。
而设计师，可以简单地理解为，是对产品的“视觉效果”负责的。
双方互相协作，工作职责有所重合，但本质上还是在各干各的活。
有些同行朋友可能碰到过这样的情况。
设计效果出来了。一看，没有达到预期，去找设计师反馈。结果设计师突然就火了。
这很可能就是因为没有弄清双方的职责范围。
有人越界了，外行想要教内行做人。
03
产品经理的工作，始终是围绕着“需求”进行的。
无论是在和什么角色进行对接，都要始终牢记这一点。
那么，产品经理在与设计师对接时，具体是要做什么呢？
我觉得，产品经理的职责，主要有以下几点。
1. 准确地传达设计需求
产品经理需要清楚地告知设计师，需要设计什么，每个模块每个细节具体有什么要求。
原型图，就是用于传达设计需求的有效手段。
为了提高沟通效率，产品经理要尽量将各种细节要求在原型图上表现出来。
比如说，做资讯列表页时，我习惯画3个资讯卡片：
- 标题字数很少，1行都显示不全的情况。
- 标题字数较多，需要2行显示的情况。
- 标题字数非常多，只能显示2行，超出的用“…”截断的情况。
这样，设计师一看原型图，就很清楚，我对资讯标题有什么设计要求。
当然，原型图只是传达需求的手段之一。
直接面对面的沟通说明，无论如何是省不了的。
尤其是关于“设计风格”的要求，只有当面沟通，才有可能说清楚。
2. 确保设计效果充分满足需求
并不是说，大家各干各的活，产品经理完全不能对设计效果指手画脚。
产品经理是需要对“需求”负责的。
所以，产品经理在验收设计效果时，首先需要关注的是，这个设计能否充分满足需求。
比如说，总共需要3种弹窗，结果只设计了2种效果。
比如说，某个数值业务上存在5位数字的情况，但预留的空间最多只能放下4位数字。
比如说，领导想要的是偏营销的风格，可设计出来的是简约小清新的风格。
有时候，设计师也可能拎不清这个界限。
他们有时会忽视具体的需求背景，仅从设计美感的角度，去与产品经理争辩。
这个时候，产品经理得清楚自己的职责。
“设计”要服务于“业务”，而不是反过来。
不能因为设计师有情绪，产品经理就在不该妥协的地方妥协。
3. 做好“设计”与“业务”沟通的桥梁
设计效果好不好，并不是完全由设计师说了算。
从完成设计初稿，到产品上线运营，领导或者相关业务部门，随时都可能提出各种修改意见。
这些意见，首先会汇总到产品经理这里。
产品经理不能直接就把这些意见“转述”给设计师，让设计师自己“看着办”。
我们需要对这些意见进行管理。
去掉大部分不合理、不重要的意见。
对需要处理的意见，进行优先级分类。
沟通清楚具体哪里有问题，需要怎么修改。最好能要到参考案例。
当产品经理把这些意见反馈给设计师时，要确保，要求清晰具体，可执行，可验收。
而不能是“领导说这里不好看，你再改改”。这样会让人摸不着头脑。
反过来，有时候设计师也需要与相关干系人进行沟通。
比如说，banner里面文案太多，设计起来效果不好。
这时候，一般建议设计师与相关业务同事直接沟通。
由产品经理来中转，效率很低，而且容易出错。
当然，如果有需要，产品经理有责任从中进行协助。
极端一点讲，产品经理只需要做好上面这3点工作，就行了。
至于设计出来的是蒙娜丽莎，还是海绵宝宝，产品经理都无需理会。
只要需求方没意见就行。
04
当然，在一个正常的团队中，产品经理还是经常需要与设计师沟通设计效果的。
在与设计师进行沟通时，需要注意以下几点。
1. 不要教设计师设计
产品经理在向设计师反馈意见的时候，要清楚自己的角色。
这个时候，我们只是作为一个普通用户，提出自己个人的、非专业的看法。
这些“普通人”的意见，只是作为设计师决策时候的参考。
它不可能比设计师的见解更“专业”，也不是“命令”。
接不接纳，需要设计师进行专业的判断。
让专业的人做专业的事情，不要想着去教设计师设计。
2. 产品经理的每一个设计，都要有理由
产品经理的每一个决策、每一个设计，都要有理由。
这个理由，并不需要逻辑严密，甚至不需要”合理“。
“原来的样式用了好久了，这次我想换一种试试”，这也是一个理由。
我们需要清楚自己在进行决策时，所依据的理由，并且能够清楚地表达出来。
举个例子。
“因为文案比较多，所以我觉得用底部弹窗的形式，更方便阅读。”
那么，交互设计师如果想要改成居中弹窗，就有了“攻击的靶”。
- “文案其实不多，居中弹窗也放得下”。
- “居中弹窗内部滑动，阅读起来也挺方便的”。
- “底部弹窗反而不适合长文本的阅读”。
- 等等。
只有这样，产品经理和设计师才能进行有效的讨论。
如果产品经理只是说，“我就是觉得底部弹窗好些”，那就没法讨论了。
3. 设计看起来“怪异”，可能只是还没流行起来
工作中，我碰到过好几次这样的情况。
设计师给过来的设计，比较“怪异”。我没见过这样的设计，也觉得不是很好看。
接下来没多久，我就发现，其他产品也都陆陆续续采用了这样的设计。
这种设计开始流行起来了。
设计风格，每年都在变。
设计师，因为是职责所在，所以会关注业内设计风格的变迁，并不断调整自己的设计。
产品经理当然也会关注这些信息，但是多少会比设计师滞后些。
因此，当设计师做出一些新设计时，产品经理不要因为没见过，就给否定了。
有可能，只是产品经理“孤陋寡闻”了而已。
4. 如果设计师不愿意沟通，那也无需勉强
我相信，大部分设计师，都是乐于与他人交流、乐于听取他人反馈的。
但是，如果设计师对自己的设计非常“自豪”，听不得他人的半点意见，那么产品经理也无需勉强。
就像上面说的，产品经理只需要做好自己负责的工作，就好了。
作者：简明产品论，个人公众号：简明产品论（ID：JianMingPM）
本文作者 @简明产品论
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
