用户研究和敏捷是不总是最好的朋友。敏捷开发通常侧重于构建功能,并将工作分解为小部分。用户研究并不总是与单个功能相关联,这使得它很难完全适应两周或三周的增量(典型的冲刺时间)。我们如何将用户研究适配到敏捷框架中?

敏捷中的用户研究是一个挑战

通常,在敏捷环境中,用户研究(例如用户访谈可用性测试,日记研究)的方法与团队构建新功能的方法相同:将其划分成小块的工作,从而产生一些有形的东西。

这种思维方式会带来许多挑战:

  • 研究跨越了多个冲刺阶段。团队不可能在一次冲刺中完成整个研究,而积压工作项在几个冲刺中仍然是开放的。
  • 研究结果在研究完成后没有被考虑。团队会从用户那里得到反馈,但这些反馈不会返回到待办事项列表中。
  • 这项研究没有产生任何有形的人工制品。利益相关者和团队不知道如何处理从研究中获得的知识,因为他们习惯于被提交已完成的设计或已准备好投入生产的代码。

因为所有这些挑战,UX研究经常会结束忽视或者在敏捷环境中完全放弃。

关注结果,而不是功能

在产品开发中,最大的陷阱之一是专注于输出结束结果-也就是说,在明确定义它们的目的之前,先讨论要构建哪些特性。这种思维方式优先考虑创建闪亮的功能,而不是理解交付给用户和业务的价值。

例如,像Venmo这样的应用程序可能会决定构建一个功能,将钱发送给另一个人,这样用户就可以轻松地在没有现金的情况下向某人付款。输出是要构建的功能:发送特性。结果是用户从中得到什么——另一种付费方式。为了理解我们正在解决的问题并弄清楚结果是什么,我们需要做用户研究。

敏捷的主要价值之一是响应变化而不是遵循计划。团队应该在整个项目中关注持续的发现——也就是持续的学习。研究应该是这种持续发现背后的驱动力,并且应该贯穿整个项目。许多团队认为研究是一个6周的项目或一个在开发之前的发现阶段随着项目的继续,永远不要再做研究了。但如果他们打算这样做,他们将在构建以用户为中心的产品方面取得更大的成功一些研究每一个冲刺。通过这种方式,他们总是在学习和完善他们的项目目标。

代表对待办事项的研究

就像设计和开发工作一样,我们需要代表了对我们敏捷backlog的研究成果.当研究工作没有反映在积压中,它们就会被忽视,不可避免地被忽略——眼不见,心不烦。

要记录对积压工作的研究,请执行以下步骤:

  1. 将研究工作作为一个单独的待定项添加到待定项中用户故事
  2. 将研究分解为小部分,并在研究待办事项项中添加相应的任务。
  3. 当你完成任务时,将它们标记为“已完成”,同时将研究待定项保留,直到所有任务都完成。

让我们来看一个例子。

例如:6人参与的可用性测试

对于这个例子,假设您想要进行6个参与者的可用性测试,以了解用户将如何(或不会)在您的应用程序中使用键盘快捷键。

为了完成这项研究,您需要完成以下任务:

  • 招募和安排每个参与者
  • 进行会话
  • 分析数据
  • 向利益相关者介绍调查结果

对于每个参与者,您可以向待定项中添加与招募、安排和管理会话相对应的单独任务。然后,您可以添加一个或多个数据分析任务,并将结果呈现给您的涉众。有些团队在数据收集的中途开始寻找模式,所以他们可能会在研究过程中分析数据并两次呈现一些初步发现。

sprint 3开始时的看板待办事项列表展示了三个栏目:“要做”、“正在做”和“已完成”。在To Do列中,有几个任务表示。在“正在做”和“完成”列中没有项目。
以下是sprint开始时的6个用户研究:用户测试:键盘快捷键是待定项的名称;中包含的几个任务要做列。因为我们的测试有6个参与者,所以有6个任务代表了与参与者相关的任何努力。在这种情况下,研究小组希望对数据进行分析,并将结果呈现两次。
sprint 3末尾的看板待办事项板显示了三列:待办事项、完成事项和完成事项。在待办事项列中,有几个任务表示尚未启动。完成事项列有一个打开的任务,完成事项列有几个已完成的任务。
在冲刺结束时代表相同的可用性研究:此时,团队已经招募并安排了3名参与者,正在招募和安排第四名参与者,并完成了一次可用性测试。

重要的是接受和交流这项研究的努力将在多个sprint中保持开放。对于某些利益相关者来说,这个想法很难理解,因此提醒他们,研究成果而不是产出——也就是说,它们提供的是目标和需求,而不是特征。问问自己,你是否离目标更近。如果是,那么你正在学习——这是一件好事!在sprint回顾中,你可以谈论研究进展如何g、 到目前为止,你可能已经听到了令人难忘的引语,以及接下来会发生什么。这种方法将强化这样一种观点,即研究一直在进行,并将继续获得认可。

sprint 4末尾的看板待办事项列表展示了三个栏目:“要做”、“正在做”和“已完成”。在To Do列中,仍然有几个未启动的任务。“执行”列没有打开任何任务,而“完成”列有几个已完成的任务。
代表下一个sprint结束时的6个用户研究:所有参与者都被招募并安排好了,一半的访谈已经完成,研究人员已经分析了前一半的数据。在sprint回顾中提出的发现可能包括一些初始模式或其他类型 进展报告

中点也是让涉众参与过程的绝佳机会!现在他们已经看到了一些早期的反馈,他们可能想要参与研究的后半部分——这是第一步让研究成为一项团队运动.如果你的研究进展很快,你不需要中途签到,但是你对过程越透明,你的团队和利益相关者就越有可能理解它给项目带来的价值。

一旦所有的任务都在这个待办事项中完成,这个研究工作就被认为已经完成,可以结束了。

根据研究结果更新积压工作

研究完成后,您可能会得到一个bug修复列表,用户体验的债务,潜在的新功能,以及未来研究的机会。这些都应该被导入到您的待办事项列表中,或者作为现有待办事项列表中的任务、要修复的bug或新的待办事项列表中。

在sprint review上展示研究结果后,提出此项目列表,以便将其优先排序并立即添加到待办事项列表中。由于您的利益相关者已经出席了sprint review,您无需要求他们再参加另一次会议。

不管如何你要把你的研究成果加入到待办事项列表中,确保你已经开始行动了。一个团队如果不处理收到的反馈,就只是发现了新的信息,而不是对变化做出实际的回应。

交流从敏捷研究中获得的经验

敏捷团队知道很多关于交付,但研究和持续学习应该同样重要。要克服在敏捷中进行用户研究的挑战,请记住:

  • 研究工作可能会跨越多个冲刺阶段。你所关注的用户目标可能会影响到不止一个功能,所以在sprint审查期间,你要清楚研究是如何推动团队前进的。在研究进行的时候经常交流,会建立信任和共同点
  • 将研究结果反馈到backlog中。对于在敏捷环境中构建可行的软件来说,持续发现并响应变化是很重要的。确保团队不仅要听取用户的意见,还要回应他们的需求。
  • 研究以学习的形式而不是有形的人工制品为团队提供价值。从您的研究中获得的信息将为即将到来的特性提供信息,构建需求和接受标准,并帮助您了解用户。这些都是推动团队前进并提供价值的东西。

参考

Josh Seiden,2019年。结果高于产出:为什么客户行为是商业成功的关键指标。感知与回应出版社,美国。