青小蛙の博客

浅谈 Google 提出的设计方法论

青小蛙 设计UI

所谓的设计方法论,是谷歌创投的 Jake Knapp 发明的一种产品设计工作法,即设计冲刺计划 (Design Sprint Method)。它的概念基础来自于其他已经在产业界应用的方法,例如冲刺开发(Agile)、设计思考(Design Thinking)与革新游戏法(gamestorming)。这个方法试图让每个设计团队都能轻易的导入,且能于5 天内解决设计挑战或测试设计原型。

本文介绍的内容整理于 Google 在 2015 年公开的电子工具书 – “Design Sprint Methods”,这本书简述这个方法中的角色、功效、时间、工具与流程等项目,不过 Google 也指出他们的目的,并非要求大家一定得按表操课,而是鼓励或激励新创或任何规模公司的设计团队,能发展出更有趣、多产且能适应的变通方法。好吧!废话不多说,下面我就来了解下具体的操作流程。

设计冲刺计划团队组成

design-Sprint-Method_01

Google 建议的团队人数约 5~8 人,其中包含设计师、工程师、产品经理或相关领域专家(如图中的团队即有两位设计师、一位工程师、一位原型设计师、一位 Sprint Master 与一位研究员)。若团队人数超过这个建议值,可拆成数个较少人的团队。并依组织或企业的目标,让不同团队面对相同或相异的挑战。

对团队的成员构成有初步认识后,我们暂不描述这套方法怎么运作,而是介绍其中决定专案成败的重要角色 – Sprint Master 之能力、职责与事项等。

谁是 Sprint Master?她/ 他要做什么?

基本上,Sprint Master 就是整个团队的领导者,他们的背景通常是 UX 研究员或设计师,且需要对设计流程、UX 方法论、策略、激励指导团队技巧与谈判有深度的了解。他们最大的任务即是:1)定义设计的挑战为何、2)建构团队及 3)带领团队跑完整个流程。

“Sprint”是整个流程相当重要的名词,它指的是解决一次设计挑战的跌代流程,若要更深入了解可参考 Design Sprint Method 开发的相关文章

在进行 Sprint 的前中后,Sprint Master 都有不同的事情需要做,该花的时间也不太一样,我们就由下图来说明:

design-Sprint-Method_02

Sprint 前

Sprint Master 在此时做的事情相当关键。首先,他必须定义好这次设计的挑战为何?以及工作时程。再来,他必须建构团队,并用快速访谈的方式向成员说明任务与使用者资料,并安排好后续测试的相关细节。另外,若能准备好环境,将会让 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)参考使用者案例。

准备好环境、设备与工具

design-Sprint-Method_03

Sprint Master 需将任务时程表规划好,同时选择好要应用的方法,例如本书提供的或任何适合的方法。另外,安排一个大桌子,它能在整个 Sprint 过程中起了 “激励讨论” 的效用,当然还会需要一些简单但有用的小工具,例如:剪刀、纸、胶带、便利贴、投票贴纸、计时器或响铃等。最后,若能贴心的准备小点心和咖啡的话,那就更完美了!

进行 Sprint 的流程

跑一个 Sprint 有六个阶段,类似 IDEO 提出的 Design Thinking 方法论,简述如下:

1.理清与了解(Understand)

使用者需求为何?商业需求为何?技术可行性?

2. 定义(Define)

决定关键的策略与应该关注于何者?

3. 发散(Diverge)

如何探索更多的想法?

4. 抉择(Decide)

选择目前最佳概念

5. 原型(Prototype)

做出概念的原型给使用者测试

6. 验证(Validate)

向使用者、相关权益人与技术专家验证概念

每个阶段都含有许多实践的方法,例如使用者访谈、竞争者分析或技术分析等。但我们不需要把所有的方法都用上,选择适合且正确的即可,甚至根据经验修改或调整过去的方法也行的!

STEP 1. 厘清与了解

360 度快速访谈

这阶段最重要的目的,就是提供不同的观点来了解问题。这场会议应该包含下述的内容,此外顾名思义, 快速访谈就是要简短扼要,不用花太多时间。

  • 商业上的目标与判定是否成功的指标/5 分钟
  • 技术可行性与可能面临的挑战/5 分钟
  • 相关的使用者研究/5 分钟

竞品分析

研究 3-10 个相似的产品或服务,列出喜欢或不喜欢的点,这方法可让我们更快进入状况也能产生更多灵感。

用户访谈

我们都知道使用者会是最后使用与评价产品的人,所以这就是为什么在 Sprint 开始前必须进行此步骤。如果是产品或服务已存在,我们可以问他们会如何使用,对他们的评价是如何;若是一项全新的产品,那我们要更专注于了解使用者觉得哪种解决方式比较好。

实地走访

有时候,访谈使用者不如直接走入他们的工作或操作的环境中来的有用,不但可以了解整个体验脉络,也可由中带回最不失真的访谈。

利益相关者

产品与服务的设计其实不只要关心使用者,所有利益相关者的需求都须考虑进来。我们可以尝试在 30 分钟内绘制出利益相关者图表:

  • 首先,陈列所有可能的权益人/10分钟
  • 将这些权益人分组/2 分钟
  • 决定哪些权益人是你在这次 Sprint 的设计对象
  • 了解他们的需求

总结学到的资讯并尝试提出想法

design-Sprint-Method_04

在大家消化前述提到的资讯后,尝试分享自己的洞见与初步的想法,将它表达于便利贴上。接着,将这些概念分组,并利用小贴纸投票来选出觉得好的概念。不过,最后选出的概念并非一定要往这个方向进行设计,团队还是可在之后的步骤中,因学习、讨论或发现而改变或优化。

STEP 2. 定义

使用者旅程(user journey)

此我们可以透过展开使用者旅程,列出使用者从发现产品或服务、初次体验、再使用及变的熟练的过程,来整理与分类概念,并定义之后设计的策略。

定义设计原则

定义设计原则的方法很简单,让团队列出认为或希望使用者怎么描述产品或服务的形容词,并选出其中最符合的三个。在 Sprint 结束后,你可以请使用者在体验完 prototype 后说出三个词汇来比较当初设定的设计原则目标。

想像发布时的第一条Twitter

以 Twitter 来举例,怎么用140个字去描述你的产品核心策略。想说的肯定很多,但是只用140个字,让你的核心更加聚焦。 这个定义的过程,我归纳为聚焦核心,避免跑偏。设计师都贪心,可时间有限,咱们要更加清晰明确自己追求的是什么。

STEP 3. 发散

5 分钟想 8 个概念

design-Sprint-Method_05

这个概念来自于革新游戏法(gamestorming),是一个暖身的练习方式。每个人都发一张纸,并对折三次,展开后就有八个区域,接着花 5 分钟在这八个区域上画上一些想法。

5 分钟画出一个较好的概念

design-Sprint-Method_06

接续上个练习,花 5 分钟将比较喜欢的一个概念,较精细的画在一张纸上。

5 分钟画出故事情境图(storyboard)

design-Sprint-Method_07

若概念较复杂不容易表达,我们就可以考虑用故事流程的方式陈述用户的操作的步骤。团队成员可选出使用者体验的 “关键” 情境将它简易的画在分镜中。(若您的团队成员对这个方法感到陌生,可以告诉他们就像画漫画般)

STEP 4. 抉择

静默投票(Zen voting)

在快速绘制概念后,大家可以将纸贴于板子上,全部看完后进行投票,但规定不能出声。不能出声的用意在于,避免因说服或说明后,而影响最初的个人想法。

团队讨论并决定以哪个概念做出原型

design-Sprint-Method_08

团队可以开始讨论哪一项概念是最好的,并决定往下做出原型。此步骤不需要再进行概念发散的动作,例如草图或探索。

思考帽(Thinking hats)

design-Sprint-Method_09

如果团队经验较少或开始对意见有所偏颇或分歧,可以进行思考帽(Thinking hats)这个方法。让每个成员扮演不同的角色(类似扣帽子的意思,如上图),并模拟该角色的想法来表达观点。这样的做法的目的在于,让讨论更加多元全面。 上图中的案例中就有五种角色,如:点子王、乐观主义者、悲观者、技术专家与使用者专家。

注:此方法是由 Edward De Bone 于 1980 提出。

STEP 5. 原型

design-Sprint-Method_10

原型大家应该都清楚知道,它能让使用者足以真的感受到有这样的产品或服务存在,这样才能得到较不失真的回馈。同时,此书也建议可以花多一点时间在这个步骤中。

STEP 6. 验证

使用者测试

透过原型进行使用者测试最大的目的,即是快速得到有价值的洞见。以下提供几个简单的问题供参考:

  • 使用者对原型喜欢与否,其原因为?
  • 他们觉得可如何改进?
  • 这个解决方案是否能满足他们所有的需求?

相关权益人确认

概念要持续发展下去,关键的权益人掌握了决定权与资源,例如 CEO。所以他们的确认相当重要,是迈向成功的必要元素。

技术可行性确认

确认这个概念所需要的技术是否超过团队的能力,邀请技术专家评估与讨论,可让后续发展更具可行度。

感想

有些设计师会将创意产出方法与设计方法论视为无用,相信创意的产出来自自我的灵感。事实上,在多元丰富的生活经验、新事物的刺激、或传化念头下,设计师可能会突然产出独特的创意或解决方法,也因此有些设计师会质疑具有流程、方法及工具的设计方法论,是否能有效的产出创意。

其实这样的说法,不具有普适性,我们重点应该视这些思维、流程、方法与工具为参考或激发的手段,毕竟团队中具有精准洞悉与产出对的创意的人太少,而依靠个人创意所带来的风险也非常大。因此,不需要对这些创意思考的模式与方法嗤之以鼻(例如设计思考、UX 流程等),这些方法尝试着如何有效的让 “每个” 团队进行准确、有效率与低风险的设计,也思考如何在实务上与其他不同专业的团队合作。

不过,就如这本电子书 Google 提到的,他们也鼓励各个组织可优化他们提出的方法流程。毕竟每个组织的文化、团队、员工、设备等皆不同,如果硬要导入一种方法论,也许会造成水土不服而衍生更多问题。所以在对的方向上,应考量现况与团队适应能力来调整,才有机会将这些思维与方法论带来的效益发挥出来。

资料整理:Wilson 资料来源: Design Sprint Methods

青小蛙
那一池,氲光拂过的荷叶