美文网首页
我们如何在英国政府部门里进行设计冲刺

我们如何在英国政府部门里进行设计冲刺

作者: ONES_Piece | 来源:发表于2018-06-05 21:06 被阅读72次

本文原载于 charlesrt.co.uk
译者:Jessie | 校对:DSC发起人-Snow

译者按:英国政府部门利用设计冲刺的过程中有什么发现?它和政府本身设立的“调研”和“验证”流程又有什么区别?如果设计冲刺流程可以在政府部门中能起到作用,那么将来还可以运用到什么场景?

冲刺团队在一周内构建出了问题,在得出解决方案之后,与真实的用户进行实测,以验证假设。

我是一名资深交互设计师,并与一支多学科背景的团队共事,通过使用API帮助人们验证相关事项能否运用在政工作中。

这是一则关于我组织的设计冲刺的故事。整个故事的焦点在于围绕的是冲刺中发生了什么,而非在于我们攻克的难题本身。在政府工作中处理敏感的项目是常态,而我们则采取积极的措施把事情变得透明化——这也可以使事情变得更好。这则故事就是一次有益尝试。

什么是设计冲刺?

如果你想更深入了解设计冲刺,这儿有本书

那些以用户为中心的团队如果你们的团队专注于以用户为中心,那么应该对书里的内容并不陌生。设计冲刺是一套谷歌风投开发的流程,这一个独特的方法,把所有相关因素聚集在短短五天之内,使得这套谷歌风投开发的流程成为解决关键性棘手问题的一种非常有效的方式。

对于一支敏捷文化的团队来说,“冲刺”这样的叫法可能比较容易误解。可以把设计冲刺想象成一个设计跃进跃升。你不需要指派整个团队去执行。思考一下哪些任务可以稍后处理,而哪些人你需要一直配合到底。亦即调动每个人这样就可以调动每个人都来关注设计冲刺。

为何要进行设计冲刺?

我们的大量项目都需要其他人的配合。每个人都急切地希望在项目板上增加下一项需要处理的事情来保持忙碌的状态。

我们团队的目标非常清晰,因此所以马上开始设计冲刺非常容易。但是,这本身也可能是个问题——我们不想把时间和金钱浪费在一些到后来发现根本不需要的事情上。

因此我想组织一次设计冲刺来为下一个项目寻找灵感。然而团队并不认同这样的做法,我们就需要换着角度跟他们解释。在几次试图说服团队后,他们仍然不以为然——不过设计师执意如此。最后,有一个人出马耐心劝说并且改变了团队的主意——这个人就是我们的产品交付经理。

设计冲刺可以帮助理解需要解决的问题,并且提示我们是否在正确的轨道上。即使不能的话不能起到这些作用,我们也只是花费了一周的时间,而非数月。这就是双赢。

团队在经历冲刺的流程与政府自己设立的“调研”或“验证”流程时,并没有那么的不同。不同点就在于冲刺中的架构以及时间限制,迫使团队作出决定、取得进展。这就使得设计冲刺可以用来很好地可以很好地来启动和引领一个项目,或者在半路中应付一项新的挑战。冲刺途中有所其他的发现。

开始设计冲刺之前

我们预定了一整周的会议室,那里将会成为我们的“战场”和“调兵遣将”的地方。我们的团队由以下人员组成:产品负责人、用户调研员、商业分析师、前端开发工程师以及交互设计师(我本人)。

整周的设计冲刺由我主导,而我们的产品负责人负责决策。

我们还邀请了一些专家加入我们。他们比较熟悉现存的问题和流程,所以最适合为我们答疑解惑,帮助我们查漏补缺。但不幸的不巧的是,由于工作需要,他们不能整一周陪伴我们,只有周一和周二参与,但这两天他们将全力以赴。然后我们在周五测试的时候再次与他们碰头。

我们同时达成一致,将与其他团队成员一道继续参与每天的冲刺总结,不仅是为了可以答疑解惑,而且可以让每个人知道知晓冲刺的进度。

周一

我们搭出了问题的框架、设定了长期目标,并且记录下了我们的中心假设以及疑问。

如果我们严格地按照流程去做,可以在设定的长期目标以后,尝试描绘出未来旅程图的所有步骤。然而冲刺团队发现很难视觉化呈现这些步骤,因为在现实中很多因素是不可控的。这在政府组织里颇为常见——大部分的服务项目需要牵涉到多个政府部门,因此而且作为团队的一分子,你所了解的只能是冰山一角。为了把目前的进度推进下去,我询问了决策者是否应该取而代之地聚焦在当下的旅程图。这样的做法很受欢迎,因为我们了解当下的旅程,可以把它阐述出来并且绘制成旅程图。同时我们也知道问题出在了哪里。

这样一个反向的做法意味着我们不是专注在一个理想化的旅程图中设定一个目标,而是扎根于现实,找到我们最具风险的问题出在哪里,这个地方也酝酿着我们的最佳机会。

我感觉这一天格外漫长,而且我并不确定大家是否在这个流程上达成了一致。已经有人有一些人已经在我们开始之前就质疑了这样行动的价值,但而且周一的流程并没有起到任何帮助。然而周一是重要的一天,也是进展缓慢的一天,由于关系到许多过去的观点和立场,因而也是进展缓慢的一天。当团队外围成员时不时进来观察的时候,情形人为变得更加复杂进展就显得越为缓慢,因为这样我们就需要经常把进展重新描述一遍。然而,既然我们到了这里,便准备好从一大早开始就解决我们的目标问题。

周二

在冲刺周里,每当周二的时候我总是很紧张。我知道自己在绘图技巧方面不达标,我那个刚在学步的儿子也会在画画方面立马超过我。但这件事并没有阻碍我,因为我明白绘图方面的非凡技巧并非是关键,然而有的人就是在这里望而却步。我过去组织过几次工作坊都在这个点上就失败了,因为大家不想参与,对他们的绘画能力缺乏信心。然而,这与画些好看的东西并没有关系,关键在于把脑海中的信息提取出来,呈现给大家看。这些信息可以是方框、涂画,甚至就是关键词。关键词确实是非常有效的涂画。

这个过程可以帮助修复大家的信心。与周一形成对比的是,周二相对安静,大家大都在自管自地涂涂画画。直到一天快结束、形成了个人的想法之后,我们才作为一个团队进行分享和回顾。

看到每个参与进来的人都很高兴,我也没什么可担忧的了。能看到团队能以以这样的方式和设计打交道,我感到非常愉快。

周二快结束的时候,我进行了一个即兴的回顾。这样做主要是让我自己确信大家对冲刺流程持乐观态度。这个机会也非常好,可以让大家去思考任何一个步骤是否可以有不同的做法。

和往常一样,我并不需要担心——整支团队对创意孵化的全新做法、我们推进的节奏以及我们共事的方式,都持积极态度。没有前一天那样反复的回顾,也很走运今天没有人拜访旁观。也有人建议接下来的几天可以以观看YouTube上《设计冲刺》的作者杰克·纳普和约翰·泽拉茨基的视频作为开场。

周三

根据提议,这天是以杰克和约翰简短的介绍如何开始周三的冲刺作为开场。他们可比我投入多得多,所以这样开场一定可以开启充满能量的一天。

我能很明晰地看到团队的融入与周一大为改观。那些坐在椅子上不动、怀疑的眼神不复存在了,大家都站立起来,热烈地讨论和来回走动。

我们的进步很大,选出了最佳创意、设计出了一个完整的故事板,并且期望基于它来进行原型测试。

周四

我们幸运至极——因为我们团队拥有一位前端开发工程师,他通过一个AngularJS的框架,很容易地的就准备好我们所需要的英国政府网站元素和开发环境。在很短的时间内我们就搭好了高保真原型的坚实基础,用户可以与之互动,就好比已经是个成型的产品。所谓把枯燥的工作理出头绪,无非就如同我们集中一整天的精力,把测试原型最困难的部分解决掉。

建立一个标准化的原型并非意味着其他组员就可有可无了。每个人都有自己的职责,比如建立模拟数据库、搭建纸质模型和定义不同的场景。团队里的所有人都到一起,把场景搭建得越真实越好。在最后一天进行实测时,这将使我们的观察更贴近现实。这样就可以在最后一天使得测试变得更逼真。

周五

冲刺的后几天就好比马拉松,而周五就是名义上我们冲刺的终点了。

我们计划把在马路对面的大楼内进行的实测作为开始——那里是用户真实的工作环境。我们打算通过谷歌环聊软件直播整个场景给向我们的团队直播整个场景。这样的话,我们整个团队都可以实时观察并做记录。

在第一轮实测开始的时候,用于测试的手提电脑突然无法连接上WIFI。由于参与者这会儿都到齐了,我们不可因此而耽搁。我带着另一台手提穿过马路,把摄像头指向实测的场地。不幸的是角度不佳,虽然我们的团队可以听见所说内容,但是不能在屏幕上看到任何互动的情况。

谷歌环聊软件就发生了这样一些小意外。

在下一个参与者到来之前,我们还有一些时间。直到实测结束我们才意识到是因为另一端实况没有通过谷歌环聊软件传输过来,所以我们才没能在屏幕上看见。

所以到这个时候我们才放弃了使用视频流,取而代之在同一个房间内重新安排下午的实测。由于这样就不是“自然”的环境了,所以并不理想,但至少每个人都可以旁观到。

我们在午餐的时候也还有一些时间,所以我们也为下午的原型实测做了些许微调。在实测的时候一些小问题层出不穷,前几天也没有机会来纠正它们。所以现在有必要把它们迅速解决,消除障碍。

下午的实测顺利多了,我们在那一天结束前厘清了我们所有的想法。

终于完成啦!——在一周的时间内,我们构建了问题、设想了一个解决方案原型、与真实的用户进行实测并在最终得到了许多有实践指导意义的、高质量的反馈。真是太棒了!

设计冲刺结束之后

接下来的一周,我们做了一个展览并与一些政策制定者进行了分享。我们分享了我们所经历的整个流程、创造了什么以及学到了什么。我们感觉用了一周完成了一项伟大工程,但也知道我们很快将回到现实当中。但总而言之,担心是多余的!那些政策制定者对整个流程以及我们在那么短时间内的所获所得印象非常深刻,甚至期望找到我们的解决方案可以运用到更多的场景。

这是一个漫漫旅程的开始。我们学到了许多,但最重要的是我们知道了我们还欠缺什么。

出乎意料的是,我们现在所邀请的专家们就是我们一小部分的尖端潜在用户,他们有几天没有参与到设计冲刺,也就意味着我们可能无形中失去了很多原本可以使旅程更富有价值的东西。

我们计划把我们所做的工作作为筹资的砝码之一,所以希望可以在不久的将来成就一个完整的项目。

我做了一个展示并告知更多来自我们外围数字化领域的人、分享我们的旅程,也希望可以启发到其他人来进行他们自己的设计冲刺。当我们听到我们的产品开发者和前端开发工程师承认他们之前其实很是怀疑的时候,我们感到了欣慰,因为那时他们并不相信我们可以做到。现在我们成功了,他们对我们的成果印象深刻,并且愿意复制我们的经验。

在政府部门进行设计冲刺有其独特的挑战:透明化工作、高层决策、跨部门的依赖性、政策、立法以及筹资。不要让这些东西阻止你。在冲刺周结束的时候你一定会从原型里找到实质的成果。你会产生许多疑问,但也会得到答案。你将会收获很多,速度更快,而这一切,仅仅是个开始。

本文为 DSC 与 ONES Piece 联合翻译计划的一部分。Design Sprint China (DSC) 是一个专注有趣设计思维的创新创意社群,其翻译团队定期搬运相关海外文章,微信公众号:设计冲刺。ONES Piece 是一个由 ONES Ventures 发起的非营利翻译计划,聚焦科技创新、生活方式和未来商业。

相关文章

网友评论

      本文标题:我们如何在英国政府部门里进行设计冲刺

      本文链接:https://www.haomeiwen.com/subject/uejcjftx.html