{{cate.name}} 搜索
无结果
没有更多了
上一页 1 ··· {{pageIndex-1}} {{pageIndex}} {{pageIndex+1}} ··· {{countIndex-1}} {{countIndex}} {{co.mypage}} 下一页
搜索结果数
{{total}}
{{forincome.name}}

初探 Google 提出的设计敏捷方法(Design Sprint Method)

首页 >点滴 > 经验观点
2292

设计敏捷方法 (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. 验证

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


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


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

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


感想


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

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

不过,就如这本电子书 Google 提到的,他们也鼓励各个组织可优化他们提出的方法流程。这点我认为非常重要,因为每个组织的文化、团队、员工、设备等皆不同,如果硬要导入一种方法论,也许会造成水土不服而衍生更多问题。所以在对的方向上,应考量现况与团队适应能力来调整,才有机会将这些思维与方法论带来的效益发挥出来。最后,若各位读者对此方法有任何想法,也欢迎留言,大家一起来讨论!

资料来源:Design Sprint Methods
{{collect ? '已':''}}收藏
{{collectNum}}
{{praise ? '已':''}}点赞
{{praiseNum}}
你可能喜欢 换一组

娜娜

wechat

获取最新大赛、设计资讯