时常听到身边的 UI/UX 设计师朋友抱怨，与自己合作的产品经理似乎不靠谱。那优秀的产品经理是什么样子？和优秀的产品经理合作又是怎样一种体验？我在下面列举了一些我从合作过的产品经理身上看到的优点，但这并不是这篇文章的重点，透过这个问题，我思考了很多关于 UI/UX 设计师职责相关的问题，希望大家可以往后看。😝
– 厉害的产品经理具备 Storytelling 的能力，分得清目标和手段，描述需求时能够脱离具体的界面方案，能从用户的视角说清楚期望的路径和想要达到的效果；
– 他们身上会时不时散发出来一种与数据指标无关的使命感；
– 在讲述需求的时候他们能给设计师留足发挥的空间，也能给自己留足余地；
– 需求从哪来、往哪打，产品经理应该比任何人都清楚，不会拿方案倒推目标，不会强行给 KPI 包装「使命」；
– 对自己的方案有信心，不会盲目地跟其他主流产品的方案做「找不同」然后推测些没缘由的理由用来「指点」自己的方案；
– 跟工程师对接的时候，方案的完成度高，即使遇到技术障碍也不扯皮、不甩锅给设计师，能够帮助或启发工程师实现共赢最好，实在不行方案该改就改，不瞎给别人添麻烦；
– 在任何环节，有感觉不对的地方不会假装看不到，而是能构建良好的讨论氛围再抛出问题，一起讨论直至解决；
– 在讨论氛围比较激烈的时候，懂得给其他人找台阶，也会在别人给出台阶时自己主动下来，不会非要在言语上战胜其他人；
– 在跨部门沟通的时候能主动扛大梁，沟通中很明确自己要什么，不卑不亢，能让业务组的设计师、工程师感到安心；
– 能正确的看待数据指标和产品目标的关系，不一味的把数据指标当目标，上线后能客观合理的利用数据指标验证目标是否达成；
– 能够从发散的产品方案中归纳出逻辑，能协助技术同学搭建一个扩展性良好的产品架构；
– 以理服人，就事论事，不总是搬出各种 leader 来压制其他人；
– 喜欢和大家分享各种好消息，会把老板的夸赞分享给大家；
– ……
说了这些我觉得还没完。「和优秀的产品经理合作又是怎样一种体验？」这个问题其实挺犀利的，一不小心就说出了很多设计师潜在的心声──合作的产品经理似乎都不靠谱。但我觉得我们不妨也想一下，如果这个问题倒过来，产品经理肯定也很期待遇到优秀的设计师呀，那我们觉得自己算不算「优秀的设计师」呢？
我想说，设计师真的不应该把产品经理放在自己的对立面上，在一个糟糕的工作流程中，产品、设计、开发… 所有人都被困在里面，我们不能光指望别人去解决问题。毕竟，与不同段位的同事合作，本身也是一种职业技能。
也有一种声音说，产品经理的基本素养是不要一直改需求，这一点我不完全同意，我觉得虽然「靠谱」很重要，但这种「靠谱」应该更多体现在交付给工程师的阶段，也就是把方案的不确定性在前期解决掉。这里的「前期」，也就是产品经理和设计师对接的过程，在这个过程中，就应该是不断修改「需求」，没错，就应该是不断的修改。
前司的一位设计师朋友前几天也在微信上问我：你在新公司合作的 PM 写不写需求文档？当时我其实也不知道该怎么回答，因为快速回溯了一下自己过去几年的经历，我好像真的没见过几次写好的「需求文档」。
网络上关于「需求文档」的讨论不胜枚举，但多数都是面向技术研发环节的。那么对于 UX 设计师来说，「需求文档」究竟应该是怎样的存在，没有「需求文档」我们就没办法好好工作了吗？
首先我想纠正一个认知的误区：
在不少设计师的认知当中，一支产品团队通常先由产品经理规划迭代方向、产出「需求」，再由设计师负责将「需求」具化为界面方案，最后由工程师进行开发、上线。这个流程本身没有错，但相比实际情况来说，这个描述过于概括了，例如一句「规划迭代方向」，背后可能需要大量的分析和研究，外加多人数轮的思考和沟通，这不是产品经理一个人拍大腿就可以完成的，也不应该是产品经理一个人去完成的事情。
但我这里给「需求」两个字加了引号，其实也是想说，很多时候产品经理交给设计师的那些东西，根本称不上是「需求」，哪怕附了原型图或密密麻麻的逻辑描述，也顶多算是一个草稿。
那设计师应该怎么做呢？我求求你千万不要立刻打开 Sketch 画美美的界面，这只会让你更早开始陷入深渊。你需要做的，是通过沟通，帮助产品完善「需求」，对于 UX 设计师来说，这个沟通的过程，甚至比能画美美的界面更重要。
我们都知道在界面方案之前，应该有痛点分析、应该有问题定位、应该有流程梳理…… 但在自己的工作中，我们真的按这种方式去执行过吗？我们是否只会看看同类竞品，然后随便把几个 Fancy 的控件拼凑在一起就交差了事了？
产品经理可能想达到目标 X，他会提出方案 A, 但其实达到目标 X, 可以有无数种做法。对于设计师来说，我们的工作职责绝对不是把方案 A 做的更美、更炫酷，而应该是去思考，达到目标 X，有没有方案 B、C、D…… 在不同方案的权衡中，是否可以从目标 X 里细化出更小的目标 X1、X2、X3…… 这个过程如果设计师不主动参与，只等着「需求文档」来告诉我们接下来该做什么，真的不应该。
大家现在都爱讨论设计工具和设计控件库，像 Sketch 或 Figma 这种把设计组件化、标准化的工作方式，很大程度上释放了设计师的生产力，我最近也在想这些东西的出现意味着什么，难道以后设计师只需要像拼积木一样搭出个界面就可以了吗？我觉得并不是，视觉制作的简化，可以让设计师更多地关注自己的方案、流程、策略是否真的足够好，是否真的能实现目标 or 解决用户问题。「美美的界面」也是好的，它是人文精神、情感化的表现，是一种附加价值，但它依附于一个完整的解决方案，否则也只是一层空壳。而 UI/UX 设计，则是通过界面方案解决问题，重点在解决问题，而不在于界面本身。
再说回开始的问题，我觉得团队合作中，把所有期待都放在其他人身上不是一个积极的习惯，这种「实习生心态」会阻碍我们突破自己。试着补足其他人的短板，也许可以帮我们解决现在遇到的问题，大家加油。