不知道大家在工作过程中有没有碰到过以下这几种情况：团队筋疲力尽，却发现做出来的东西有一大半都没达到预期效果；看不清前景，可做的事情很多，但团队始终无法达成一致；想验证某些关键假设，但时间、资金、人手都远远不够；现有产品增长遭遇瓶颈，想寻求二次创新却很迷茫。这篇文章，能帮到你。
很多时候，我们辛苦工作几个月却做了一个没人需要也不会投产的产品。从结果上来看，这几个月的时间白白地被浪费了。
既然如此，为什么我们不选择一个能快速检验的方式，在原型阶段用5天甚至更少的时间试试呢？
这种通过原型快速验证产品方案的方法叫设计冲刺（这一方法出自《设计冲刺：谷歌风投如何5天完成产品迭代》一书，以下简称《设计冲刺》）。下图简单明了地解释了这个方法。
设计冲刺的逻辑
图片来源：《设计冲刺：谷歌风投如何5天完成产品迭代》
设计冲刺分为“理解领域、聚焦方向、发散解法、选择解法、制作原型、用户测试”六步。它是谷歌创投基于Design Thinking的启发而提出的方法，如下图所示。
设计冲刺的六步骤
这套由谷歌创投总结出来的产品创新方法论，已经经过了实践检验，助推过很多公司和产品，比如Uber、Lime、Slack、One Medical Group、Nest、Flatiron Health、Duo Security等。
《设计冲刺》中对“设计”这一概念的定义很广泛。搜索引擎、电子邮箱、无人驾驶汽车是“设计”，优化产品、制定营销策略是“设计”，为公司命名、评估新商机的可行性也是“设计”。
那么，设计冲刺能干什么？
《设计冲刺》一书的英文副书名——“How to Solve Big Problems and Test New Ideas in Just 5 Days”（如何在短短5天内解决重大问题并测试新想法）就很准确地阐释了它的价值。
所以，我们也可以这样理解：这是一套适用于“现有产品碰到大瓶颈”或“打算启动一个新产品”情况下的方法论。
虽然书上写的标准做法是5天，实际上很少有团队真的能下决心花5天时间来完成这件事。
因为这套方法虽然严谨，但一些公司可能因为某些因素的限制无法完美地执行，比如公司可能凑不齐一群“合适”的人来执行这一整套任务。最终有可能什么结果都得不到。
你可能会问，既然很少有公司能真正落地这个方法，那学习它有意义吗？谷歌真的在用这套方法吗？
我的回答是，有意义，而且谷歌真的在用。
我和至少5位在谷歌工作的朋友聊过，他们表示公司确实在用“设计冲刺”。所以，它并不是一个摆设。而且，谷歌内部有5天冲刺的做法，也有时间更短的做法。
我和一些咨询客户也展开过短期尝试，我可以很有信心地说，哪怕只有2天、1天，甚至半天，即使能简单尝试一下里面的一些做法，也会大有收获。
设计冲刺开始之前我们要先做一些准备，实际的执行环节分为六大步骤。我本人在给客户做“产品创新工作坊”的时候，也借鉴了很多设计冲刺的理念和做法。
下面我会结合自己的实践经验为大家讲述“设计冲刺”，并且会挑出可落地实操的步骤着重讲解。
01、可落地实操的步骤
1、准备阶段
首先，我们要做些准备工作，明确好“设计冲刺”要解决的问题、参与团队、时间地点，以及一些产品理念。
2、识别挑战
设计冲刺要解决的问题应该是当前急需解决的，且问题的颗粒度需要和投入的时间、资源相匹配。
如果问题的颗粒度太大，比如未来5年的产品规划，这类一时半会搞不定的问题不适合运用“设计冲刺”的方法。如果问题颗粒度太小，比如产品内文案的风格统一，这类问题又不值得专门进行一次冲刺。
3、组建团队
团队组建方面，我们需要先确定一名真实的决策者，他在过程中的决定就代表了公司最终的决定，不会再被其他人推翻。
然后，我们还要再确定一名引导者，他是熟悉设计冲刺方法的人，在整个设计冲刺的过程中可以根据实际情况对方法做“剪裁”，以保证最高效的产出。
最后，我们要确定多样化的团队成员。团队成员可以来自公司内部，也可以来自公司外部。他们是解决特定问题需要的各方面的专家。
4、确定时间、地点
根据实际情况，我们要决定到底投入多少时间来做设计冲刺。同时，我们也要找到合适的工作空间。
设计冲刺工作的地点，应该与日常工作场所隔开。它可以是公司内不受打搅的会议室，也可以是宾馆里租用的房间，但最好是用户场景下的空间。
比如做校园产品的设计冲刺，有条件的话，我们可以去目标学校租借一间合适的教室。
5、达成共识
最后的准备工作，我们需要和参与的团队达成一些理念的共识。
这是一次真实的产品探索，不是实战类的培训，所以我们需要有利益相关方的介入，比如各种真实用户、合作伙伴，而不能由着产品团队闭门造车。
在有限的时间内，我们更应该尽可能多地排除多余的选项，找到有价值的选项。另外，良好的工作空间布置也能对我们的工作起到很好的促进作用。
确定合适的问题、挑选正确的成员、建立民主的氛围，这些良好的准备是成功的一大半。准备完毕之后，我们就可以正式开始了。具体步骤：
第一步：理解领域
一开始，团队专家会通过共享已有的重要信息，设定这次冲刺的目标。一个好的目标是整个冲刺过程的灯塔，比如我们把目标设定为“让初次网购的用户可以拥有一次顺畅的网购体验”。
接下来，团队需要列出所有可能会遇到的阻碍，在“网购场景”的例子中，阻碍可能是“如何顺畅地注册”、“如何成功完成支付”、“如何解决信任问题”等。
第二步：聚焦方向
接下来，我们可以请冲刺团队的专家来集中讨论一下列出的所有阻碍，并且确定本次冲刺要重点突破的一个阻碍。
注意，这个选择一定要得到决策者的确认。
第三步：发散解法
然后，我们要从问题领域转移到解决方案领域。团队的每个人都要贡献点子，然后用各种各样的集体协同创作的方式，在已有点子和灵感的基础上提出更好的点子，并且把部分好点子落在纸面上，做出详细的方案。
第四步：选择解法
到了第四步，我们要在为数不多的好点子中选出最佳方案。这时候我们可以用一些引导技术来进行集体决策，比如采用投票的方式。这里的重要决定也需要决策者的确认。
第五步：制作原型
选出最佳解法后，我们就要开始用各种方式制作产品原型了，此时我们可以利用上一节里的七种原型，选取合适的做法。
第六步：用户测试
这是最关键的一步，反而往往容易被忽略。
很多公司在做出原型之后，只是经过内部评审就继续推进项目了。殊不知，此时是让真实用户对解决方案给予反馈的最佳时机。
我们都知道，在任何产品研发的流程中，改动越早成本越低，而原型是解决方案最早的表现形式。
做出原型后，我们需要找到少量的真实用户去采集他们的意见。
对于很多时间不足的企业，我也会建议他们至少基于现有的产品，进行第六步的用户测试，通常他们都可以收集到很多有价值的反馈。
比如用户找不到按钮、看不懂文案提示、露出困惑的表情，等等。总体而言，用户测试可以扫除团队的盲目自信、发现隐藏问题。
设计冲刺的整个过程，其实就是从问题到解决方案的过程：先是问题的发散与收敛，再是解决方案的发散与收敛。英国设计协会有一个类似且十分形象的抽象模型，名为“双钻模型”，如下图所示，你也可以扩展了解。
设计领域的“双钻模型”
02、类似方法论的辨析
上文提及的设计冲刺和双钻模型，如果我们了解过相关的概念、方法论，可能会有个疑惑——这些内容和已有的一些产品经理工作方法十分相似。
所以，我想在扩展话题中和大家聊聊其他一些相似的方法论，帮大家做个辨析。
第一类是精益管理，它源自精益生产的概念，旨在及时制造，消灭故障，消除一切浪费，向零缺陷、零库存进军，常见的扩展工作方法有精益创业、精益UX专注于设计体验，与传统UX相比，它对可交付成果关注更少，需要整个团队更好地合作，核心目的在于更快地获得更好的回馈，从而快速决策等。
第二类是敏捷工作法，它是一种以人为核心进行迭代、循序渐进的做事方法。具体的方法有Scrum、XP，是一门针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上等。
第三类是设计思维，它是一套探索创新的方法论系统，包含了触发创意的方法。它也是设计冲刺的来源。
第四类是双轨开发，它是一种比较新的提法，双轨的意思是一个“轨”负责想法和设计，一个“轨”负责研发实现，这个概念源自“敏捷工作法”，不过正式被提出是在2018年。
这几个概念都有强调试错、小步快跑、尽早发布、尽快获取反馈、真实用户参与、学习闭环、迭代发展等特点。经过研究，我发现它们其实可以用产出物和所处的领域阶段进行区分，下面我把自己的理解分享一下。
第一个理解角度，看它们的产出物是不是真实产品。
敏捷工作法的产出物显然是真实产品，因为它的方法论里有很多是关乎开发（测试）的硬性内容，每次的产出物常被叫作最小可行产品。精益管理的场景也主要发生在有真实产品的生产过程中。设计冲刺则不同，它是某种可用于验证假设的原型。而双轨开发的一个“轨”是做“原型开发”，另一个“轨”是做真产品，即“产品开发”。
第二个理解角度，看它们各自的适用领域和阶段。
各个方法论“出身”的不同，导致它们各自有更适用的领域。设计思维源自著名设计公司IDEO和斯坦福的设计学院，后来被谷歌创投改造为设计冲刺，更加贴近实际的产品工作，它适用于相对早期的设计环节。
“双钻模型”也同样更适合设计领域。敏捷工作法来自软件开发领域，故而更适用于把设计“做出来”的开发阶段。精益管理源自丰田的生产方式，它是要把做出来的东西规模化，所以和“推出去”阶段比较匹配。双轨开发是针对跨阶段的工作方法，它的一个“轨”在“想清楚”上，另一个“轨”在“做出来”上，我们可以将其理解成是设计冲刺加敏捷工作法的合体产物。
所以，从一个商业产品从无到有的逻辑来看，设计思维、敏捷工作法、精益管理依次对应了“想清楚、做出来、推出去（规模化）”三个不同阶段，根据产出物的不同，它们的区别如下图所示。
各种方法论的对比
03、小结
全社会的各种产业正在以越来越短的变化周期来适应加速的商业环境，各种方法论支撑的原型设计方法的基础逻辑大多都是用粗糙的原型去获取真实用户的反馈，然后互相学习、改进。如此循环往复，才能打磨出优秀的产品。
