我们平时经常收到App更新推送通知。大部分的数字化服务长至几个月，短至几周进行一次更新，有时候是为了修复bug，有时候是用来测试新技术或新功能。数字化服务总是"悄悄且一点一点地，反复且持续不断地"进化并生存下去。

 更新周期可以视为服务的生命力。Facebook移动应用每月更新两三次。更新后变化其实不大，故意去找往往找不到，只是无意间会发现"咦？这有点不一样？"而已。但如果回头去看更新200次以前的Facebook应用，宛如古代文物。反之则反，如果有一个服务很久没有更新，十有八九已经失去了生命力。

 当然它们不只做小更新。当需要变更或改善整体服务战略时，会以一年为单位长时间进行大规模改版更新。大家应该还记得Instagram在两年前进行了全面改版。从此以后和Facebook一样通过小更新反复测试功能。现已司空见惯的视频头像、以铺瓷砖（tiling）方式显示"搜索"出的视频内容、每次显示新内容的时间线（timeline）逻辑等就是典型的例子。数字化服务不仅要长远发展，还要着眼当前。赛我网（Cyworld）、Freechal、My Space等风靡一时的数字化服务，由于在鼎盛时期长期处在安于现状、不思进取的状态，而且当发现为时已晚的时候做出错误选择的结果，加快了衰落的步伐。

 【瀑布模型（Walterfall）】是传统的数字化服务开发模型，按"制定计划、软件设计、程序编写、软件测试和运行维护"等流程顺序展开，以完全按计划分工为前提。尽管瀑布模型被广泛采用，但在速度和问题应对方面存在诸多严重缺陷，而且开发所需时间很长。正因为此，为方便小企业使用而出现了【敏捷（Agile）】、【精益（Lean）】等软件开发模型。这两种模型将软件项目切分成若干子项目，快速实现商业化后，经过反复测试和修改，逐渐提高完成度。但最大的缺点是提供给用户的软件"处于未完成状态"，因此需要导入整个程序的大型组织和企业就较难套用。

 在此情况下，谷歌提出了【设计冲刺（Design Sprint）】这一全新设计方法。它是为了与150多家初创企业合作，由谷歌风投（Google Ventures）开发的方法，现已为谷歌所有部门所用。运作流程为首先界定要解决的问题，再利用设计来验证解决方法。与精益模型相比，可以说是在服务上市前的设计阶段下了很多功夫。从某种角度上看，和现有的原型（Prototype）模式相似，但最大的区别为设计冲刺方式以一周为单位重复执行，并需要更多利益攸关方的参与。

 谷歌设计冲刺法的理想条件如下：

a. 了解不同技术和拥有不同观点的利益攸关方（开发、营销、设计、管理等）4-5人/决策者1人
b. Understand（理解）> Sketch（草图） > Decide（决定） > Prototype（原型）> Validate（验证）等5个步骤

 其中，人员准备尤为重要。只靠设计师制作的原型，以后在派上用场时需要投入很大的精力。因此需要了解不同技术和拥有不同观点的利益攸关方和决策者参与其中，验证其可行性后再做决定。这样的设计冲刺法才有意义。

 不仅如此，每个步骤要在一天内完成，让全过程控制在一周内。也就是说，与其厘清是非，不如一边向前移动（moving forward）一边验证。要在指定时间内迅速决定点子和最佳方案，如果中间有任何错误或遗漏的，等下一个验证时间进行验证。

 验证结束后，可能会发现看似完美的想法其实不然。如遇到这种情况，不管几次都要回头重试。设计冲刺的关键在于重复验证，而不是成败。重复验证可能会觉得缺乏效率，但相比把一个点子开发成产品时所投入的时间和努力，越早发现错误并加以纠正会越好。

 今年1月，Digital Design Team与谷歌UX首席设计师Jonathan Chung相见，听取了谷歌设计团队的实际工作经验。就我个人而言，最想知道的是如何缩短理论知识和现场实践的距离。他们公司内部曾多次进行过设计冲刺，而且幸好（？）每次都根据实际情况，运用了最适合的方法。总而言之，解决问题时最重要的就是向前移动（moving forward），而且我们的最终目标应该是持续保持数字化服务的生命力。