用户体验这个词由来并不久,但用户体验的工作流程却经历了很多变化。从最初的传统用户体验瀑布流式的工作模式,到敏捷设计,到精益用户体验,以及最近的设计冲刺和双轨道设计,每种工作模式都会有利弊,就看使用者如何将这种工作模式用的恰到好处。
“用户体验流程是容易让人困惑的,甚至对大多数设计师来说都是如此。”
首先,我们看看唐·诺曼提出的用户体验设计的概念:
“我发明了用户体验设计这个词,因为我认为“人机界面”和“可用性”这两个词太狭隘了。而我想涵盖的是个人与系统之间体验的所有方面,包括工业平面设计,用户界面,物理交互和使用手册。从那以后,这个词被广泛传播,以至于它开始失去了其本身的意义。”—唐·诺曼
直到2016年,唐·诺曼一直很直言不讳地表示这个词被误解很严重,他也在一段简短的YouTube视频中提到了这一点。这段时间他说他在某种程度上是一位大众设计师,但他对这个头衔表示不置可否。
甚至连我们这个领域的鼻祖都不知道如何称呼自己,我想这种状态或许可以表明当代用户体验设计的奇怪和困惑之处。
要明白现在的用户体验,就需要了解20世纪90年代以来设计和开发的历史。它们之间存在着内在联系,所以在几年后就开始互相影响。
在这种纯粹的形式下,用户体验设计是基于瀑布流的工作模式。
图片来自Swipecubes
一个通过瀑布流方法工作的产品团队,在构建最简单的原型之前,需要着手学习尽可能多的知识。研究可能需要几个月甚至几年才能完成,而研究结果决定了设计团队的执行方向。
在设计开始前,需求是锁定的,在开发开始前设计也是锁定的。没有回头路可走,直到2.0版本。这就是瀑布流的工作方式。
在校学生通常会被传授传统的用户体验流程,比如这样:
这基本上就是一种瀑布流式工作流程,用户体验的经典元素(杰西·詹姆斯·加勒特)也遵循瀑布流式,根据明确的需求建立自下而上的执行操作。
但问题是,传统的用户体验从根本上来说,与敏捷开发是不兼容的。
长久以来,硅谷的创新都是由摩尔定律推动,该定律指出:高密集度集成电路中的晶体管数量大约每两年增加一倍。如果重叠瀑布流过程来看,你会注意到它以24个月为一个周期。商业,设计和开发周期就像瑞士钟表一样结合在一起,英特尔芯片组的新品发布就是很好的例子。
突然有一天,索尼、东芝和IBM(STI联盟)认为摩尔定律太慢了。
STI创建了第一个细胞芯片,它在单个晶片上堆叠了8个微处理器内核,而这家伙实际上效果是不错的(它为第二代游戏机PS2提供动力)。多核架构改变了这一切。
而摩尔定律没有消失,它让生活更加高效,消失的则是瀑布式工作流。
几乎一夜间,速度和灵活性取代精度和可预测性成为极具竞争力的优势,公司也全面转向另一种颇具规模但未充分利用的开发方法——敏捷开发。
敏捷开发的重点在于:快速迭代,它每2-4周发布一套新的可交付的功能,是随着时间的推移对产品进行更新,而不是一次性更新。
它是基于假设、实验、快速发布和实时测量而建立的。在敏捷开发中没有编辑阶段,没有尽善尽美。正如Bre Pettis在2009年所说的,每一次迭代完成都是趋向更加完美。
瀑布流式的工作流程需要“测量两次,去掉一次”,这比从到处都是 iPhone 的世界中淘汰诺基亚 StarTAC 要更快。
不过,有一个小问题:传统的用户体验是在瀑布流式的节奏下运行的。
由于每个月迭代一到两次功能,使得用户体验设计师没有时间来执行他们的体验设计过程,这就导致在敏捷开发这个概念中,用户体验成为了阻碍者,这是非常糟糕的一点。
面对不能改变的阻碍,大多数团队会简单地放弃用户体验。取而代之的是,他们雇用了能够在两周内快速交付的年轻平面设计师。这些设计师并不是真正的用户体验从业者,至少不是传统意义上的,但他们对于以用户为中心的设计是有基本认知的,至少能避免犯最糟糕的错误。
这种情况与产品开发团队也可以合作顺利。他们认为:细节将通过迭代自行解决。
可以谨慎地猜想一下,敏捷开发过程中设计师的头衔会是什么呢?
如果你回答“ UI/UX 设计师”,那么,给自己奖励一块饼干。
当苹果公司证明:以设计为主导的商业模式可能会塑造全球最有价值的品牌时,UI/UX设计师正处在这场风暴的核心。当用户体验在两周的敏捷冲刺中连削铅笔都来不及,更别说设计一个功能,设计师们是时候接过用户体验的火炬了,虽然这是需要付出代价的。
UI/UX对数字化和平面设计的倾向和偏爱严重扭曲了商业世界对体验设计师的看法。直到今天,还有很多企业仍然认为用户体验是一门视觉学科。正如唐·诺曼一直试图解释的那样,这是不正确的。
这一切直到2013年才开始逐渐好转。
《精益用户体验》是杰夫·戈塞尔夫针对在敏捷开发环境中践行用户体验的一些问题,而提出的改变游戏规则的杰作。Jeff在他开创性的杰作中,把用户体验的整个领域都化为智慧的火花。这本书介绍了一系列策略和调整活动,使用户体验可以在不确定性范围内敏捷地运行,并根据用户反馈快速迭代设计。
尽管传统的用户体验是需求导向的,但精益用户体验是结果导向的。如果您需要关于精益用户体验快速入门的指导手册,O’Reilly 提供了在线免费章节,可以让你快速准确了解。
敏捷环境中的精益用户体验,来自 DaveLandis。
尽管如此,精益用户体验还不算完美。虽然用户体验现在能够与敏捷设计的节奏相互协调,但如果产品定义模糊基本上任何没有发布的产品,精益模型就会崩溃。
设计师发现:在他们真正了解正在构建的东西之前,自己要承受巨大的压力去做一堆在冲刺中积压的工作。因此,大量的开发周期都被这些根本无法成为最终产品一部分的功能所消耗。以至于在项目管理界,精益用户体验或者敏捷开发在不理想的条件下的尝试,是以大量浪费和返工而闻名的。
在一个成熟的产品中,可以搜集到大量的用户反馈,这对推动精益用户体验的迭代周期起到了很好的作用。这就是为什么精益用户体验几乎是所有已建立的产品团队的行业标准,没有人会去改变它。
但是,在建立团队时,用户反馈机制尚未自行启动。在这种情况下,浪费和返工问题已经足够严重,经常会影响精益用户体验成果的采纳。这为初创公司和重要项目组呈现了一个真正的难题:他们希望在不恢复瀑布式工作模式的前提下拥有强大的用户体验团队结构。
就在这时,杰克·科纳普和谷歌风投像闪电一样从空中出来,用设计冲刺解决了问题。没有人注意到它,也没有人关心它,但用户体验漫长的黑夜终于结束了。
附录:
设计冲刺的根源在于IDEO以人为本的设计流程,该流程与斯坦福设计学院紧密相连。麦肯锡使用相同的概念根源创作了类似的冲刺模型。所有这一切都追溯到斯坦利波利特和广告中以用户为中心的设计根源,但这是另一个故事。
如果你正在看一场设计冲刺或书,并说“等等,那就是一个加速版的传统用户体验流程啊”,那么你就差不多答对了。它的不同,或者说天才的部分就在于:它就是一个低保真度的传统用户体验流程,就像艺术杰作和简单素描的区别,但它却很有效。
设计冲刺的目标是搜集现有问题,并对之进行研究,然后将其实质拆解为一个多元结构,最后疯狂地想点子。
然后,这些点子通过以人为中心的设计进行漏斗式筛选,最后的点子再由团队投票选取。之后,设计师们构建一个低保真度的(能够勉强测试潜在用户的)原型(通常仅在一天内)。如果测试结果为正面,就可以为设计师打造高保真目标奠定基础,从而加速了精益用户体验或敏捷开发的周期。
“任何足够先进的技术都像魔术般难以捉摸”——- Arthur C.Clarke
重要提示:双轨敏捷开发通常是指在精益用户体验环境下研究和设计之间的相对独立。我已经更新了这篇文章,希望减少对双轨道设计的困惑。
现在,我们来看看当今的用户体验方法论的重点。
正如你可能预料的那样,双轨道设计有两条轨道我知道,这是个福尔摩斯水平的推理,低调低调。
一个产品团队通常在第二轨道上运行,除非需求定义非常不明确。如果发生这种情况,则团队会评估问题并且进行设计冲刺。这样问题就可以得到解决。
但是,如果产品团队正在忙于进行精益用户体验,那么这个评估由谁来做呢?
那最有效的方法就是成立一个专门小组来负责。当设计和开发在努力迭代时,研究团队可以在后台更全面地调查结果,而且由于该研究团队不会受到敏捷冲刺节奏的限制,他们仍然可以奢侈地花费3个月的时间来取得结论。
每隔几个月,输出团队就会接收新的洞察信息,并以此为他们要做的需求补充新的实验性猜想。在与我合作的一家公司中,现在已经有了一支完整的数据科学团队,为多个创意小组提供知识。但由于研究人员需要较长的输出周期,因此这种洞察更新并不频繁,但当它发生时,效果总是非常好。
有时洞察的发现足以引发设计冲刺,这大大改变了产品愿景。然而,大多数情况下,只是给精益用户体验增加了一个导火线。
所以,当一个专门的研究团队在活跃的产品组范围之外工作时,双轨道效果最佳。
你可能已经猜出这是一件花钱的事情。
是的,你又答对了。
但我可以告诉你的是:这至少比在没有用户体验的情况下运行,或者比单纯的精益用户体验造成的浪费和返工问题来的便宜。
投资它吧!
那么,在双轨道设计中,用户体验设计师属于什么角色呢?
用户体验设计师的角色将会是一个领导者,一个流程传播者,一个洞察的产生者,一个承上启下的角色以及一个点子制造机。正如我在其他地方所说的,用户体验设计提供的是一种价值,它本身已经兼容了可以提供上百种不同成果的十几个不同岗位的作用。
除非我们领导一个团队,否则我们大多数人实际上并不是真正的用户体验设计师,而只是在用户体验设计领域工作而已。
这足够让任何人感到困惑,甚至会激怒唐·诺曼。
本文原载于uxplanet.org
作者:Ian Armstrong
译者:小释界,个人微信公众号:insightUX
微信公众号:设计冲刺(ID:designsprint_cn)
来源:
https://mp.weixin.qq.com/s/GrUEQDzz8e543Ek8V8-DBA
本文由@设计冲刺 授权发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash, 基于CC0协议。