在给设计师提意见的时候，我们应该需要注意哪些细节和说话方式呢？
自己手头的设计做久了，容易陷入细节而难以发现一些问题。所以设计师通常会找别人来帮忙看看设计稿，换个角度也换个思维。
一般有三种途径来主动获取意见反馈：
找设计同事过稿——他们可以从专业角度帮忙查找问题或优化点；
参加设计评审——同一团队中不同岗位的同事齐聚一堂来指点江山；
找测试用户体验——找和产研无关的人来感受体验并给出反馈。
今天我们跳出设计师的身份，站在他们的对面来谈谈如何更好地给他们提出建议和反馈。
设计不像开发，是一个很多人都能或多或少说上一嘴的专业。随便找一个人给他看某个设计，他都能多少提出点个人看法。这就使得有些人会觉得自己设计看多了，也很懂设计，然后在提设计意见的时候，容易一顿炮轰。但因为缺少专业锻炼，又不注意说话方式，容易变成对设计的批评批判，甚至有时候变成了人身攻击，这只能让设计师抵触和反感。
批评更多是找问题，而提建议则是帮助解决问题。我们当然没有义务帮其他设计师去解决问题，但起码可以做到不要言辞过于凌冽，更不应该夹杂着笼统的主观感受，比如“这也太丑了！”、“这也能叫设计？！” 这个时候设计师可能分分钟想把你做成表情包。
我们作为设计师时，找同事帮忙看设计图给意见，不是为了你好我好大家好，是希望有专业领域的同事从不同的角度或者是自己没考虑到的角度给一些意见，能把这个设计做得更好。
作为提出意见的人，如果有好的看法，提出来的话说不定能很大程度帮设计师做优化或避免返工。不要因为害怕影响同事关系，总是给一个含糊的“老好人”意见。
总是提这种“好听但没什么用”的意见，会让设计师觉得你专业能力不行，或者不是真心想帮忙，反而不利于同事关系。
设计师找我们提意见和反馈，是为了把设计做好。我们（尤其是设计leader）提出意见反馈也是为了他们能听进去。
合适的说话方式和语气就像润滑剂，能让设计师更容易接受说话内容。很多时候，影响人与人沟通效率和结果的，不是内容而是语气。我以前在给组里设计师过稿时通常会说“我个人觉得……可能会好一点”或者“你要不要考虑把……改一下看看”，效果还不错，各位可以试试。
有时候一些意见和看法，点到为止就好。设计师自己手里出来的设计稿他们肯定很熟悉，也有过思考。一些地方我们稍微一提，他们立马就懂了，一般会恍然大悟附和一句“哦对对对！”。这个时候没必要再长篇大论做观点输出了，他听明白了，就可以打住了。
尤其是对于设计评审，其目的是为了让设计方案更好，产品体验更佳。设计师把设计稿拿到评审会上是在说“这是我为公司/团队做的设计稿，大家一起来看看怎么能让它更好，给公司/团队创造收益”，而不是“这是在下的拙作，大家来喷我吧”。
那我们作为评审设计的人，说是“评审”，其实就是一起使劲儿，从各个岗位的专业角度来让设计变得更好，而不是七嘴八舌炮轰设计师——这不就是多岗位设计评审的意义吗？
甚至有时候，设计师带着一个不是很成熟的方案参加评审，我觉得也没必要指责。可能这个方案里是有一些可取之处的，放在别的方案里能变成一个更好的方案，这也未尝不可。
推荐一个提反馈的方法：
在一篇文章Constructive Feedback for Designers中，看到了一个提反馈的方法，可以借鉴一下。这个方法叫SBI，即Situation-Behavior-Impact，我自己又补了一个T(Thought)其中：
S(Situation)——描述当前的背景情况
B(Behavior)——只描述你所观察到的行为，不要猜测继而指责别人怎么想的
I(Impact)——说明这样做的影响是什么
T(Thought)——询问对方的看法，也可能对方有他坚持的道理
例子1：（S）我们的设计规范里没有这个控件，别的产品里也非常少见（B）你在这个不太重要而且操作频次低的功能里加了这个新的控件（I）这可能会导致我们的设计控件不统一，而且要维护新的控件，也增加了开发成本（T）你觉得呢？还是你觉得这个控件加了确实是可行的呢？
例子2：（S）我们整个产品色调都是偏于明亮清新的（B）这里这个颜色可能暗了一些（I）用这个颜色可能会让用户对这个界面的第一视觉感受不太舒适（T）你要不要考虑调整一下？
找问题容易，提建议很难。
也愿大家在职场上越走越坚强！
本文由 @Vicol 原创发布于人人都是产品经理
节点互动（广东）科技有限公司一家专注于 APP开发 + 小程序开发 + 微信开发 + 系统开发 + 网站开发 的专业互联网应用服务提供商。5年实战开发经验，高校合作基地，多年行业深耕经验，助力传统行业快速转型，为众多企业提供创新性互联网应用产品。
