这一篇是给团队里的设计师培训的内容，能做到的人仍然不多。有时候我自己也很难都做到，和大家共勉吧。

建立互相信任的关系

知已知彼百战不殆。要理解怎样与产品经理沟通，首先要理解产品经理的职能和工作状态。

产品经理在团队中的分工是，产品经理把控用户/客户的核心诉求，定义出产品方案，并传达给设计师、技术开发、运营等团队中的各个角色，最终交付给客户满意的产品。因此好的产品经理，是需要有一定控制力、推动力的角色，否则难以推动团队配合，按时按质量把产品实现出来。

但产品经理的精力有限，思考问题很难做到面面俱到。有时候，为了保证方案落地的进度，可能会「拍脑袋」想出来一些并不太靠谱的需求，事后遇到各种问题后，为了避免上线出现明显的已知问题，「改需求」也就成了家常便饭。大家吐槽产品经理改需求的时候，有时可能也被段子手洗了脑。一个产品经理，如果不改需求的话，让产品带着明显的问题上线，反倒更不合格了吧。

因此，好的产品经理，应该把更大的精力用在保证需求大方向合理、推动进展，同时信任自己团队中的每个人能够解决自己份内的问题。

作为设计师而言，接到产品经理的需求，首先要想的是: 我要怎样帮助产品经理，把用户交互这里做到最好。这是一份沉甸甸的责任，也是一个发挥的机会。如果一个设计师总能把产品经理交过来的需求「接住」，「发挥」，甚至「升华」，那么产品经理没有理由不信任你对他产品方案上的建议。这样的信任关系需要一定时间的磨合，但最终一定会基于彼此专业度的认可而进入良性轨道。

如果这样的信任还没有建立，那么设计师可以从专业上更多地打动产品经理，如:

  1. 充分的竞品调研
  2. 多个足够好的可选方案
  3. 高效、及时的反馈

当然，与产品经理有良好的个人关系也会对需求的讨论更有帮助，但在团队中，最核心的信任依然是专业度的信任。

充分沟通预期

时间紧、任务重是产品经理口中的常态，但从负责的角度来说，任何一个可以落地的方案，都需要足够的时间去思考、整理、决策。事实上在我们日常的工作中，产品的需求主要有这样几类:

  1. 演示类
  2. 小迭代
  3. 大改版
  4. 新项目

演示类项目的特点是: 时间短，逻辑要形成闭环，细节只要没有硬伤即可，有时甚至为了演示的效果，可以把一些本身隐藏的功能、层级展开。

小迭代的特点是: 有一些简单的需求未必需要设计介入。设计师的工作是花时间解决复杂的交互问题，如果需求足够明确，产品经理和开发之间沟通也很明确，那中间设计师的工作实际上只能增加流程的时长。

大迭代的特点是: 之前的设计同时会有可取和不可取之处，设计师理解本次需求的同时，也需要了解之前版本的问题，有一些看似不合理的设计，当初可能是因为技术、运营或者多次小迭代打补丁形成的问题，这些问题现在是否还存在，需要仔细确认后再动手。

新项目的特点是: 要想推进一个项目，必须要做很多假设。假设是否成立，在事先是无法判断的。在合理的产品规划时，「必须要做」的假设越少越好，不同的假设之间是互相自恰的。进入设计阶段时，更多的细节会暴露出来，原本在需求讨论阶段时合理的假设，也可能变得不合理，这时就必须调整假设，直到所有的细节能够互相自恰。

用更大的图景思考需求

即使产品经理和设计师之间，已经有了较明确的分工和信任关系，也不能保证按需求做的「命题作文」就是合格的满分作文。因为产品经理的「命题」有很多情况下未必是合理的，在这个前提下，哪怕按产品经理的意愿 100% 甚至 120% 实现出了方案，到了客户/用户手上，还是有可能会被驳回的。

如果不相信产品经理的需求，还能相信谁呢？

站在更大的图景上来看这个问题，如果一个产品以用户想使用为目标，那么一定对用户来说是足够简单好用的。尤其是对于医生而言，看病、搞科研、评职称已经压力很大，说服他打开我们的产品已经很难，如果还要花上很多时间理解各种逻辑，忍受不少 Bug，我们不等着挨骂才怪。

怎样的产品是对用户简单的呢？

  1. 真的通过各种技术、非技术手段真正简化他的流程。
    （比如支付宝交电费，就是通过各种线上线下的努力，让用户看到电费数，一下授权就交完了，这是真正的简单，我们也要考虑换位思考，尽量把问题「解决在设计之前」。）

  2. 与用户已经会用的工具、系统接近，用户可以沿用已有的习惯。
    （文本处理并没有什么套路可言，但因为大家习惯了 Word， WPS 是靠高仿赢得了市场，即使是 Google Doc 这样的在线文档，走的也是兼容 Word 的道路。因为用户已经学会的东西，新的学习成本几乎是0，哪怕新的设计再好，对用户的学习成本也是 >0 的，所以我们要思考我们的设计是不是好到用户可以放弃原来的习惯？正面例子是 Photoshop 和 Sketch，它们的操作差异非常大，但 Sketch 靠速度、插件扩展、生态杀出一条血路。）

  3. 信息量合理，降低理解成本、提高效率、减少犯错概率 （如果不存在前面两个考虑因素，这一步就进入了纯粹的设计问题的探讨，参照苹果、Gmail 这些业界的标杆来思考一些 Best Practice 会提升效率，也能在讨论方案时加速沟通。）

所以，最理想的情况，是简化流程。「没有流程」就是最好的设计，一旦产品经理提出「我们的产品有几套流程，几种状态」的时候，就要非常警惕，认真思考这些是否是必要的。如果一个产品的逻辑我们设计者理解都很吃力的话，那一定从什么地方是需要和值得简化的。

解决问题的同时创造美

一个流程合理、操作简捷的产品，本身就有一种美感，就像我们经常所说的匠人精神。但是在满足「解决问题」这个大前提的基础上，为产品增加设计感，就是设计师只能独立完成的事情。

说起美感，大家可能下意识地会想到插画、背景、可爱的装饰元素，这些只是美感的一部分。能够在产品体现出来的更大维度的美还有:

  1. 清晰的层级之美: 就像看排版考究的杂志，大标题、小标题、正文、引言等，我们打开杂志就能很有效、明确地找到有用的信息。最有用的信息层级最高，字号最大，次要信息被弱化，但用户需要的时候也可以看清和找到。

  2. 互相呼应的统一之美: 做设计时需要克制自己的表达欲望。用户没有太多的时间思考为什么一个在他看来几乎相同的概念和元素每个地方都有差别。如果他能好不容易学会一个概念，理解一个设计，能够轻易地举一反三，那么他如果有强迫症的话，也会被治愈很多。当然，「统一」并不是机械的，它的目标是降低学习成本，如果因为统一造成两边的设计都变得劣化，那么更好的方式是加大它们的不同点，防止用户混淆。

  3. 好好说话的人性之美: 每个产品经理、设计师可能有意无意会发明一些概念，幻想着用户一旦「接受了这个设定」之后，就能理解背后的一整套复杂逻辑。绝大多数情况下，用户并不想增加自己的认知负担。如果不是故意把用户忽悠晕，就尽量不发明概念，说话的方式简单点。

这些美感上的提升，是润物细无声的，最终达到的效果，依然是让产品经理信任你解决问题的能力，乃至你专业的品味。基于这一层信任，才能使得设计的发挥空间更大。

珍惜每次展示设计的机会

看到摄影师大作时，惊艳的同时，我们也无形脑补:大师每张照片都拍得很棒。大师固然是大师，但大师更重要的一点，是爱惜自己的羽毛，把那些最好的照片示人。那些拍得不够好，稍有瑕疵的照片是不会给别人看的，甚至最好的那些照片，也会仔细裁切细节、调色到不能再改为止。

身为设计师也是一样。每次设计稿的展示，都可能是唯一一次打动别人的机会。在设计师团队内部的交流可以展示一些半成品，因为大家更能理解和脑补，也会给出很多建设性的意见。但对于产品经理、技术开发、等其它角色而言，给出的设计稿几乎等同于线上产品的效果。要想让大家尊重你的专业性，就要珍惜每个展示设计的机会，只把非常满意的设计稿给出来。

和产品经理的交流中，一定要避免坐在旁边一起改，或者把半成品和产品经理讨论。以墨菲定律来概括，就是「那些你最不希望被选中的方案，一定会被选中。」任何一个方案的沉淀都需要足够的时间和思考。产品经理能够当场拍下来的方案，他思考设计的时间和你的一样多，足以说明决定不靠谱了。