极致用户体验成就伟大的产品

　　你从来不会因为产品功能而赢得用户，但他们会因体验慕名而来。
　　基于这样一个背景，你需要重新考虑你的产品设计——摒弃罗列功能清单，选择通过满足用户需求去迎合商业目标，通过定义用户体验去吸引目标用户并驱使他们行动起来。同时，你要时刻准备好从真实使用场景中学习，根据需求不断调试你的产品；以保证能够锁定、维持和增加你的客户群。
　　如果你试图在产品上增加一些功能以确保它是＂完整的＂，或者希望产品能够覆盖更多的极端情况；那就只能推迟进入真实使用环节，你也就会很晚才能了解是什么影响了用户的参与度、行动力，以及产品与商业结果的相关度。
　　产品的发布是了解产品体验的重要机会，因为这将基于真实的用户反馈，而不是模糊的人口学特征或者由众多人物角色而形成的假想用户。这就是为什么你的产品通过最小可行产品（MVP）尽快占领未来市场是非常重要的。
　　快速进入市场
　　有时候，是一些与众不同让产品从市场中脱颖而出。Foursquare是一个很好的例子。他们花了近两年专注于普及游戏化模式，这也确实迅速普及开来，但它的吸引力并不足以维系自家的核心产品；或依靠这个核心产品盈利，产生长期价值。因此，他们把目标转向专注于本地搜索。
　　Foursquare的例子说明为什么快速进入市场，在市场中测试之前的假设是如此之重要，他们花了两年的时间在无谓的探索上，这两年时间原本可以用来秒杀最相似的产品，但事实上花费了数百万美金的投资后也没能盈利。
　　一个更好的说明MVP策略的有趣的例子是Hyperlapse，由Instagram/ Facebook前不久发布。
　　当你打开这个app，你会被邀请开始录制视频。当完成录制，你可以设置2倍到12倍于原始视频的速度。当你选择了一个速度，加速的视频会保存到你的相机胶卷，然后你可以分享到Instagram或Facebook上；以上就是这个app的全部了。没有帐户设置，app中也没有文件管理，你无法查看任何之前保存的视频。只能拍摄一次，一旦选择保存，就无法改变视频速度设置。所有你能做的，就只有拍摄、设置速度和分享视频。
　　＂没有这些功能，我们就不能发布＂
　　大多数公司会说，＂没有这些功能我们就不能发布产品。＂简单想一下，一款类似Hyperlapse的产品可能真正需要的两个额外的功能是：文件管理和视频编辑。要做到这两点，你需要考虑用户将如何访问这些功能入口（导航或屏幕上的控件），设计每一屏的内容，开发实现这些功能（包括文件系统访问和接入支持编辑复杂视频的API），最后你还需要测试和发布的产品。
　　与现在的app相比，它需要多花掉四倍的时间进行界面设计，多花掉六倍的时间完成开发工作。并且这还不考虑由于复杂的工作而引起的开发问题和一些意外情况的出现。在每一种情况下，稳妥的实现这些新功能都需要时间。这意味着该产品会在若干个月后才能推向市场。如果这个过程中没有人一直推进它，那结果会怎样呢；又或者最后如果产品不能盈利，那又会怎样呢？
　　因此，如果你的MVP很晚才推向市场，你可能会错过很多宝贵的用户回馈，被很多无关紧要的功能所拖累；或者更糟的是，基于此，你得到一个错误的假设。
　　设计一个答案机
　　对新产品来说，你总是站在对用户的猜测和用户真实行为的十字路口上。你在努力抓住新的市场机遇的同时，也要处理变化的目标需求和一大堆额外的未知状况。这些你带到MVP中的假设和未知会创造更多额外的变数。额外的变数会让验证假设变得更加困难。但如果不能有效地验证你的假设，你就不能收集有助于重新定义产品的有用的数据。
　　＂你的MVP就是解决问题的答案机。＂
　　MVP的目的就是在产品下一个开发阶段前减少无谓的假设和不确定性。换句话说，MVP就是一个将问题变为答案的机器。
　　产品的核心体验
　　显而易见，产品发布前，你设计的越多，能推向市场的时间就越久。可惜遗憾的是，缺乏市场信息的参照，你设计的越多，可能越难专注于目标用户。这一切只因你不可避免的过多关注在产品的功能集合上，而那些功能集合又基于不断发展的未被证明的假设上。这一切就好像缺乏任何照片参考，却要拼凑一个巨大的拼图。
　　相反，你需要把重点放在目标用户的核心体验上。从产品的外延到产品的核心一层层抽丝剥茧，寻找一个你的产品能够帮目标用户完成的，不可替代的任务。尽快把产品交到目标用户的手上，看看他们是如何回应的。
　　如果你不专注于核心体验上，而是创造一个宽泛浅显的产品，你会发现你的用户会在这个产品里感到迷失、困惑、无聊、以至于想要放弃。更重要的是，你找不到那些没了你的伟大的产品就活不下去的激情用户，因此你就找不到那份吸引力。
　　太多的＂但是＂
　　典型的产品设计过程中有一些内在的阻力，往往造成MVP实际上没有展现出速度，专注，高效，和洞察力等重要价值。进入市场前，你总能找到很多理由去做的更多，但是这些理由都不是在传达＂你必须创造一个伟大的产品＂。所以我们不妨来看看这些内在阻力，以及它们是如何导致产品失败的。
　　有三个原因可能会阻碍创造出一个有价值的MVP，如果你从一个产品经理这里听到这个，他或许会用外交官般官方的方式来谈论臃肿的MVP的负面影响，而不是集中于MVP上。
　　如果你是一个产品经理，我们也希望你能多考虑用户使用你的MVP的体验，这是可以优化的最重要因素。不以这个为目标意味着你将面临比MVP的开发预算更大的危险。
　　＂但是＂1：我需要从MVP中得到更多地价值
　　作为一个企业业主或支票签署人，尝试让MVP比实际需要多出一些功能是很有吸引力的。如果你信奉功能越多价值越高的话，越来越多的功能可能会让你觉得它传递了更多地价值。但更多的功能其实仅仅意味着更多地工作，且往往会导致产品体验变差，进而降低价值。
　　这类似于你用一辆车的车轮的数量来界定一辆车的价值，六个轮的就一定比四个轮的好。这当然不是一个合理的论据，增加MVP的功能数量也不是，因为功能并不等同于体验。事实上，越多的功能可能会导致让体验变得复杂和令人费解。额外的功能往往会带来负面效应，让产品随着开发、维护和投入资金的增加而变得越来越难用。
　　换句话说，MVP的功能数量并不草率的与MVP的价值相关，增加MVP的功能将会让你迟迟不能开始做一些关键的事。比如：
　　·验证假设
　　·提供有关用户和市场偏好的数据
　　·向用户传递产品的核心体验
　　如果你想优化产品，找到产品的激情用户会比较快达到这一目标，而不是增加产品的功能。
　　＂但是＂2：＂我们需要覆盖所有的用户情况，不然就会有疏离用户的危险＂
　　现在就丢掉这个观点吧，你根本不可能覆盖所有的用户情况。功能丰富的产品历经成千上万的开发者和几十年的发展，但是仍然无法覆盖所有的用户情况。追求全覆盖面真的很傻，也会让一切越来越糟，因为它让你分神而不能集中于核心用户体验，更糟糕的是，它迫使你忽视你的核心用户。
　　以微软的Office软件为例，Office在微软是营收仅次于Windows系统的第二大支柱，但是现在谷歌的Docs和太多别的书写工具正威胁到Office的地位。Office其实使用起来并没有那么快、跨平台使用也没有那么方便，它也没有它的竞争产品那样操作简单。这些竞争产品都集中在核心的书写功能上，而不是开发很多的仅仅吸引高级用户的功能。
　　让我们假设大多数的Word的用户只使用的5％的产品功能。这意味着，任何一家只要将那5%做得更好的公司，都比Word有令人信服的优势。构建一个满足很多极端情况和高级用户需求的MVP可能要多花4倍的设计投入和6倍的开发投入，况且多加的功能反倒会让用户界面变得混乱，因为页面上多了很多不相关的信息，用户在达到目的之前，需要过滤的信息也就更多了。
　　因此，它不仅仅大幅度增加的产品开发工作，也大大的增加了用户的认知成本，用户每次都要先想好为了完成他们想完成的任务，他们要怎么做。归根结底，为大宗用户，使用Microsoft Word进行日常写作任务包含了太多的无用信息，太多的选择，太多的分心，过多的困难。最好的情况是，用户直接忽略了大多数他们从来不使用的功能；最坏的情况是，他们一次又一次的盲目点击，却无法找到他们想找到的。虽然Word是一个成熟的产品，而不是MVP，但是对最大化产品的功能列表的后果而言，这是一个绝佳的例子。
　　所以，跟我一起再重复一遍：你不能覆盖所有的情况。现在开始，回归专注于体验。
　　但是3：＂我们需要在产品发布前就做完这个产品＂
　　对于创造一个成功的MVP而言，＂完成＂的概念通常是一种常见的障碍。
　　这种拖延往往来自销售或营销的利益相关者，他们担心真实的MVP（以加速产品上市进程、并收集有用数据的优化）是不完整的。这种担心来源于他们对两个问题的错误认知，是什么创造了无与伦比的产品体验？怎样能在用户使用产品的过程中，降低人与产品的摩擦？
　　更多的功能，或者更完整的功能列表从来都不能导向一个更愉悦的体验；只有真正的集中于产品的核心体验才可以。这意味着你所有的资源都应该集中于计划、设计、开发和传播一个非常精心制作的核心体验。这才是一项庞大的事业。为了让产品变完整，你所做的所有多余的努力其实只会导致延期和假设的叠加，在产品和目标之前也会产生一种隔阂。实际上，你的产品永远不会完成。当你从你的每一位用户身上学到些什么的时候，当商业规则和市场情况都在改变时，你的产品需要去基于当下的情况解决哪些问题。你越早开始学习和适应，你越有可能会成功。
　　你的MVP可能需要去掉更多的功能
　　你的MVP可能需要删减掉一些功能，它会从两方面提升你的产品：
　　·推向市场的时间
　　·预算
　　请记住，每一个功能的背后，是成倍的更多的工作，因为它需要多个利益相关者有所投入，包括：
　　·内容
　　·设计
　　·工程
　　·测试
　　·维护
　　·法律
　　当你要给你的产品增加一个功能点的时候，多想想这个吧。
　　专注于体验
　　上市时间和预算都不是削减MVP的最佳理由，反倒增加了一定要做MVP的理由。每一个利益相关者所做的任何努力，都应该从产品核心体验的角度出发。从产品立项到发布，以及其中的每一次迭代，都将可用资源充分集中于核心体验上。
　　无论你是想增加功能或者做一些界面上的改动，你都应该不断地去了解你的用户做出了怎样的回应，他们从中收获了什么，以及他们是怎样使用这个产品的。