在产品设计过程中，有种方法叫敏捷开发，叫瀑布流模式；在体验设计中，也有类似的方法——精益体验设计。这篇文章，我们就从这种方法的历史和流程角度，来说说这个方法如何与敏捷开发相结合。
在上一篇文章中，介绍了在软件时代无论是产品的体验设计还是技术研发，其底层的流程管理都是在参照传统制造业生产流程下的瀑布流模式。当然，任何产品研发生产模式都不是完美的，所以也讲述了瀑布流模式的三个缺点。
传统企业我们需要非常详尽的设计，因为我们是有生产环节的，需要实体的销售模式投放市场，这要求设计不能产生半点差错，不然成本会很高。
随着互联网的高速发展，使得用户对于数字化产品的迭代更新速度的预期越来越高，加之软件SaaS化的浪潮席卷而来。数字化产品的速度和灵活性取代精度和可预测性成为极具竞争力的优势。
数字化产品的研发生产不再受制于实体产品的生产流程，可以随时缩短的生产周期要快速适应这瞬息万变的市场，“一次性的完美设计” 已经不再受用。瀑布流的设计研发模式显然在互联网时代已经无法成为主流的数字化产品研发模式，这就迫使企业不断寻找可以替代瀑布流模式的新设计研发流程管理模式。
数字化产品研发流程的主流模式也至此从瀑布流模式进入到敏捷模式，如下图所示。
从瀑布流到敏捷
以快速迭代为核心产品开发思维的——敏捷开发模式，成为互联网时代数字化产品设计研发流程的新宠。
敏捷开发的重点在于快速迭代。它每2-4周发布一套新的可交付的功能，是随着时间的推移对产品进行更新，而不是一次性更新。它是基于假设、实验、快速发布和实时测量而建立的。在敏捷开发中没有编辑阶段，没有尽善尽美。正如Bre Pettis在2009年所说的，每一次迭代完成都是趋向更加完美。
瀑布流式的工作流程需要“测量两次，去掉一次”，这比从到处都是 iPhone 的世界中淘汰诺基亚要更快。
从2001年提出的敏捷开发宣言可以看出，这种开发模式是比较符合工程师文化的。在敏捷开发宣言的指引之下产生了多种多样的敏捷开发方法，如冲刺和迭代式Scrum方法。
一个典型的数字化产品的敏捷开发流程如下图所示，如下图所示。
典型的敏捷开发流程
在敏捷开发大行其道的今天，我这里就不详细介绍这样产品研发流程细节。只是在这样一种主流的产品开发流程中，发现了一个小问题：
“对于2周一迭代的产品发布周期，体验设计团队几乎没有时间去执行他们传统的设计流程。在敏捷研发流程中，体验设计变成了一个绊脚石。”
面对不能改变的阻碍，大多数产品研发团队会简单地放弃用户体验。取而代之的是，他们雇用了能够在两周内快速交付的年轻平面设计师。这些设计师并不是真正的用户体验从业者，至少不是传统意义上的，但他们对于以用户为中心的设计是有基本认知的，至少能避免犯最糟糕的错误。
或者是选择使用设计外包，因为设计外包中的设计师一般都是优先满足开发需要，成为团队里面的编外“美工”。
这种情况与产品开发团队也可以合作顺利。
敏捷假设的前提是Product Backlog（待开发事项）是已经清晰定义的需求，大部分敏捷开发实践中更关注快速迭代的环节，而忽视用户故事、需求分析、设计规范；快速的迭代时间使得用户体验设计师没有时间深入思考、执行体验设计过程；敏捷认为细节将通过迭代自行解决，现状是细节从未被解决，如下图所示。
在敏捷开发中被忽略的部分
敏捷开发终究是一种开发方法，并不利于体验设计师的工作。
精益创业是一种发展商业模式与开发产品的方法，由埃里克·莱斯在2011年首次提出。根据埃里克·莱斯之前在数个美国新创公司的工作经验，他认为新创团队可以借由整合「以实验验证商业假设」、「快速更新、迭代产品」、以及他所提出的最简可行产品（简称MVP）及「验证式学习」，来缩短他们的产品开发周期。
精益创业方法论产生的背景是根据统计，在全球范围内创业公司失败率高达90%，其中排在第一位的原因是找不到市场：“没有人需要他们做出来的产品”。
精益创业的方法早在上世纪90年代的硅谷就已经崭露头角。但是精益（lean）这个词最早可以追溯到丰田的精益生产理论。丰田的精益生产理论是为了高效生产商品，但没有回答应该产生什么商品的问题。
精益体验设计是 Jeff Gothelf 通过精益创业方法论，试图解决UX在敏捷中实践存在的问题。让UX能够在敏捷开发略渐清晰的流程里，基于用户的反馈快速迭代设计。
什么是精益体验设计？ 使用协作、跨职能合作的方式，不依赖完备的文档，强调让整个团队对真实产品体验达成共识，从而尽快把产品的本质表现出来，如下图所示。
精益体验设计流程
首先了解一下经验证认知的基本单元–精益循环。我们建立假设，并根据假设建立一个“待验证假设”，随即对它进行定量评估获得测试数据，这些数据包含了终端用户对于”待验证假设”的认知及价值衡量，通过数据学习验证其是否正确，如果答案肯定，开发过程向前推进；如果答案否定，则返回假设原点，修正假设后再次循环直到“待验证假设”肯定，这就是一个循环。
传统的设计是基于需求的，而精益体验设计是基于成果的。
可以看出，Lean UX强调了快速设计，快速用户反馈与迭代。通过精益体验设计流程，让体验设计团队很好的融入到敏捷开发流程中，如下图所示。
精益体验设计与敏捷开发流程
似乎通过精益体验设计流程，体验设计现在能够很好的与敏捷的节奏相协调，成为其流程的一部分，推动产品的快速开发迭代。
然而，在实际的项目推进中，体验设计发现了新的问题。设计师发现在他们真正了解正在构建的东西之前，自己要承受巨大的压力去做一堆在冲刺中积压的工作。因此，大量的开发周期都被这些根本无法成为最终产品一部分的功能所消耗。以至于在项目管理界，精益体验设计或者敏捷开发在不理想的条件下的尝试，是以大量浪费和返工而闻名的。
在一个成熟的产品中，可以搜集到大量的用户反馈，这对推动精益用户体验的迭代周期起到了很好的作用。这就是为什么精益用户体验几乎是所有已建立的产品团队的行业标准。没有人会去改变它。
但是，在大量的创业公司中，特别是从0到1设计开发一款全新产品的时候，但新产品的定义往往不是那么清晰，相对有点模糊，且无法得到大量有效的用户反馈的时候，精益体验设计流程就会崩溃。
所以，对于很多创意公司的体验设计团队来说，精益体验设计流程并不是一个很好的选择，我们需要对体验设计流程继续探索新的设计流程，以便更好适应创业公司对于敏捷的产品研发模式的需要。
对于创业公司来说，因为规模和投资等因素，设计开发资源是宝贵的，我们必须要把“好钢用在刀刃上”。建立一套新的敏捷的体验设计流程，用于提高数字化产品的研发效率和响应速度。设计师面临一种窘境。谷歌风投创建了设计冲刺流程（Design Sprint）一种在5天内回答关键业务问题的过程。设计冲刺是一个高度结构化的创新周期，在这个周期内，团队回答特定问题，确保始终以用户为中心。在做出任何昂贵承诺之前，无需等待发布最小化产品，设计冲刺就可以帮助你了解一个想法是否是好的，如下图所示。
体验设计冲刺的敏捷性
设计冲刺为团队提供了一条学习的捷径，无需开发和发布。那么一个典型的体验设计冲刺流程是以5天为一个项目节点，强调在跨团队的五天封闭式共创工作中完成方案设计和验证，用最少的资源，最快的速度提高产品在投入市场中的成功率，如下图所示。
典型的设计冲刺流程及活动
看到这个设计流程图，你也许会说“这个和我们传统的设计流程一样啊，只不过这个设计流程只给了五天的时长！”，那么你就差不多答对了。它的不同，或者说天才的部分就在于它就是一个低保真度的传统用户体验流程，就像艺术杰作和简单素描的区别，但它却很有效。
设计冲刺的目标就是收集目前所有关于问题的调研，将它的核心分成多个群组，并疯狂地进行头脑风暴。头脑风暴是透过以人为中心设计的透镜进行筛选，而这些被团队所投的想法将留存下来。设计师接着搭建低保真原型（往往就一天的时间），这原型也足够能够用去测试潜在的用户。如果测试的结果不错的话，它能帮助设计师搭建高保真的模型，因此来驱动精益设计/敏捷的循环流程。
设计冲刺侧重于设计构思和验证，是日常例行工作之外的特殊工作状态。设计冲刺的输出将作为开发团队的输入，并不涉及开发流程的变化。
设计冲刺不主张传统开放式的头脑风暴，认为集体讨论的模式无法深入思考且效率低下，其更主张独立思考绘制草图后再混合修改调整。
然而随着互联网时代敏捷模式在企业中的不断发展，越来越多的开发人员、体验设计师对当前敏捷模式的产品设计研发流程提出了质疑，其中最大质疑就是：
敏捷开发流程真的可以确保向客户交付的产品具备卓越体验吗？
该系列文章的最后一篇，会给大家介绍当前敏捷开发面临的挑战，在后敏捷开发时代，体验设计流程的应对之策。
作者：井然，公众号：井然聊体验
本文由 @井然 原创发布于人人都是产品经理。未经作者许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。