Miro持续发现会话运营指南:10分钟轮换机制与生态效度实践
Delivering Continuous Discovery Programs That Run like Clockwork
持续发现(Continuous Discovery)并非替代深度访谈或可用性测试,而是通过高频、结构化的用户接触填补产品决策中的验证空白。Miro柏林办公室的实践表明,该模式的核心在于“时间约束即特性”:每场会话邀请5名活跃用户,与5个产品团队进行10分钟轮换交流。这种压缩的时间框架模拟了真实世界中用户在认知负荷下扫描和处理信息的状态,比受控的一对一研究更具生态效度,能暴露界面元素对用户行为的实际引导作用与团队假设之间的差距。
为确保会话如钟表般精准运行,需建立标准化的运营体系。人员配置上,除5组由面试官和记录员组成的内部团队外,还需一名主持人及两名支持人员处理接待与突发状况。招募策略强调“超额招聘”,建议确认10名用户以应对缺席风险,并设立并行工作坊消化多余参与者。用户画像无需细分,仅需“活跃用户”,因为单一小时内面对五个不同议题时,特定受众筛选反而降低效率。
后勤细节决定体验成败。固定于周四下午5点举办,营造社交氛围;提前预订披萨并在中场送达,利用食物作为打破僵局的“门把手时刻”,促进非正式反馈收集。现场必备可视计时器、NDA纸质备份及简易反馈表单。
该实践详细拆解了持续发现活动的运营细节,包括人员配置、招募策略及现场流程,为建立可复用的用户接触机制提供了具体操作指南。
在柏林的第一场活动中,我绝对是那个忙得满头大汗的人。那是 2025 年 3 月,我手里拿着打印好的检查清单,在办公室里跑来跑去,确保一切就绪:产品用户、我的同事、桌子、计时器,当然还有披萨。我们邀请的一些用户没有到场,所以我冲进大楼的公共区域,试图招募任何在走廊里休息的人来参与。大多数人礼貌地拒绝了,我并不怪他们。如果一个浑身是汗的陌生人提供披萨,以换取我和一家我从未听说过的公司聊天——Miro 是谁?——我也不知道该如何回应。
最终,在活动开始前五分钟,同一栋楼的一位办公室经理邀请我去他们的办公室问问:您愿意参加一个与 Miro 的产品构建者进行的一小时持续发现会话吗?我准时带着两名额外的参与者回来了;我永远忘不了我和同事 Anthony 之间那种如释重负的眼神交流。
在这篇文章中,我将分享如何建立使持续发现会话像时钟一样精准运行的运营流程,以及这些会话可以带来的价值。我会带你了解应该邀请谁,你需要做什么才能在不同地点和远程环境中创建可重复(且可持续)的设置,以及那些可能决定活动氛围成败的小决策。
编者注:本文最初发表于 The ResearchOps Review,你可以在这里阅读。
持续发现方法
产品发现教练 Teresa Torres 创造了 持续发现 这一术语,用来描述在产品开发中建立定期、结构化的用户接触的实践,从而使洞察不再是通过他人进行的临时研究一波波地到来,而是持续流动——并持续建立同理心并为产品决策提供信息。
就在一年多前,当我首次在 LinkedIn 上宣布我们在 Miro 的柏林办公室启动一个持续发现计划时,有人留言称这是所有研究问题的终极解决方案。我当时的回复反映了我今天依然坚持的观点:持续发现是一种从用户那里收集证据的方法论,但它不能替代其他研究方法,如用户访谈或可用性测试。尽管如此,当做得好时,这些面对面的、披萨驱动的计划可以帮助以客户为中心的程度取得进展,这是其他方法往往无法做到的。
从宏观层面来看,持续发现会话的运行方式如下:每月一次,你会邀请五位产品用户到你的办公室,花一个小时参加与五个不同产品团队进行的简短十分钟访谈,每个团队有一名访谈员和一名记录员。每个团队可以利用他们的十分钟询问关于其产品领域的问题或测试设计。每十分钟,用户顺时针轮换到下一张桌子,接受由不同团队提出的新一组问题。在一个小时结束时,每个团队都与每位用户进行了交谈,每位用户也对五个产品想法发表了意见。这种氛围不像图书馆或研究实验室那样安静,而是社交性的、有趣的(有时也很吵闹),并且总是以披萨结束。
持续发现会议常被视为一种随意或非正式的研究——其有效性不如,比如说,一对一访谈。是的,从设计上讲这些会议是非正式的,但持续发现有其立足之地。它既不是生成性的(对问题空间中直觉的开放式探索),也不是纯粹评估性的(在解决方案空间中严谨地收集证据)。相反,它处于中间位置:稍微偏向验证一侧,而大多数产品决策实际上就发生在这里,并且需要快速而非完全地减少不确定性。当需要进行深入诊断时,或者处理敏感话题或需要严谨性的高风险验证时,这通常不是一个好的方法论选择。但对于早期产品想法、粗略原型和假设检查来说,是一个不错的选择。
时间限制是一个特性,而不是缺陷
我们从同事那里最常收到的反馈是,与每个用户相处的时间不足以让他们想深入挖掘的那样深——当你有很多内容要覆盖时,十分钟可能感觉很短。但时间限制不仅有助于让尽可能多的团队成员接触到尽可能多的用户。
线下的持续发现会议比受控的一对一研究更接近生态效度——即研究条件与行为通常发生的现实世界背景的相似程度。我逐渐相信,没有人会以可用性测试参与者的耐心来对待新功能。人们对待应用程序或任务的方式就像对待其他一切事物一样:心不在焉、半心半意,也许还很匆忙。一段压缩的时间来探索产品,反映了用户在野外遇到你的产品的典型方式。他们在认知负荷下扫描、处理和做决定——情况类似于在繁忙的房间中只有有限的交谈时间——并不一定会给你的应用或他们的任务全神贯注。面对数百个其他标签页、应用、任务和争夺他们注意力的人,他们怎么会做到呢?
十分钟的时间限制也揭示了注意力的真实层级。团队亲眼看到哪些界面元素真正引导了行为,而不是他们的假设;观察到的与假设之间的差距正是持续发现的大部分价值所在:最诚实的发现出现在用户没有时间保持礼貌的时候。
深入而非广泛
对于从事研究工作的人(PWDR)1来说,选择一两个问题问参与者并深入而非广泛地展开范围可能是一个挑战。这就是为什么在会议开始前与同事就研究设计和范围达成一致至关重要——在活动过程中重申对齐目标也是合理的。
即使面临只选择一两个问题的挑战,团队很少会带着毫无可探索的内容进入持续发现会议:总有一些他们需要验证的东西,无论是草图、原型、氛围编码的想法,还是他们想在推向生产环境或暂停以进行更多研究之前测试的假设。他们很少需要统计置信度;他们寻求的是足以做出下一个决定的信号——我喜欢称之为方向性指导。老实说,有时他们只是需要验证以求心安,或者只是想提高他们的访谈技巧。无论如何,这种格式是为团队需要解除阻塞的具体时刻量身定制的。
虽然 PWDRs 可能会觉得时间限制令人窒息,但对用户来说,这是一个特性而非缺陷;他们可以利用一小时的时间探索一些新的产品创意,并结识希望向他们学习的新朋友。这既具有社交性又充满乐趣。
招募、角色与职责
也许你现在已经确信这些会议将成为你研究工具包中有价值的补充;现在你需要知道如何组织它们。要运行一次持续发现会议,总共需要十八个人:十位同事组成五个“团队”,每个团队有一名访谈者和一名记录员,五位产品用户,以及由以下人员组成的支持团队:
- 一位负责人来主持和展示会议。
- 一位支持人员负责接待工作,欢迎用户,并在出现意外情况时协助主持人。
- 另一位支持人员在有多余用户时负责并行工作坊,或在发生任何意外情况时介入。
如果你只能找到另一位同谋者,你们可以分担这些职责。虽然稍微不那么舒适,但仍然是可行的。
招募同事
产品设计师、产品经理、工程师和数据分析师是这些会议最自然的人选,因为他们的工作往往最能从简短且频繁的用户检查中受益。但随着时间推移,拥有各种职位头衔的同事也可能加入会议:客户成功经理、市场营销和社区专业人员。基本上,所有工作中涉及思考用户的人都适合参加。
吸引同事的关键在于在最相关的沟通渠道中传达清晰的信息,说明持续发现会议何时举行、包含哪些内容、参与的好处以及如何报名。对于初次参与者来说,整个体验可能令人望而生畏,因此我们还在注册页面上提供了一套简短的注意事项、访谈技巧和笔记模板。此外,我们提供一个简短的准备电话,向他们讲解角色和职责,询问他们想要测试什么,并解释如果有问题该怎么做。这些信息通常能安抚那些不擅长与用户交谈的人的紧张情绪。我们还保留了一个候补名单,因为五个名额通常会很快满员,而且偶尔有人在活动开始前改变主意。
招募产品用户
这是少数几种招募对象画像并不重要的情况之一。你只需要招募“活跃用户”,仅此而已。原因如下:你的用户将在一小时内接触到五种截然不同的想法,因此没有必要寻找特定的画像。如果其中一个团队坚持认为他们确实需要特定的受众群体,那么持续发现会议可能不是正确的方法。在这种情况下,帮助他们找到适合其问题的正确方法。
最后,为了确保当天不缺用户,请从我那汗流浃背的柏林办公室冲刺中吸取教训:超额招募。目标是确认十位用户而不是五位。虽然超过五位用户从来都不是问题,但如果到场人数少于五位,团队就会等待却无人可谈,从而破坏所有人的会议动态。我们经常确认远超十位参与者,并运行一个并行的共创工作坊,由我们的研究人员之一主持,将多余的用户转化为实时协作的机会,并邀请同事参与其中。
要找到用户,如果你有标准的参与者招募流程,请遵循该流程。你也可以使用以下策略:
- 当你招募在你举办活动的城市居住的人时,LinkedIn 帖子可以是一个有效的补充。
- 起草一条简单的消息,让你的同事在他们的网络中分享;这种传播效果出奇地好。
- 利用与你的产品或服务相关的论坛和用户社区。
- 考虑打印二维码并贴在朋友的办公室。
- 请办公室经理邀请他们担任相关角色的员工参加。
- 最后,作为最后的手段,不要忘记家人和朋友始终如一的宝贵帮助。
整合招募运营的最有效方法是创建一个单一面板供产品用户注册。不要把它搞得太复杂;一个要求提供姓名和联系方式的简单表单就足够了。如果你能访问像 Luma(见图 1)这样的专业活动工具,用它来处理候补名单、提醒和取消等繁重工作。无论你最终使用什么,请务必详细说明如何到达你的办公室以及预期情况。

为(可重复的)成功做好准备
一旦你成功招募了所有参与者,你需要协调和准备一些基本事项。大多数物品可以在不同场次之间重复使用,只需一次性投入时间和最少的预算。以下是必备清单:
- 一个实体房间。 不要太挑剔。确保房间能舒适地容纳五张桌子,每张桌子有足够的空间坐三个人——两名团队成员和一名用户。如果桌子是会议室长度的,请在桌子的两端分组。我们在办公室的午餐区举行会议,因为那里空间充足且桌子易于移动。提前预订空间,并确保有屏幕可用于共享幻灯片演示文稿。
- 一份演示文稿。 制作一个简短的幻灯片演示文稿,涵盖你和你的团队是谁、议程是什么以及互动方式如何运作(其中大部分内容你可以直接从本文中借用)。
- 保密协议 (NDA) 表格。 打印大量表格,确保用户签署它们,然后就把这事抛在脑后。你也可以在招募、确认和提醒电子邮件中提前发送 NDA,但人们通常不擅长提前签署,所以务必在办公室保留纸质副本,以备未签署者使用。
- 一支 Sharpie 记号笔和名牌。 去文具柜搜刮一下;拥有比需要的更多总是更好的。
- 一个计时器。 你可以使用任何计时器,但我们是自认极客的人,所以我们喜欢 Jake Knapp 的 Design Sprint clock。无论你使用什么,确保它对团队可见,以便他们可以关注自己的时间。
- 披萨。皇冠上的明珠,也是这项工作中唯一反复出现的财政投入。经过多次迭代,我们得出结论:合适的数量是六个大号或八个小号披萨。务必包含一个无麸质披萨。意大利辣香肠、松露和瑞可塔奶酪等配料格外令人印象深刻。提前订购并安排配送在会议进行到一半时送达:届时你几乎无事可做,因为各轮讨论正在进行中,而当会议结束时,披萨依然热气腾腾、酥脆可口。
- 反馈表。你需要一份面向参与者的反馈表(在演示文稿末尾附上二维码);让大家在享用披萨时将其留在显眼处,并在感谢信息中再次发送。你也应该向同事发送一份反馈表。保持几个基本问题最为有效:保留什么、改进什么以及增加什么。
我们不针对持续发现会议的参与者提供金钱激励。通过让用户了解我们正在开展的工作、与我们共同创造未来的解决方案、带走一些周边礼品、会后收到活动照片,当然还有在饮食中进行社交,我们就已经获得了足够的报名者。
时机就是一切
我们发现周四下午 5:00 效果最佳:这是周末前的良好铺垫,也是标准下班后聚会的强劲竞争对手。我们还让它看起来和感觉起来像是一场社交聚会。
一旦日期确定,请在日历中创建两个事件:
- 一个是给同事的,比活动开始时间提前三十分钟,以防有最后一刻的问题或需要协助布置房间。此外,在用户到达前让团队所有成员聚集在房间里至关重要:你们将准时开始,并向用户展示他们进入的是一个尊重他们及其时间的场合。
- 第二个邀请是给用户的。在日历邀请中,将活动开始时间设定在正式启动前十五分钟。这段缓冲时间对通勤者大有裨益,并能保护你的开始时间。
在开始时间前一小时,确认所有参与者仍会参加。完成房间布置:五张桌子,每张三把椅子,或者沿长桌分布五个编号位置(提前为桌子或位置编号会使分组分配容易得多)。在桌子上放置水和零食(可选附加项)。测试技术设备,确保你的演示文稿和计时器可见。订购披萨并安排配送。
在开始时间前三十分钟,与当天的核心活动团队会面,一起过一遍 检查清单。一切就绪后,支持人员可以前往接待区欢迎产品用户。
设计“门把手时刻”
在一小时结束、最后一场会议完成后,供应披萨是团队和用户自然重拾那些没时间跟进的话题的完美桥梁。这相当于在主持式访谈中停止录音,却突然听到用户敞开心扉谈论之前未显现的内容——这是我从史蒂夫·波提格尔的经典著作《Interviewing Users》2中学到的技巧,他在书中写道:“医生和治疗师熟悉‘门把手现象’,即关键信息往往在患者即将离开时才被揭示。”
所以,要有意识地在你的活动中设计“门把手时刻”。我们旨在将空间收窄,以便同事和用户必须穿过人群才能拿到披萨,从而更自然地开启对话。确实有些人喜欢利用这段时间快速汇报甚至当场做出决定,但我们总是确保自己是第一个开始交谈的人。

最后,我们还创建了一个简单的仪式作为活动的记录:在吃披萨时拍一张集体自拍(见图 2)。这张照片对于通过社交媒体招募新参与者加入未来的活动也非常有用。
两件本应奏效却失败的事
回到我在文章开头提到的柏林活动。除了开始得晚之外,我们还决定以破冰游戏开场,让每个人自我介绍:分享你的名字以及你会选择的一种超能力,或者类似的内容。我们这样做了十五次(每位同事和产品用户一次),浪费了大量时间,并在活动开始前就让所有人感到不知所措。简而言之,取消破冰游戏,让名牌发挥作用吧。
此外,由于产品用户是我们的贵宾,我的直觉是让他们坐在同一张桌子旁,而同事们则移动到新的用户那里。毕竟,我喜欢体贴待人。但这个决定带来了意想不到的代价。移动五个同事团队比移动一个用户更具破坏性,而且当团队眼中流露出“再问一个问题”的神情时,情况只会变得更糟。相比之下,当你要求用户移动时,他们通常不会反对,团队也不会抱怨这种移动。这效果出奇地好。
将信号转化为行动
我一直告诉周围的人,如果你不投入足够的精力去激活研究发现,那就好像研究从未发生过一样——持续发现会议也是如此。我们有四种机制来帮助确保团队跟进他们所学到的内容:
- 轻量级文档记录。 活动结束后第二天,各种聊天频道中会弹出一条自动消息,提醒同事使用我们准备好的模板整理出“三大收获”幻灯片(见图 3)。我们将此幻灯片包含在我们的月度 UX 研究通讯中。
- 交叉传播。 我们审查研究发现,将其分发到关键渠道,私信个人,并经常在发现重叠的团队之间安排会议。我们相信研究发现可以充当团队之间的粘合剂,帮助公司专注于用户而非其内部组织结构图。
- 连续性。 有时团队意识到他们学到的东西还不够,或者问题比他们预期的更大。发生这种情况时,我们会支持他们进行专门的后续研究,或将该问题纳入我们自己的研究路线图。
- 赞美,赞美,再赞美。 第一次和第二次运行持续发现会话时,同事们可能会出于新鲜感而加入。但在某个阶段,他们会意识到这些会话在日常工作之外增加了额外的工作量,因此参与度可能会停滞。为了应对这种自然的衰退,我们在相关对话中提及同事的名字,强调他们花了时间与用户交谈,并肯定这样做的积极影响。这也将他们树立为团队内的榜样。最后,在征得他们的同意后,我们会在公司的外部社交媒体帖子中标记他们,因为谁不喜欢一点个人曝光度的提升呢?
这就是我们所做的全部。我们不会催促人们根据发现采取行动,也不会要求他们解释所做的产品决策。对我们来说,只要同事们接触到用户并且他们的假设受到挑战,哪怕只有一个小时,就已经足够了。

跨地点扩展
Kate Towsey 的书 Research That Scales,3 以题为“研究无法扩展——系统可以”的章节开篇,我完全同意这一观点。我们,即 Miro UXR 团队,所构建的正是这样一个系统:一个持续发现研究系统,让我们能够以快速、低成本的方式对用户进行有主持人的线下定性访谈。我们的系统——也就是我刚分享的系统——现在非常有效,一旦你建立了可复用的资产,你就可以在许多地点运行持续发现会话。如果你或你的核心团队无法前往特定地点,你可以轻松地培训其他人复制这种格式。在我们的案例中,我们从柏林开始,将持续发现引入阿姆斯特丹,然后我们让设计团队的人员在我们东京办公室运行他们自己的版本。
运行远程会话
虽然持续发现在线下效果最好,但我们也成功运行了远程版本,尽管格式显然不同。远程版本每周运行一次而不是每月一次,旨在一天内让五个用户面对单个团队。我们在周三运行它,这是 Miro 的无会议日,因此不会与任何人的日历冲突。如果你能在组织的日历中找到类似的机会,请加以利用。
在远程持续发现的情况下,参与者招募可以更加具体。用户不是在五个想法截然不同的团队之间轮换;他们只与一个产品团队交谈。因此,如果团队希望与特定画像的用户会面,这里也是实现这一目标的地方。其余部分与线下版本基本相同。你会提前与团队会面,以帮助制定研究计划和讨论指南。他们使用你已经拥有的任何有主持人研究工具来运行会话,并且在白天留意你的即时通讯应用,以防出现意外情况。
如果可以的话,同时运行线下和远程会话。它们并不竞争。事实上,它们以非常好的方式互补。线下版本创造了节奏(每月的频率成为已知的组织节拍)和社会认同(由披萨推动),而远程版本则提供了探索针对性问题的机会。如果你想举办线下活动但没有实体办公室,联合办公空间也可以,愿意借给你房间的合作伙伴组织同样可行。
打破孤岛,建立共情
持续发现以其他研究方法无法做到的两种方式推动变革:它打破了孤岛并建立了共情。让一位客户成功经理、一位工程师和一位产品设计师坐在相邻的桌子旁,并给予他们聆听同一批产品用户的机会,这种方式能激发彼此对对方问题的好奇心,这是消息渠道永远无法做到的。我见过更多跨团队协作努力始于一块披萨,而非任何对齐会议。
同事们离开持续发现会议时,对用户需求的感知更加敏锐,并且更好地理解 UX 研究团队的工作及其重要性。这种第二种形式的共情是无人计划的好处,也是改变组织对待研究方式的因素。团队不再将研究视为瓶颈,而是成为倡导者,因为他们终于有了一种低风险的方式来实践“以客户为中心”。一旦你围绕某人已经想做得好的事情创造了轻松氛围,他们下个月回来就不需要被说服了。
原作者保留版权;来源:User Interviews。本站维护者确认获准转载,非公共领域或开放许可证声明。 原文来源(转载授权由站点维护者确认) · 中文译文由 CxHub 客户体验社区生成,并非官方译文。
来源:User Interviews · userinterviews.com