β

完美匹配敏捷迭代的用户研究策略【UXRen译#191】

13Tech 19 阅读

作者:Ben Ralph |  翻译:丫丫,校审:Dch King

用户体验研究(全称为:User eXperience Research,很多企业也被称为:用户研究User Research)可以帮助团队洞察用户,促进产品开发,但实施不当的话,也可能阻碍项目进展。做研究工作时,往往会遭遇反对,我最常听到的是“时间来不及”。我当然理解,但也会告诉他们“只管去做”。

­­

随着过于死板的瀑布开发逐渐转向灵活的敏捷开发,如何找到恰当的阶段来实施研究成为难题。

用户体验研究员属于敏捷团队的一员,还是有他们独立的业务团队?一个团队是否可以同时兼任项目的研究、设计、开发和测试工作?当我们已经进入开发阶段,如何再去决策开发什么?

矛盾1:将用户体验研究融入开发流程却阻碍项目

常用的折衷方案是在敏捷开发的过程中实施用户体验研究,但是先于几个迭代前进行。这个方案听起来不错,但却常常引发用户体验研究员与其他团队成员之间的矛盾。

一个团队的开发速度取决于其中最慢的一个环节—鉴于此,项目进展常常会被一个力求最优方案的用户体验研究员影响。另外,这样的方案本质上属于一次迷你版的瀑布开发,而非敏捷开发。

最后来说,这个方案不可行也是因为高质量的研究需要时间成本。用户体验研究员需要花大量的时间去了解这个领域,去理解用户,去追溯尽可能多的线索,直到找出一个可以解锁产品潜能的引爆点。这样的研究绝不是在一两个迭代周期之内可以完成的。

矛盾2:用户体验研究独立进行却脱离实际

另外一个方案是将用户体验研究独立于敏捷团队之外,通常先于敏捷开发几周或者几个月进行。这个方案的明显不可行之处在于它忽略了研究的时效性和相关性。用户研究的价值在于提高用户的产品使用体验,研究越偏离实际用途,越难发挥其价值。

况且,脱离了开发以及测试这些务实主义者,设计师们会变得更加天马行空,从而造成 “理想的体验”与切实可行的方案之间产生鸿沟。设计师会因为开发者无法实现方案而感到沮丧,开发者也会因为满足不了设计师的想象力而觉得挫败。

矛盾焦点:如何并行实施用户体验研究?

我们在找一个两全的方案。我们需要将一部分用户体验研究保留在敏捷开发流程中,而将另一部分独立出来按照其本身的节奏去进行。

我们不妨将研究分成两大阵营:基础研究VS定向研究。

基础研究是指用户访谈以及人种志研究,这类研究建立了决策所依据的坚实基础。定向研究是指可用性实验,通过解决特定的用户问题从而一点点塑造产品的方向。

方法1:定向研究

定向研究具有针对性,并且周期短。实施的目的在于解决具体的可用性问题或者用户意愿问题。研究由敏捷团队执行。为了达到好的效果,实验需精简独立,旨在找到某一问题的解决方案,或者证实某一假设。

定向研究面向团队内部,也会简单地涉及到其他业务层面。研究产出应该是一个明确的YES/NO的回答,或者是一条切实可行的建议—而非一份十几页的报告。

例如:

方法2:基础研究

基础研究是指用户访谈及人种志研究,目的在于了解用户的意愿、需求、目标、动机,并得出一个立体丰满的用户画像。

值得注意的是下方图表中关于基础研究的价值并非一成不变。不能仅仅只做一次用户访谈就完事了。市场、技术、用户都在变化,你的产品也需要改变。伴随这些变化,研究的相关性减弱、愈发陈旧,其价值也会越来越低。

这意味着基础研究是一项持续性的工作。深刻见解需要时间累积,永远不要停止和用户交流并从中学习。

基础研究是有时间成本的。团队需要时间去参与并观察用户行为,需要时间去向无数用户无数次发问,直到发现先前被许多公司忽视掉的璞玉。

例如:

方法3:将基础研究与定向研究结合起来

这两类用户体验研究可以各自独立,一快一慢地并行实施。

那么,该如何将它们运用在团队工作中呢?

Medium网站上有多不胜数的文章介绍UX以及产品流程,方法并不唯一,每个团队都需要寻找合适自己的方法。

所以,这里只提6点建议,希望可以帮助你去实施并行的用户体验研究。

1、敏捷团队应始终处于核心和领导位置

敏捷开发离不开团队成员的自我驱动力。他们需要研究以辅助决策,但是也不能一昧地对用户体验研究结果照单全收。敏捷团队需要有能力去发起并执行研究。

2、灵活把握研究规模及时间

在项目早期测试1名用户好过在项目快结束时测试50名用户。

–史蒂夫·克鲁克

在项目启动时,会有冲动进行各式各样的研究;在进入开发阶段之前,恨不得找到所有疑问的解答。但这是不现实的,知道的越多,反而越觉得自己需要学习更多。

最好将研究细分成简单快速、易操作的小模块,再根据每一次的研究决定下一次的研究方向。

3、运用团队的力量来进行实验

你们是一个多职能的敏捷团队,要充分发挥这个优势。

了解用户行为的最好方法就是开发出来发布到市场上,看看用户是如何使用的。再次强调,从小处做起,问问自己:如何开发一个最小的模块来解答一个关键的用户问题。

开发和测试人员可以成为用户体验研究员的好搭档。做完实验之后,确保自己花时间去解读这些研究发现,然后再将它们实施出来。

4、自我审视

(优秀的)开发者经常走读自己的代码。我们做实验和界面设计也应如此。花时间清理技术债可以让代码更加持续可靠;清理UX债也会对我们的实验起相同作用。

开发者和产品负责人们:如果在每次迭代时花点时间解决界面的问题,而不是着急着开发新特性,那么UI和UX设计师们就可以松口气,放下意见和你们一起合作。

5、UX是一项综合技能和团队责任

UX的重要性决定了它不应该只由团队中的某一个人独立负责。

不能因为招募了一个敏捷专家就认为自己是敏捷团队。同样地,不能因为招募了一个UX设计师就认为自己在做以人为本的设计。团队中的每一个人都应该考虑到用户。UX设计师应该协调促进用户体验工作,而非独立负责用户体验。

6、犹豫不决时,参照精益用户体验原则

总之,用户体验研究不能急于求成,也不能不加约束。

研究的时间可长可短,重要的是将不同的研究区分开来,有些研究是为了解决当前特定的问题,另一些则是服务长远的策略。基础研究帮助你决策前进的方向,而定向研究将会逐步带领你到达那个地方。


更多译文:

好文案的5条指导原则:清晰为王
如何优雅地将可用性测试数据用于实践?
向APP用户请求权限的正确姿势
互联网设计的互惠原则:索取前请先给予
全部180+篇译文>>
申请加入UXRen翻译组>>

uxren-fanyizu-00


译者: 丫丫 审校: Dch King

作者:Ben Ralph

原文标题:《How to Stop UX Research being a Blocker——Fitting research into agile teams》

原文链接:https://medium.muz.li/how-to-stop-ux-research-being-a-blocker-225d91105de8

发布日期:Nov 12,2017

版权声明:

作者:13Tech
专注用户体验,只为UXRen

发表评论