用户研究和敏捷是不总是最好的朋友.敏捷开发通常侧重于建筑功能,并将工作缩小成一口大小的碎片。用户研究并不总是与单个功能相关联,这使得很难完美地符合两周或三周的增量(典型的冲刺持续时间)。我们如何将用户研究拟合到敏捷框架中?

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

通常,在敏捷环境中,用户研究(例如用户访谈,可用性测试,日记研究)方法与团队构建新特性的方法相同:将其划分为可产生有形内容的小块工作。

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

  • 研究跨越了多个冲刺阶段。团队无法完成单个Sprint中的整个研究,积压项目仍然在几个冲刺中仍然开放。
  • 研究完成后,不考虑研究结果。团队从用户那里得到反馈,但这些反馈并没有反馈到待处理的待办事项列表中。
  • 没有参赛的有形工件。利益相关者和团队不知道如何处理从研究中获得的知识,因为他们习惯于将已完成的设计或已准备好投入生产的代码交给他们。

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

关注结果,而不是功能

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

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

敏捷的主要价值之一是应对变化按照一个计划进行。团队应在整个项目中专注于持续发现,即持续学习。研究应该是这一不断发现背后的驱动力,并且应该贯穿整个项目。许多团队将研究视为一个为期6周的项目或一个项目开发之前的发现阶段随着项目的继续,永远不会再进行研究。但如果他们的目标是这样做,他们将更成功地建立以用户为中心的产品一些研究每一次冲刺。通过这种方式,他们总是在学习和完善他们的项目目标。

代表对待办事项的研究

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

要记录积压的研究,请按照下列步骤操作:

  1. 将研究工作作为一个单独的待定项添加到待定项中用户故事
  2. 将研究分解为Bite-尺寸的作品,并在研究积压项目中添加相应的任务。
  3. 在完成任务时,将任务标记为已完成,同时保持“研究积压工作”项目处于打开状态,直到所有任务完成。

让我们看一个例子。

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

在本例中,假设您希望对6名参与者进行可用性测试,以了解用户将(或不将)如何在应用程序中使用键盘快捷键。

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

  • 招聘和安排每个参与者
  • 进行会话
  • 分析数据
  • 提出利益相关者的调查结果

对于每个参与者,您可以向积压工作中添加与招聘、安排和执行会话相对应的单独任务。然后,您可以添加一个或多个用于数据分析的任务,并将结果呈现给您的利益相关者。一些团队在数据收集的中途开始寻找模式,因此他们可能会分析数据,并在研究过程中两次展示一些初步发现。

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

重要的是接受和交流这项研究的努力将在多个sprint中保持开放.这个想法很难让一些利益相关者掌握,所以提醒他们,研究努力提供结果,而不是产出 - 也就是说,他们提供目标和需求,而不是特征。问自己,如果你更接近你的目标。如果是的话,那么你正在学习 - 这是一件好事!在Sprint审查中,您可以谈谈研究如何,到目前为止,您可能听到的令人难忘的报价,以及下一个即将到来。这种方法将加强研究始终如一的事情,并将继续建立买入。

Sprint4末尾的看板待办事项板显示了三列:待办事项、待办事项和待办事项。在“待办事项”列中,仍有几个任务尚未启动。“执行”列没有打开的任务,“完成”列有多个已完成的任务。
在下一次冲刺结束时代表6位用户的研究:所有参与者都已被招募和安排,一半的访谈已经完成,研究人员分析了前一半的数据。sprint回顾中的发现可能包括一些初始模式或其他类型的 进度报告

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

一旦在这个积压项目中完成所有任务,就考虑了这项研究工作,可以关闭。

基于研究发现更新积压

研究完成后,您可能会得到一个bug修复列表,用户体验的债务,潜在的新功能,以及未来研究的机会。这些都应该汇回到您的积压 - 作为现有积压项目的任务,修复的错误或新的积压项目。

在Sprint Review的研究结果演示后,将此项目列表提交,因此它可以立即优先顺序并将其添加到积压中。由于您的利益相关者已经存在于Sprint审查,因此您不需要要求他们参加另一个会议。

不管怎样你把你的研究结果加入到待办事项中,确保你是按照这些结果行事的。一个团队如果不处理收到的反馈,只会发现新的信息,而不会对变化做出实际反应。

交流敏捷研究的经验教训

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

  • 研究工作可能会跨越多个冲刺阶段。你关注的是可能会影响不止一个功能的用户目标,因此,在sprint评审期间,对研究如何推动团队前进保持透明。在研究进行过程中经常沟通,将有助于建立信任和信任共同点
  • 将研究结果反馈到backlog中。对于在敏捷环境中构建可行的软件来说,持续发现并响应变化是很重要的。确保团队不仅要听取用户的意见,还要回应他们的需求。
  • 研究以学习的形式为团队提供价值,而不是有形的伪影。从您的研究中学到的知识将告知即将推出的功能、构建需求和验收标准,并帮助您了解用户。这些都是推动团队前进并提供价值的因素。

参考

乔希塞登。2019年。输出结果:为什么客户行为是商业成功的关键指标。感觉与响应新闻,美国。