设计敏捷方法 （Design Sprint Method）是由 Google 提出，且于内部实践并受到欢迎。它的概念基础来自于其他已经在产业界应用的方法，例如敏捷开发（Agile）、设计思考（Design Thinking）与革新游戏法（gamestorming）。这个方法试图让每个设计团队都能轻易的导入，且能于 2~5 天内解决设计挑战或测试设计原型。
本文介绍的内容整理于 Google 在 2015 年公开的电子工具书 – “Design Sprint Methods“，这本书简述这个方法中的角色、功效、时间、工具与流程等项目，不过 Google 也指出他们的目的，并非要求大家一定得按表操课，而是鼓励或激励新创或任何规模公司的设计团队，能发展出更有趣、多产且能适应的变通方法。好吧！废话不多说，以下就让大舌头来导读吧～
设计敏捷方法 初探
团队成员
Google 建议的团队人数约 5~8 人，其中包含设计师、工程师、产品经理或相关领域专家（如图中的团队即有两位设计师、一位工程师、一位原型设计师、一位 Sprint Master 与一位研究员）。若团队人数超过这个建议值，可拆成数个较少人的团队。并依组织或企业的目标，让不同团队面对相同或相异的挑战。
对团队的成员构成有初步认识后，我们暂不描述这套方法怎么运作，而是介绍其中决定专案成败的重要角色 – Sprint Master 之能力、职责与事项等。
谁是 Sprint Master？她／ 他要做什么？
基本上，Sprint Master 就是整个团队的领导者，他们的背景通常是 UX 研究员或设计师，且需要对设计流程、UX 方法论、策略、激励指导团队技巧与谈判有深度的瞭解。他们最大的任务即是：1）定义设计的挑战为何、2）建构团队及 3）带领团队跑完整个流程。
“Sprint"是整个流程相当重要的名词，它指的是解决一次设计挑战的跌代流程，若要更深入了解可参考敏捷开发的文章
在进行 Sprint 的前中后，Sprint Master 都有不同的事情需要做，该花的时间也不太一样，我们就由下图来说明：
Sprint 前
Sprint Master 在此时做的事情相当关键。首先，他必须定义好这次设计的挑战为何？以及工作时程。再来，他必须建构团队，并用 lightning talks 的方式向成员说明任务与使用者资料，并安排好后续测试的相关细节。另外，若能淮备好环境，将会让 Sprint 进行的更顺畅，例如一张大桌子（facilitator’s desk）与讨论的空间。
Sprint 中
在 Sprint 开始后，Sprint Master 将扮演促进者（facilitator）的角色，像是掌握时间或节奏、让每个人都能参与、指派、给予方向、减少沟通摩擦、每日工作检查、每日发出总结信件与鼓励讚扬等。有时候议题可能会因为讨论而有了新的方向，此时 Sprint Master 也必须快速做出决策，与统合大家的目标。
Sprint 后
当 Sprint 结束后，Sprint Master 须保持带起来的热情与衝劲继续下一个计画，并将这次 Sprint 的结果纪录并分享给所有成员，并藉由此次的经验让下次的 Sprint 更好。
Sprint 前的淮备事项
在开始 Sprint 前，Sprint Master 要设定或选择好团队将要面临的挑战为何。首先要简单明确的呈述挑战的目标，并告知该专注于哪个族群，下方举个例子：
针对 4~7 岁孩童设计直觉的平板阅读体验，并在第四季推出。团队需产出 mockup 及可点击的 prototype 供测试。
接著，召开一场与相关权益人的会议，Sprint Master 能从中判断与学习是否选择了对的挑战目标，考量因素包含：1）访谈相关权益人、2）参考现有资料、 3）参考相关的使用者研究报告、4）分析近期相关设计与5）参考使用者案例。
准备好环境、设备与工具
Sprint Master 需将任务时程表规划好，同时选择好要应用的方法，例如本书提供的或任何适合的方法。另外，安排一个大桌子，它能在整个 Sprint 过程中起了 “激励讨论" 的效用，当然还会需要一些简单但有用的小工具，例如：剪刀、纸、胶带、便利贴、投票贴纸、计时器或响铃等。最后，若能贴心的准备小点心和咖啡的话，那就更完美了！
进行 Sprint 的流程
跑一个 Sprint 有六个阶段，类似 IDEO 提出的 Design Thinking 方法论，简述如下：
1.理清与了解（Understand）
使用者需求为何？商业需求为何？技术可行性？
2. 定义（Define）
决定关键的策略与应该关注于何者？
3. 发想（Diverge）
如何探索更多的想法？
4. 定案（Decide）
选择目前最佳概念
5. 原型（Prototype）
做出概念的原型给使用者测试
6. 验证（Validate）
向使用者、相关权益人与技术专家验证概念
每个阶段都含有许多实践的方法，例如使用者访谈、竞争者分析或技术分析等。但我们不需要把所有的方法都用上，选择适合且正确的即可，甚至根据经验修改或调整过去的方法也行的！
STEP 1. 理清与了解
360 度（全面） lightning talks
这阶段最重要的目的，就是提供不同的观点来了解问题。这场会议应该包含下述的内容，此外顾名思义， lighting talks 就是要简短扼要，不用花太多时间。
1、商业上的目标与判定是否成功的指标／5 分钟
2、技术可行性与可能面临的挑战／5 分钟3、相关的使用者研究／5 分钟
竞争者分析
研究 3-10 个相似的产品或服务，列出喜欢或不喜欢的点，这方法可让我们更快进入状况也能产生更多灵感。
使用者访谈
我们都知道使用者会是最后使用与评价产品的人，所以这就是为什麽在 Sprint 开始前必须进行此步骤。如果是产品或服务已存在，我们可以问他们会如何使用，对他们的评价是如何；若是一项全新的产品，那我们要更专注于了解使用者觉得哪种解决方式比较好。
田野调查
有时候，访谈使用者不如直接走入他们的工作或操作的环境中来的有用，不但可以了解整个体验脉络，也可由中带回最不失真的访谈。
相关权益人图表
产品与服务的设计其实不只要关心使用者，所有相关权益人的需求都须考虑进来。我们可以尝试在 30 分钟内绘製出相关权益人图表：
1、首先，陈列所有可能的权益人／10分钟
2、将这些权益人分组／2 分钟
3、决定哪些权益人是你在这次 Sprint 的设计对象
4、了解他们的需求
总结学到的资讯并尝试提出想法
在大家消化前述提到的资讯后，尝试分享自己的洞见与初步的想法，将它表达于便利贴上。接著，将这些概念分组，并利用小贴纸投票来选出觉得好的概念。不过，最后选出的概念并非一定要往这个方向进行设计，团队还是可在之后的步骤中，因学习、讨论或发现而改变或优化。
STEP 2. 定义
使用者旅程（user journey）
此我们可以透过展开使用者旅程，列出使用者从发现产品或服务、初次体验、再使用及变的熟练的过程，来整理与分类概念，并定义之后设计的策略。
定义设计原则
定义设计原则的方法很简单，让团队列出认为或希望使用者怎麽描述产品或服务的形容词，并选出其中最符合的三个。在 Sprint 结束后，你可以请使用者在体验完 prototype 后说出三个词彙来比较当初设定的设计原则目标。
想像发布时的第一则社群讯息
以 Twitter 来举例，团队可以想像当产品或服务首次推出时，你会怎麽发出一则贴文。这个方法可以协助团队在少量文字下表达策略。
STEP 3. 发想
5 分钟想 8 个概念
这个概念来自于革新游戏法（gamestorming），是一个暖身的练习方式。每个人都发一张纸，并对摺三次，展开后就有八个区域，接著花 5 分钟在这八个区域上画上一些想法。
5 分钟画出一个较好的概念
接续上个练习，花 5 分钟将比较喜欢的一个概念，较精细的画在一张纸上。
5 分钟画出故事情境图（storyboard）
若概念较複杂不容易表达，我们就可以考虑用故事流程的方式陈述。团队成员可选出使用者体验的 “关键" 情境将它简易的画在分镜中。（若您的团队成员对这个方法感到陌生，可以告诉他们就像画漫画般）
STEP 4. 定案
静默投票（Zen voting）
在快速绘製概念后，大家可以将纸贴于板子上，全部看完后进行投票，但规定不能出声。不能出声的用意在于，避免因说服或说明后，而影响最初的个人想法。
团队讨论并决定以哪个概念做出原型
团队可以开始讨论哪一项概念是最好的，并决定往下做出原型。此步骤不需要再进行概念发想的动作，例如草图或探索。
思考帽（Thinking hats）
如果团队经验较少或开始对意见有所偏颇或分歧，可以进行思考帽（Thinking hats）这个方法。让每个成员扮演不同的角色（类似扣帽子的意思，如上图），并模拟该角色的想法来表达观点。这样的做法的目的在于，让讨论更加多元全面。
上图中的案例中就有五种角色，如：点子王、乐观主义者、悲观者、技术专家与使用者专家。
注：此方法是由 Edward De Bone 于 1980 提出，大家可参考这本书 – 六项思考帽。
STEP 5. 原型
原型大家应该都清楚知道，它能让使用者足以真的感受到有这样的产品或服务存在，这样才能得到较不失真的回馈。同时，此书也建议可以花多一点时间在这个步骤中。
STEP 6. 验证
使用者测试
透过原型进行使用者测试最大的目的，即是快速得到有价值的洞见。以下提供几个简单的问题供参考：
2、他们觉得可如何改进？
3、这个解决方案是否能满足他们所有的需求？
概念要持续发展下去，关键的权益人掌握了决定权与资源，例如 CEO。所以他们的确认相当重要，是迈向成功的必要元素。
技术可行性确认
确认这个概念所需要的技术是否超过团队的能力，邀请技术专家评估与讨论，可让后续发展更具可行度。
感想
其实这样的说法，我不否认，但重点应该视这些思维、流程、方法与工具为参考或激发的手段，毕竟团队中具有精准洞悉与产出对的创意的人太少，而依靠个人创意所带来的风险也非常大。因此，不需要对这些创意思考的模式与方法嗤之以鼻（例如设计思考、UX 流程等），这些方法尝试著如何有效的让 “每个 " 团队进行准确、有效率与低风险的设计，也思考如何在实务上与其他不同专业的团队合作。
不过，就如这本电子书 Google 提到的，他们也鼓励各个组织可优化他们提出的方法流程。这点我认为非常重要，因为每个组织的文化、团队、员工、设备等皆不同，如果硬要导入一种方法论，也许会造成水土不服而衍生更多问题。所以在对的方向上，应考量现况与团队适应能力来调整，才有机会将这些思维与方法论带来的效益发挥出来。最后，若各位读者对此方法有任何想法，也欢迎留言，大家一起来讨论！
资料来源：Design Sprint Methods
发表评论 取消回复