Facebook的产品设计经理 Adam Mosseri最近做了一个非常棒的演讲： Data informed, not data driven（数据启示，而非驱动）
演讲以Facebook如何利用数据指导产品设计为主线，还涉及到Facebook的产品设计团队架构、不少的设计案例，以及Facebook是如何做产品设计决策等。 本文将其内容以译介形式总结如下（意译非翻译）。
1. 小而精的产品设计团队
“ It’s important to understand that, at Facebook, we believe in particularly small teams. ”
（有一点需要被清楚认识的是，在Facebook，我们特别认可小团队）
Facebook的产品设计团队通常只有6、7人，因为他们认为这个人数最高效率，且团队拥有的产品决策权很高，架构扁平( flat decision-making structure )，有的决策可以直接到CEO那里待通过。
一个产品设计团队的结构通常是这样的：
一名设计师，负责交互、视觉，产品战略(product strategy)，甚至一点前端
一名用户研究员。两年前，Facebook只有为数较少的研究员，而且只负责大项目，如今，随着对于定性研究的重视逐步增加，基本上每个团队都配一名。
一至四个工程师。
一个项目经理(PM)，项目经理通常相当于团队中的迷你CEO，需要对产品负责。不仅要保证项目的按时完成、资源协调，还要保证产品质量。
产品 设计团队之上，会有一个经理负责统筹管理。演讲者本人就担任这一职位，他负责着九个产品设计团队。另外，有专门的20人数据团队，一半是工程师，一半是数据分析专家。
2. Facebook如何利用数据
“ Data helps us understand how users use the product, which then in turn helps us understand how to optimize the product. ”
（数据帮助我们了解用户如何使用我们的产品，从而帮助我们更好地优化产品）
Facebook每天会采集到4TB的用户行为数据，这些数据能指导设计持续优化。例如 通过瀑布式分析、追踪交互步骤的转化/流失率，大量的A/B testing，观测行为使用模式 ， 优化界面交互和操作流。
例1：照片上传器的改造
在新照片上传器刚上线时，有85%的用户每次只上传一张照片。针对这一痛点，对界面进行了优化，在用户选中一张照片后浮出了一个上传tips，虽然有点“扰民”，但结果数据每次只上传一张照片的用户数降到40%，平均每次上传数从3上升到11.
同样地，通过数据他们发现，用户在周日量达到平时的150%，这种行为模式的识别也为设计带来不少启示。
例2：What’s on your mind的位移
在推出Question这个产品后，原来的What’s on your mind需要调整位置。于是他们使用A/B testing的方式测试了 8个设计版本，但每个版本对于核心指标的影响都不具有统计意义上的差异，所以最终他们选择了最简洁的一个方案。
例3：注销页的改造
除了瀑布式的分析，数据还会用于回溯性式的分析、优化一些小页面。例如一个设计师发起了注销页的改造，他思考的是如何在用户即将离开之时将其挽回。最终他通过一种情感化设计改造了这个页面（图1），成功将注销率降低了7%，这对于Facebook的用户量来讲是非常了不起的数字（当时Facebook有7千万用户）。
3. 对数据过度利用的警惕
“…at Facebook, in product – we call product “product management and product design” – that there’s a healthy skepticism of being overly data driven ”
演讲者提到数据怀疑论的三个原因：
一组数据指标很难完整地代表你所重视的价值
影响产品决策的因素很多，除了定量数据，还有定性数据。Facebook的用户研究员会做大量定性研究，如可用性测试、眼动测试等。另外还有战略因素，用户需求，竞争产品，商业利益因素。
过度依赖于数据，可能导致“微优化”或“局部最大化”
对数据的变化过度敏感，可能导致所谓的“微优化”(micro-optimization)，即过度着重、不断追求某一项指标的提升，而忽略了其他因素。尤其当Facebook规模不断扩大，各个团队更专一于自己的产品，就可能导致各自只从自己的指标出发，使得整体上出现冲突，没有了全局观。
例如 ，应用菜单的设计几经周折，位置从左边栏换到顶部，又换到底部，由于流量不见大增，还曾考虑使用蓝色大按钮的方案。虽然流量提高了5倍，但由于设计师自己都觉得很难接受，这个方案最终没有被发布。无论如何，直到一年后他们才发现，尽管朝着提高引导到应用的流量这一指标不断优化，却出现停滞不前、达到局部最大化(local maximization)的瓶颈。最终他们成立了一个菜单项目组，推翻之前的重新开始，设计了目前的版本——而这实际上有一半回归到菜单最初的样子。
另一个例子是相片上传器。相片团队花了好几个月朝着提高上传成功率的数字优化， 虽然数字有提升 ， 但成功率已几乎稳定，不可能有什么新的变化了。如果一直围着这个指标打转，体验并不会有质的变化。
真正的创新通常会导致数据的变差 ， 但这未必是坏事
“… real innovation invariably involves disruption. And disruption is usually – involves a dip in metrics ”
