我最经常被问到一个问题，“什么才是最为有效的互联团队工作方式？”。通常我都会以这样的方式来应答——“看来你正在寻找一个最适合自己的方式”。在我看来，这里确实没有一个统一的标准答案。
最近看到了一篇关非常有感触的文章，原题目为《One Year Designing at WhatsApp》（在WhatsApp做设计的这一年），作者是Charlie Deets。文章分享了作为Facebook资深产品设计师的他加入WhatsApp后对于两种截然不同的产品文化与工作方式的感触与思考。
我是在Facebook官方的设计博客中发现它的。里面有很多作者作为两家公司亲历者的真实感受，很有启发，所以花了些时间进行了翻译与君共享。
作者：Charlie Deets
原文：《One Year Designing at WhatsApp》
地址：https://medium.com/facebook-design/one-year-designing-at-whatsapp-c20b4c46bae6
一些关于WhatsApp与FaceBook如何针对大规模用户进行产品设计的想法
我之前以产品设计师的身份在Facebook工作将近四年。我与许多产品组都一起共事过，比如“群组”、“分享”与“隐私”等小组。在去年的这个时候，我获得了在WhatsApp工作的机会，这让我感到非常兴奋。
在我进入WhatsAPP之后，我了解到，在WhatsAPP做设计是与之前在Facebook是完全不同的两种体验。这种体验比我预料地要更加让我大开眼界，并且教会了我从各种不同的角度来看待问题，而非我之前那样的思考方式。
在过去的一年里我学会了很多东西，现在想分享一下我对于WhatsApp与Facebook这两家公司的产品设计工作的观察与思考。
强大的设计原则
WhatsApp在设计与搭建它的产品时会将一些特定的原则考虑进去。这些原则是产品决策的重中之重。下面的这些例子就体现了这个价值：
· 产品的界面应该与用户所用的设备看起来是天然一体的。
· 前端产品应该是非常轻量的，要尽最大可能地减少它的大小。
· 产品界面应该非常的简单。
· 用户交互与动画都应该具备非常快速地反应。
· 所有的功能都应该具备非常高的可用性，所以它们几乎不需要说明与引导。
不同于此，Facebook使用一个很高层次的远景来驱动公司决策。WhatsApp使用这些原则聚焦产品讨论，所以大多数关于产品设计的思考都会直接涉及到产品细节的执行。
每当我与Facebook的设计师谈起WhatsApp的这个特点时，都会遇到大家的反弹。他们会这样回应：“我会很讨厌这样的做法！谁来决定产品方向呢？这样的做法不会让你感到失控么？你还能再谈谈其它的想法吗？”
在涉及到产品路线图的时候，WhatsApp的产品决策方式比Facebook更加的“自上而下”。我个人认为，这让能够更加专注于自己手头上的工作。我通过设计来影响产品本身......因为我是一个设计师。
话虽如此，但我依然有对产品路线图的决策提出建议与表达思想的空间，但通常情况下我并不需要去这么做。因为依照路线图选择出来的项目也同样遵循刚刚分享的那些产品原则。
我最大的收获就是发现如果你的团队可以发现一些强大的产品设计原则并形成共识，你的团队会变得更加有效率。你们形成的共识越多，你就会变得越有效率，而且为了让团一起打成共同的目标，减少一些沟通也会变得很必要。
在创造产品的过程中，清晰地知道”要为人们解决什么样的问题“是成功的一半。具备一个产品决策的指导框架来评判各种建议会让另外一半工作变得更加有效。
可用性研究与实践的相互关系
在Facebook工作的时候，有时设计师会被安排设计一个新的功能。这项工作非常具有挑战性，一位Facebook已经拥有了许多有用的功能。在一个已经有用户正在使用的产品上进行改进从来都不是一件简单的事情，但引入这些新功能时我们总是想能够提升用户的使用体验，并用户更多有用的工具。我们在不断提醒用户来使用一些可能对他们有用的新功能。
WhatsApp用另一种更加务实的方式来解决这个问题。我们只努力去设计与搭建一些显而易见有用的功能。如果这个功能还需要解释，那么说明它还没准备好。
我尽量避免在产品中提醒用户使用新功能。我们假定，如果我们创建的功能是足够有用的，那么用户就一定会发现它们，并自然而然地使用上。
有人可能会反驳说，我们目前用户规模这么大，当可以有这种天真的想法。从另一个方面说，我相信这种方法论来自于产品决策本身，并且与正在使用WhatsApp的用户产生了共鸣。
对于我来说，在这里学到的就是”从来没有一个可以用来创造产品的单一设计公式“。你可以通过弹出窗口等方法来帮助用户去体验新功能，但你也可以被动地鼓励用户来发现它们。在产品决策中去努力发现用户的意图，非常有益于创造出一种受尊重的产品体验。
设计工具与设计能力
有一件事让我现在非常怀念，就是在Facebook设计产品的时候受益于那些已经变得让人惊讶的设计工具。在Facebook有一个独立的团队，他们专门聚焦于通过创造各种非常棒的工具来让设计工作变得更加简单与有效。
我几乎每天都使用Origami来制作我的原型。我非常喜欢它。但是现在由于WhatsApp并没有一个正式的界面工具，也无法使用Facebook的界面API，所以其它曾在Facebook帮助到我的工具与我目前工作的相关度就变得更加的低。
对于WhatsApp来说，维护一套界面工具所需的工作量要比我们目前这个团队的”产值“大得多。我们非常依赖平台原生的设计模式，所以对于自定义标准控件的需要要小得多。我们把常用的一些设计在Sketch中做成模板互相分享。这与高度结构化的Facebook与Instagram系统相比显得非常原始。
另外一件让我在WhatsApp工作中感到惊讶的事情，就是我经常不得不通过手绘来输出一些成果。对于我来说，在Facebook的界面上来发挥我的交互能力一点问题都没有，而且，由于我们使用非常棒的插画工具与牛叉的作品分享工具，我的视觉设计技巧几乎没有被挑战过。所以我从来都没有认为自己是一名视觉设计师。但是在眼下这个小团队，你必须做好每一件事——包括完善一些视觉设计的细节。
关于这一点，我在这里学到的是，虽然工具可以把你的工作变得更简单，但依然鼓励你偶尔退一步，确保你可以在没有工具的帮助下完成工作。至少，这样可以让你对于工具的用处保持一种客观的判断力。
一些特殊问题
我在WhatsApp遇到的一些产品问题是我从来都没有处理过的。举个例子，端到端的加密就有许多充满挑战的副作用。在WhatsApp中，信息被存储在了用户自己的设备中，用户发送了的信息就不会被存储在服务器中。
这就导致那些底层技术不了解的用户对于界面的上的一些行为产生误解。比如，当你从一个新设备登录到WhatsApp上时，你无法立即获得你所有的历史信息。因为这些信息依然仅保留在你的旧设备上——它们并没有被拷贝在服务器上。
在Facebook这个情况通常这样处理——加入身份验证，它是设计的基本组成部分。在WhatsApp，我们不需要用户提供头像照片，我们也不许需要用户提供他们的用户名！在Facebook是我会理所当然地在我的设计中加入身份验证，但是当你无法依赖身份验证时，某些问题就会变得更加棘手。
另一个有趣的例子，就是把文字当成理所应当。用户在WhatsApp上可以使用语音、照片以及视频的方式来彼此交流，而非文字。我曾经历了一个有趣的挑战，为用户登录WhatsApp设计一个界面。用户需要了解到他们的通讯录已经成功地与WhatsApp进行了连接，并知道从哪里开始使用。而这项设计工作需要对那些没有读到引导文字的用户依然有效。
谨慎且慢行
在Facebook，你提出一个问题，然后你为它提供一个解决方案。如果你能够让团队感到兴奋，你就可以继续对它研究与测试。如果测试效果不错，你可以开始搭建它，并且把它推出去看看是否能够解决问题。如果问题也被解决了，那么最终你要把它丰满成一个功能并发布给更为广泛的用户。这是一个迭代的过程，其中有很多的检查点以及内建的平衡。这个成熟的流程效果还不错。
在WhatsApp，你发起一个问题后要努力处理一系列的解决方案。首先你把看起来最优的解决方案写出来，并且要与产品原则相符。你要反复不断打磨这个最佳方案，直到你认为它无错可挑。接着工程师对此进行研发，然后在一次产品升级中你把它推向所有用户。这种工作方式一定程度上也算得上是一种迭代，但是主要都在产品设计阶段。为了能够发布得当，它给予了设计工作额外的压力。
Facebook拥有”快速行动“的价值观。在Facebook可以让一个项目非常快地启动起来，但是整个产品的发布过程还是需要花费一些时间。如果WhatsApp也有一个座右铭，那么它应该是”谨慎且慢行“。我们把更多的时间前置到了产品设计阶段，这是因为我们在开发阶段更不易转型。当我们向工程师交付设计时，我们真的会尽可能地提供一个详尽完备的说明与各种原型。工程师很欣赏这样的做法，它的一个优点是减少了研发过程中的干扰与变化。潜在的缺点，就是工程师会感觉在整个产品的设计过程中缺乏参与感，会感到与产品决策更加的隔离。
在这两种工作方法中都有各自的优缺点。但是我学到的是，这两者都有效。并不能说明哪种更快，而只是不同工作风格偏好的差别。Facebook的风格允许更多角色间的相互重叠，而WhatsApp的风格则是以个聚焦各自角色的工作流。
总结
我希望这些分享能够帮助到你来思考一些新的工作方法，或者提出新的方法来为你目前的团队带来一些价值。能够亲眼看到不同的工作方式都能够创造出极具规模的伟大产品，我感到很兴奋并备受鼓舞。这些内容只对从事这些工作的人有意义。我认为对于工作方式的探索非常重要。
其实我也希望通过这篇文章增加大家对于WhatsApp设计工作的关乎度。我们是一个正在成长的团队，需要更多的伙伴来加入。如果这些价值观与工作方式很吸引你，那么你应该来看看我们公开的职位，特别是产品设计师这个职位。
（原文完）
读后感
国内大多数的团队与WhatsApp的工作方式相似。这种各司其职，上下游清晰的瀑布式工作流更接近传统的工作方式，因为容易实施所以被很多“善于管理”的老板看重。但是大家为什么还是做不好呢？作者在这篇文章中有提供了一个非常重要的线索——“强大的产品原则”。
这正是很多非产品出身的老板所忽略的地方，认为既然工作流程清晰，所交付成果的质量也自然可以轻易把握。但不要忘记，这取决于“创造”这两个字在你的团队目前的工作中所占的份量。对于需求清晰不变的传统IT项目来说，没什么需要再创造的，而且创造越多还可能错得越多，采用这种瀑布流显然最为合适。但对于大多数互联项目而言，但凡对团队有了“创造”的要求，那么作为老板就需要额外为“创造”打造环境。
WhatsApp这样的瀑布流式工作法表现看上去团队是收敛与集中的，大家都在为一个“目标”工作。但实则每个成员之间却是极其“分散”的。就像文中提到的，除了核心几个人之外，大多数成员的归属感是很低的。他们看起来更像是公司内部的“外包”。所以类似于是“产品原则”这样的方式其实起到了一个收敛框架的作用。如果你所在的团队也同样以瀑布式工作，那么你可以尝试推动大家形成一些原则共识。你会发现，在这样的团队中，号召大家讨论这些原则要比讨论产品目标与愿景更加受欢迎。因为这些信息关系到每个人的具体工作效果。而且，产品目标也会从这些原则之中逐渐清晰起来。
像Facebook这样的充分迭代与试错的工作方式在国内不多。因为除了对个人技能要求高之外，最重要的是彼此间的信任与安全感。这样的工作方式的背后是“挑战”式的团队文化，这与传统“家长”式企业文化截然不同，很难在后者中孕育车这样的氛围。所以国内一些小团队，或者团队在创业初期时还可以做到，但团队一大，人员一混杂就完蛋。去年我就犯了一个错误，妄图在一个“家长”氛围浓厚的大团队中建立充满参与感的“挑战”式小团队。虽然前期项目速度明显提升，小团队中的伙伴也收获很多，个人成长很快，但最终依然以惨败告终。
这几年积攒的案例越来越多了。打的仗多了也看得更明白了一些。其实很简单，一场仗能不能打，采取什么姿势合适，只要看发起这个战役的人是谁，他是什么性格。他是喜欢蒜汁还是芝麻。没有什么标准姿势，找到合适的就是最好的。
创造，因创造者而不同。
