产品团队工作秘籍：如何与设计师、产品经理、开发者一起工作？
原文的作者是 非死book 的产品设计总监 Julie Zhao，这个系列一共有三篇文章，分别是如何与设计师，产品经理和工程师合作，早在去年年中就发布在 Medium 上，最近再读的时候就想翻译一下，网上的译版看了以后更加坚定了译一个自己的版本的决心。老文新译，希望对还没有看过的小伙伴们有帮助。
如何与设计师一起工作
——给工程师和产品经理的秘籍
在很久以前，我曾经做过产品经理，之后也做过开发工程师，在过去的 7 年里，我从事设计的工作。每一天我都和担任这些角色的人一起工作，而每一天，在产品开发中，我对这三种角色相互合作背后的责任，挑战以及艺术都有新的体 会。对于那些想搞清楚设计这个奇幻世界的工程师和产品经理，这篇文章就是为你量身定制的。
用设计师的语言，停止谈论软件指标，一起来说说用户，
通常，这两者差得并不太多。比如，你也许要说的是设定一个目标，将注册转换率提高X%，用另一种方式来说则是，你想做的就是要扫清那些让用户注 册变得复杂的障碍。但是你看，怎么说在这就很重要，“让用户注册变得更简单”与“优化注册流程的转化率”。一个说的是对于用户的价值，而另一个则是倾向公 司需要怎么做才能获得成功。设计师通常都是站在用户的角度来思考和行动的。
其他的基于设计师语言的翻译：
我们能增加按钮的点击率么？ => 如何让用户知道这个贴心的新功能并且知道它很易用？
我们不能让这个改变影响了软件评定的指标 => 我们需要确保这个改变不会让用户的使用变得更加困难。
让我们提高产品传播率=> 让我们鼓励那些喜欢这个功能的用户分享给他们的朋友
译者注：产品传播率，原文用词是“viral coefficient”，直译是病毒性系数，为此我还专门找到一篇文章， 这个传播率= 参与邀请的活跃用户的平均邀请数x活跃用户中有邀请他人的用户比例x受邀用户中实际加入的用户比例，比如产品有 100 个活跃用户，其中 50 个人有邀请别人，平均是邀请 3 个人，而其中只有 2 人加入，那个这个数值为 3 x1/2 x 2/3=1, 这个参数大于 1 则说明你的产品用户数量会以指数增加，小于 1 则说明你需要通过一些市场手段来提高用户数。
设计师都有各自的强项， 好钢要用在刀刃上
每个设计师都不一样，即便是“全明星”设计师，他们思考问题的方式也不尽相同。因为设计包罗万象：
1. 视觉设计：排版，对比度，层次感，以及那句老话“这看上去怎么样？”都属于这个范畴。正确的吸引用户的注意力了么？细节是经过精雕细琢的还是草率完事的？还有更重要的，这套视觉设计是否系统化？
2. 交互设计：用户完成某个任务是否简单清晰？导航系统足够强大么？动画对于用户来说是否自然？
3. 产品设计：这个设计很好的解决问题了么？这个设计点有用么？是否有清晰的愿景？带来价值与否？
有些设计师在视觉方面是个大牛却在交互方面经验缺乏，有些有着很好的产品策略却在设计建模上偏弱。每个设计领域都有独特的难题，选择拥有正确职 业技能的设计师来解决就显得尤为重要。你不能指望随便换一个设计师就能得到同样的设计输出，通常一个好的设计，以上三方面都是需要考虑到的。如果团队里只 有一个设计师，那么这个人最好是个多面手，而非在某方面特别优秀但是其他的却很弱。如果有一个设计团队的话，聚集各领域的能手也行的通。
设计师越资深，就应该解决越抽象的问题
为了进一步说明，让我们来看看一些设计师等级以及对应职责的例子：
设计师等级1： 设计一个表格，用户可以通过它来编辑个人资料。非常具体——假定用户需要编辑个人资料，设计出表格的形式作为解决方案。
设计师等级2： 设计一个界面，用户可以通过它来编辑个人资料。这个界面可以是一个表格，可以是所见即所得的实时编辑控件，也可以是一个模态窗口。
设计师等级3（广度）：设计一个可以更改个人资料，文章以及设置的编辑系统。这个要求就不只局限在个人资料上，而是一个灵活多变，横跨应用的编辑系统。
设计师等级 3 （深度）：设计让用户更新个人资料的方式。这样设计师需要思考，为什么用户需要更新个人资料？在何种情况下？以及如果更好的引导？
设计师等级4：设计一个解决方案，从而提高应用中用户的真实性。编辑个人资料也许甚至都不会成为我们关注的焦点了，也许用户间的相互评价系统更靠谱。
设计师等级5： 找到应用/公司/网站存在的产品设计问题，并提供解决方案。在最高阶，顶尖的设计师往往是能够推动产品愿景的。
换句话来说，当一个资深设计师感觉自己对产品愿景和策略有很强的主导权时，他会在提案中表现出高度生产力。相反，如果一个资深设计师拿到是一个 初级的设计任务时，比如“设计一个表格”但是认为表格根本不是正确的解决方案，他们也许会对工作安排产生不满情绪，甚至很可能无法很好的完成这个设计。这 种情绪正是影响团队士气的根源：越是资深的设计师，当他们根本不认同产品愿景和策略时，会越沮丧。
设计师之间的交流越多，工作开展得越顺利（设计师也会变得更好）
设计师之间互相反馈意见是改进设计最重要也最为有效的方式。如果设计师是独自工作并且从未给其他设计师看过自己的作品的话，那么几乎可以保证这 样的成果会比定期讨论的效果差。这就是我们为什么希望设计师们在项目研发阶段（设计随时都会迭代更新）坐在一起工作，而仅在项目执行阶段（设计基本已经定 稿，执行开发变得更重要的时候）与工程师坐在一起工作。
设计师的价值和他在产品团队中付出的努力是很难衡量的
因为设计师的目标是高品质的体验——不仅是应用的某一个方面，而且是横跨整个应用；不仅是短期，更是经得起时间考验的。举“杂乱”为例，大家通 常都认为杂乱是不好的，但是如何评定在添加到什么程度后变得“太杂乱”呢？这根本没有办法量化，同样你也没法通过添加某个设计点而让用户马上感觉到提升。 但是慢慢地，就是像海浪冲刷岩壁，这些点积累到一定程度，用户就会觉得你的网站杂乱不堪，这时有其他更清新简约的应用能取代你的话，就太迟了。
同样的，设计师经常要求应用或是系统中不同部分做到一致，这看起来似乎有点过于挑剔，因为从功能层面来讲，例如上传照片的流程是一致的，这样不就够了么？
但问题是，用户不仅只上传照片。他们可能同样会上传视频。如果上传照片和视频的流程是明显不一样并且是完全独立的，这将十分令人困惑。用户在上 传照片和视频的时候会很痛苦。想想一下如果“文件”菜单项在每一个产品里的位置都不一样，有时在左上角，有时在右上角，或者是底部又或者是其他任何地方， 这对用户来说都将是一个噩梦。
的确有些设计师在对重要性的平衡上不足。比如倾向于过高估计自己的个人经验而低估大家乃至整个互联网形成的经验，又或是基于自己的体验来设计产 品，而事实上他们并不是产品的目标用户。（当然，这里只是宽泛的说明问题，显然并不是每个设计师都是这样的。）但事实上，短期内的量化指标会受设计的变化 而上下浮动，从而很难评估。像用户对产品的信任、理解、长期的情感和喜悦——都会因为设计师对产品的改进而受到积极的影响，而这些却是很难量化的。
关注细节，直击设计师的内心
说真的，你想要让设计师心花怒放，喜悦万分么？那就精确地将每一个像素都实现出来。设定高标准决不允许粗糙的页面存在。为了实现一个设计细节而 不惜大量工作，或是彻夜加班去做那些明确要取悦用户的功能。据我所知，每一个设计师都喜欢与重视设计的产品经理和工程师一起工作——心甘情愿放弃夜晚和周 末的个人时间，就是为了与团队一起奋斗将产品实现，因为这是大家的共同信仰，整个团队都希望能创造出真正有用、闪耀和更上一层楼的好产品。
如何与产品经理一起工作
——给设计师的秘籍
产品经理就像是变色龙，为了产品能成功上线，他们不断地去适应新的需求变化。作为设计师，如何对待他们的个人魅力、大量的数据分析、团队聚合力以及能言善道的说话方式呢？往下看吧。
了解产品经理的工作是帮助团队成功上线产品的桥梁
这意味着， 产品经理多半都极其善于：
1. 清晰的沟通：作为团队里帮助产品成功发布的重要组成部分，产品经理需要将团队的目标，优先级以及发展蓝图呈现给公司的不同部门，包括法律部、市场部、客户 运营、销售等等。这意味着他们的思路要非常清晰简明，有重点。设计师或者工程师的表达如果有抓不住要点或是含糊其辞的倾向，还尚可原谅——这通常不是这些 职位描述的首要要素。但是对于产品经理，这是不能容忍的。这就是为什么产品经理需要向高管们或是外媒展示产品——并不是因为他们看上去比设计师和工程师更 加“正经”，而是因为产品经理普遍拥有更好的沟通技巧，如果他们没有那肯定不会被公司录用。
2. 善于组织：为了上线好的产品，产品经理必须随时了解项目进度，以及项目是否在正常的运行。他们能够在需要时将这些碎片化内容重组成一副完整的画面展示出来，这需要超强（忍术级别）的组织能力。
3. 善于和各种各样的角色合作：对于产品经理而言，每天和许多来自不同团队的人交流是习以为常的事情。因为产品经理通常并没有人事权去让团队做事（比如他们并 不能直接聘用或炒掉工程师或者设计师），他们需要向这些同事证明自己并获取信任。如果产品经理是个傻冒，他们会很快地不加修饰说出自己的脑残想法，这样是 会降低交流的成效的。大家都知道那些陈词滥调里古怪的人，难搞的工程师、无法信任的像 Don-Draper（来自广告狂人）一般的设计师，但我曾经也遇到过类似的产品经理。要重申的是，这只是宽泛的说明产品经理的一些问题，但是我必须承 认，产品经理通常都比工程师和设计师有着更成熟的想法和同理心。
同时，每一位产品经理，和设计师一样，都是有各自的强项的。
只有好的沟通能力，组织能力，好的协作能力还不够。一个好的 PM 还要具备以下技能中的几种：
1. 执行力：产品经理在发布产品中时表现的如何？ 这可以通过以下几个方面来评定：1）成功与否取决于目标，2）及时与否取决于期望，3）顺利与否取决与团队的感受。越是资深的产品经理，就有着越大的执行 野心。（比如，一个初级产品经理负责的是给Y产品加一个X功能，而资深产品经理负责的则是建立一个移动平台产品套装Z）。好的执行能力，就像是船长平稳行 驶着一艘船。你需要保证每个人都知道自己的职责并且很好的执行，整个团队齐心协力，这样你就能有效评估是否带够了补给，还有当你驶向地图上标记的X目的 地，不会被海怪搞死。
2. 设计思维：产品经理在理解，领会以及帮助推动成功的用户体验上表现如何？设计师十分渴望与拥有这种技能的产品经理一起合作。这并不是说她一定要在设计专业 上非常在行，但她应该对设计内容、目的，有挑剔的眼光，并且理解设计师的价值，即使她并不总是同意设计师的建议。
3. 分析能力：产品经理对已知信息是如何计划以及得出结论（定量数据，任务，用户反馈，过去的经验等）以便于将来提出更好的工作划分？一个具有分析能力的产品 经理总是会考虑一切已知和未知的因素，为之后的工作，获取更多确定性和可预期的因素。一个极具分析能力的产品经理会使用各种工具去帮他确定目标，为任务排 定优先级，让项目有序进行从而提高产品开发的信心。
4. 大局观：产品经理是如何理解市场、现有技术、问题、以及产品的反响从而提出极具创新的解决方案的？这是更高阶的技巧，产品经理都是梦想家，就像是燎原的星火，点燃了并激励这整个团队去追逐那些大胆有时也极具风险的新方向。
作为一名设计师，和产品经理一起工作，很重要的一点是需要谨记整个团队必须要在工作任务上得到很好的平衡以及正确的安排。这意味着，例如缺乏设 计思维的产品经理应该避开以设计为中心的项目，像是重新设计产品、开发新产品，或是与资深的设计师合作来弥补这个技能缺陷。同样的，那些在目标和时间上把 握不足的设计师就需要与极具执行力的产品经理一起合作，帮助他们关注在更重要的事情上。
别把产品经理当成监工，与他们并肩作战，你的工作就会变得更容易
需要了解产品相关领域的知识？找产品经理去。（如果他们不知道，他们会帮你找到知道的人，或是开始研究直到找到答案）。想要客户、销售人员或者 用户的反馈？找产品经理去。想了解现在产品开发优先级或者最严重的产品漏洞么？最新的数据能为Y功能带来什么信息呢？也许你还要感谢产品经理从一些新的角 度给你提供的建议，如何给你的 7 个设计提案里排定优先级，哪一个应该优先细化。
你的产品经理可以为你提供相关背景、数据以及各种有效的反馈，让你可以做出最好最适合的设计。他们同样可以帮你搞定 85% 的干扰因素，好让你更专注在设计上。所以，有事就去找产品经理吧。
当你与产品经理持不同意见
这是一定会发生的。大部分情况下都没什么问题，这在产品开发团队中很自然会产生的一种状况，也是产品开发团队中三座基石（产品经理，设计师和工程师）之间的正常平衡。通常有以下几种方式：
1. 产品足够好了么，是时候发布了么？ 在团队中，产品经理负责将产品成功定时的发布到市场上，他们有着推动团队去达到里程碑的天性，从而让产品发布并且可以快速迭代。而设计师注重的更好的用户 体验，他们希望能够有更长的时间去做设计、研发和优化。极端地说，这些都不是合理的视角。没人希望明天发布的东西是坨便便，也没人想花 10 年的时间去设计完美的登录流程。真正有影响力的产品往往都是及时发布出还不错的东西。（大部分人都知道这点，争论的本质是关于具体哪些来评定是不是好和哪 些评定是否及时，但是由于某些原因，最后都会变成毫无效率的讨论。）那么怎么解决这个问题呢？你可以冷静理性地表明自己的立场；你可以分析延迟发布的得 失；你可以同意一起去找一个有权威的拍板人；你可以去征询一下你们都信任的人的意见（这是我最喜欢的方法）；你可以做些用户测试，判断是否其他人的假设是 错的。大体而言，只要你和靠谱的人一起工作，即使不断出现异议，这也不是大问题。
2. 我们是否应该发布设计师认为较差但是又符合软件设计指标的体验呢？这点很微妙因为它通常会有两种结果。第一种是设计师的观点是清晰正确的，而指标并没有正 确的反应出真实用户（要么太短期，要么不完整——例如，对某一点来说是好的，但是对于另一个没有被追踪的点来说却不好）在这种情况下，作为设计师，你应该 要找出其他的指标来照亮这块盲区证明这是一个不好的体验。第二种是设计师高估了自己的个人经验，无视网络形成的经验。例如，过早给用户展现“邀请朋友”的 流程也许并不是一个很好的选择，但是从长远来说，他们拥有的朋友越多，这个功能就能给产品带来更多的价值。
3. 我们根本不认同产品策略。关于这一点，我在前文“如何与设计师一起工作”中有更多的描述，这是我认为设计师和产品经理应该很认真的重新考虑是否要一起工作的最主要的情况。
先抛开那些异议，其实大家在最终目标有着坚定的一致意见的情况下仍然很容易分歧。（如果对最终目标没有达成一致，也就是刚才第 3 点提到的，那是时候做些改变了）。如果可以把这些讨论过程记录下来，并在事后回顾是非常有意义的。通常，它们很有启发意义，可以为之后总结很多有价值的经 验。有时你甚至会在回顾中发现这些很愚蠢。（我们竟然花了这么大的精力在这些小的细节上？最后这些根本不是事儿！）
最快虏获产品经理的心，就是做个靠谱的伙伴
千万别做 DonDraper（广告狂人），在午饭后消失去寻找他的“创意魔法”，然后直到周四下午才出现，我是认真的！创意领域的东西并不能作为高大上的借口，为 你免除给团队做出承诺和做出好设计的责任。没错，要预测出何时能够做出符合你所期望的高质量的好设计确实很难。但是我说的是“靠谱”并不是“每次都按时交 功课”。你也许无法总是精确地知道何时能细化出好的设计，但是你至少应该顺道花点时间和团队沟通你在做些什么，为什么这么做，以及什么时候能完成即使它不 停在变动；分享你的进度和流程；解释为什么你还在探索，以及为什么你对现有的成果还不满意。事实上，你和产品经理探讨这些会给你贴上“靠谱”的标签，而且 能帮他更高效的完成工作。除此之外，这些还能帮助他了解你工作的方式，以便将来你们建立更加牢固的合作关系。
因为说到底，你，亲爱的设计师，不只是仅仅为你的设计目标负责，应该为整个团队一起为之奋斗的目标负责。只有这样，你们才能做出前所未有的好产品。
如何与工程师一起工作
——给设计师的秘籍
工程师是团队中的魔术师，他们只需要动动手指，执行计划和绘制像素，你瞧！一款鲜活的产品就诞生了。作为设计师，如何才能跟得上他们精明缜密，自我否定又热衷脚本的工作方式呢？往下看吧。
工程师是将创意变为现实的人
是工程师将每个好点子变成现实的，这是个大家需要永远铭记的事实。不管你的公司里有 5 个，500 个或是 5000 个工程师，都不要把他们当做是一种“资源”。他们是产品基石的建筑师，也是让产品正常运行的守护者，是他们，让产品快速运作起来，变得稳定，可靠，从而拥 有数百万记的用户。通常，也是他们在创新，用新的算法在推动技术，将产品团队无数投入变得有意义。
这一切的一切我就是想表明：工程师超牛掰！
这意味着…
想要创造点神奇？你需要做的就是说服一两个工程师
真的，就这么简单。许多传奇般的产品是这样诞生的：几个好友在某个周末，一边喝着啤酒一边敲着代码。产品经理和管理什么的那都是后来的事情，一切都从最基础开始——创意，设计然后实现。这也就是为什么我们需要与工程师保持紧密的关系。
或者，试想一下这样的场景：产品中某个细节部分让你感到十分烦恼，就像瘙痒在你根本挠不到的地方的那种，你觉得这个设计很有问题，你该怎么做？
1. 在下次团队讨论会中提出来，加入到产品改进列表，然后大家一起来排定优先级，之后等待新的工程师加入团队，在他熟悉了产品之后再把它做出来。
2. 和某个工程师保持良好关系然后径直走向他的工位，请他帮个忙，花个三五分钟处理，然后再看着他提交这个改进。（也许你需要帮他做一件印着 80 年代知名乐团图案的T-shirt 或是其他点什么作为交换，反正你对插画也很在行。）
你说哪种办法更快？
也就是说…
如果工程师明白设计的价值，事情会变得容易得多
试想一下，工程师不需要来询问你每个设计细节就知道如何处理页面的空白处，即使你忘了详细标注边距的尺寸，他也会打开 PS 自己丈量——这是件多么美妙的事情。特别是他还能给你提出改进意见让你的设计变得更好，这简直不可思议。更有甚者，他细致精准到实现出的界面与你的设计完 全无二致，这是件多么惊人的壮举啊！
你如何才能与这样的工程师一起工作？如果能招到这样的工程师，那将会是很幸运的事情，因为界面设计导向的工程师是炙手可热的。
或者帮助工程师提高一些设计鉴赏力。如何做到呢？不要只是把你的设计丢给他们——和他们阐述你的设计，告诉他们设计的价值，以及为什么你的设计是值得实现的。帮助他们学会如何鉴别实现是否符合设计的要求。对于那些看起来很糟的东西告诉他们你是怎么想的。
建立良好的关系也很重要。人们总是根据和其他人的谈话转移自己的价值取向和优先级。这听起来很老套但总是屡试不爽。（New Yoker 站点上一篇名为“Slow Ideas”的文章就很完美的阐述了这个策略）
工程师大多不会关注到设计细节，但是他们大部分都很关心用户体验而且希望产品有更好的体验。这并不是说每个工程师都会热衷于设计细节的实现工作，但是这样的态度有助于他们理解设计背后的意义。
因为，工程师越是对设计喜欢，他就越能理解这样设计的原理并且看到它的价值，也就能越快越好地将它实现。
尽早搞清技术限制，为自己节省时间
身为设计师，你很容易就会沉浸在各种设计假想的世界中难以自拔。如果我们能读懂用户的心思并且知道他具体想要什么然后再呈现给他？又或是点击这个按钮会产生火焰以及爆炸成颗粒随风飘散的特效？
在没搞清技术或是时间限制前，别沉迷中那种根本不可能实现的设计。（就算是值得你去争取一下的设计方案，提前了解限制也会让你更有底气。）最坏 的情况就是你倾注大量的时间试图将某个设计提案做到完美，最后却发现它却根本不可行。好的设计师本来就够少的，而要解决的大问题又有很多，这种毫无效率的 事情应该尽量避免。
所以下次当你有个绝妙的主意在你脑海中闪过，而你却对实现难度上感到疑惑时，别猜，直接去问工程师！
另一边也是一样…
任何时候都让工程师了解最终设计会是如何，帮工程师节省时间
如果你对自己交给工程师实现的设计方案并不那么自信，在看到成品前都无法确定它是否能够运作得好，请确保让他们知道设计有可能会有变化。对于工 程师来说，没有什么比“通宵完成实现却在第二天早上得知整个设计已经改了”来得更困扰的事情了，因为这样他们要把那些倾注了无数心血、成品级别的代码统统 丢掉了。
当然，工程师都有写出废代码的经历。这是他们工作的一部分，设计也是一样。好的工程师理解产品研发的流程是复杂的，东西做出来之前都不知道是否 能行得通，需求常常变化，设计也是。但是沟通清楚哪些部分仍然还在探索，哪些部分基本已经敲定，可以帮助工程师想出如何更好的构筑代码，是更快速的编程， 还是写得足够灵活为将来的修改做好准备。
确保设计得到完美实现的最好方法就是极其密切地与工程师合作
像是坐在他们的边上看着他们把东西做出来。大家都坐在同一个空间里工作，对于确保大家是否进度一致这件事，则显得异常容易。问题更快浮出水面，也能更快得到解决。
最终产品如果不是每个人都引以为豪的成品，各种指责将轻易出现。“我们的设计很赞的，但是工程师根本就实现得不对。”这种思想要不得。作为设计 师，你需要对面向用户的产品负责，而不是那些 PS 的设计稿。对于实现不对的地方为什么不拿出些该有的行动？为什么你不让工程师给你演示一下他们实现好的东西这样你们就可以一起抠抠细节？为什么不在开发阶 段问问工程师们是否对你的设计有任何疑问？为什么不在发现后给工程师提交一个任务让他去修复？
没错，拿出你的担当来！
最快俘获工程师的心的方法，就是提供完整的设计
说起来也可笑，人们总是用“细节导向”来形容设计师，然而事实上许多设计文档遗漏了大量的场景，最终却由执行这些分支开发的工程师找出来。
想成为工程师心目中的设计英雄么？请确保你的设计方案是完整的，考虑到各种边缘场景例如：
1. 国际化： 设计在换了另一种语言后看起来如何？尤其是德语下长文字对排版的影响如何？
2. 出错状态：网络连接丢失时会发生什么？或是数据崩溃？等等。
3. 极端用户： 当用户完全没有任何信息或是活动时，页面是如何的？那当用户有着超级多的信息或活动时呢？
4. 页面转换：A屏到B屏的跳转具体是怎么完成的？好的工具在将给你帮大忙，具体可以参考我的另一篇文章《如何在设计（以及僵尸启示录）中生存》
设计上述的这些场景不仅可以帮你全局的考虑产品从而增加对设计的信心，更可以帮助工程师去计划如何构建系统，并给出时间上给出合适的评估。更不用说完整的设计可以避免临时抱佛脚出来的粗制滥造，因为之前没人发现直到想做得更好却为时已晚。
请做一个合格的团队贡献者，确保你的设计是完整的，别只为理想的情景去做设计，从设计效果图的幻境中走出来。因为每一个工程师都知道，唯一有价值的就是最后发布的那个产品。