Facebook如何利用数据指导设计

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