产品用户大会：议程与组织

如何组织产品用户大会：路线、案例、实践、发展计划、问答及会后资料。

产品用户大会适用于公司希望围绕解决方案的实际使用聚集外部社区的情况。仅仅发布新功能是不够的。参与者需要同事的案例、实践、与产品团队的对话、经验交流以及会后明确的后续安排。

我们在Aventura从用户路线开始：每个群体应理解什么、尝试什么并带回工作中。我们根据这些成果来搭建舞台、实践和咨询环节。产品事实和发展计划由客户团队确认。

如果产品用户大会已在计划中，请索取报价并讨论形式。初次沟通只需说明产品、主要用户角色、议程任务、城市及预计参与形式。

什么是产品用户大会？

产品用户大会是针对那些选择、实施或日常使用特定解决方案的人所举办的外部活动。议程将产品背景、用户经验和实践相结合。

这种形式通常被称为用户大会（user conference）。英文名称在产品团队内部很方便，但对受邀者来说，更重要的是明确的承诺：他能梳理哪些任务，亲自尝试什么，以及与谁讨论自己的情况。

Atlassian Team Europe 和 Salesforce Dreamforce 的议程将产品发布与客户案例、实践课程、咨询和社区交流相结合。录像和材料在线下部分结束后继续发挥作用。这对架构来说是一个有用的参考，尽管不能把别人的日程当作通用规范来复制。

大会有四个成果：

• 用户了解哪些功能与其角色和任务相关；
• 参与者通过案例、演示或实践至少验证一个场景；
• 问题获得背景、负责人和状态；
• 活动结束后留下材料以及与所参加路线相关的下一步。

我们负责活动的议程和制作：从注册到场地运营。客户团队确认产品论点、披露规则和对用户的回复。

与五种相邻形式的界限

主要区别在于受众构成和预期结果。用户会议围绕一个产品的应用展开；合作伙伴、内部和研究形式则解决其他任务。

在制定方案之前需要明确界限。如果受众范围比特定解决方案的用户更广，请从关于客户B2B活动的指南开始。如果参与者需要对一个工程任务进行深入学习，那么客户技术研讨会更有用。

内部产品日从内部讨论公司的工作：产品组合、依赖关系、研究和产品团队的决策。产品用户会议则是对外的。用户可以讨论相同的开发方向，但不参与内部产品组合决策，也无法接触整个产品后台。

CAB可以作为独立的闭门会议融入大会。这类会议的参与者需提前确定，主题应表述为研究任务，而反馈会被分配负责人和状态。没有固定参与者的普通VIP晚宴或圆桌会议不应称为CAB。详细的界限在关于客户咨询委员会的文章中进行了分析。

经销商会议与渠道合作。用户会议则与最终用户对产品的应用有关。混合会导致议程模糊：一些客人期待商业条件，另一些则想分析工作场景。针对合作伙伴形式，有关于经销商会议议程的单独材料。

如何将受众划分为不同路线？

路线取决于参与者的角色、经验和工作任务。这三个特征影响内容的深度和会议形式。

从那些会改变议程的细分群体开始。职位名称本身并不能很好地说明需求。小型实施项目的负责人和成熟产品项目的负责人可能会选择不同的路线。某个解决方案版本的管理员并不总是适合另一个环境的实验室。

有效的细分使用四个维度：

基于这个矩阵，组合出几条精心策划的路线。例如：“首次实施”、“成熟环境管理”、“集成与扩展”、“客户方产品负责人”。参与者可以更换个别会议，但能看到现成的框架。

注册只收集会改变路线的数据：角色、经验、感兴趣的场景和便利条件。技术信息仅在预先确定的任务中询问，并转交给指定的负责人。表单和签到的完整流程在关于活动参与者注册的文章中有详细说明。

如果需要将细分群体、议程流、场地和技术限制整合为一个统一方案，提交报价申请。我们将帮助围绕用户行为而不是随机的演讲清单来构建议程和执行方案。

对于大型全体环节和并行议程流，我们采用会议组织的方法：统一时间安排、分会场主持人、清晰的转场、技术方案以及每个环节的结果收集。这样参与者就不会在主舞台、实践和咨询之间迷失自己的路线。

议程矩阵与当日节奏

议程应交替安排讲解与实操。在共同环节之后，参与者转向案例、练习或与专家交流。

首先，明确用户在会议结束后需要发生哪些改变。“了解了新功能”过于模糊。更有用的是：选定了合适的场景、在培训环境中验证了设置、与同行比较了流程、向产品团队提出了问题，或制定了试点计划。

议程矩阵可以如下所示：

不要连续安排多场冗长的演讲。在参与者聆听的环节之后，给他们比较、尝试或提问的机会。

可用的顺序可以如下：

1. 提供产品、主题与路径的整体地图。
2. 结合实际应用场景展示更新。
3. 按案例和成熟度对受众进行分组。
4. 举办有可观察结果的实验室或诊断会。
5. 按角色或任务组建经验交流小组。
6. 标明发展方向和确定程度。
7. 通过答复、状态或验证路径解决遗留问题。
8. 让每个人确定自己的下一步。

各环节之间的缓冲时间用于转场、提问和咨询。不能将其视为空档。如果实验室与下一场必修报告同时结束，参与者要么放下手头工作，要么会迟到进入会场。议程应考虑舞台、实操区和洽谈室之间的实际动线。

不含广告宣传的用户案例

优秀的用户案例会展示任务、限制条件和经过验证的结果。没有初始条件，故事很快就会变成广告。

筛选案例时，请先问一个简单的问题：其他用户能否理解在自己的条件下需要验证什么？一个知名标志无法弥补空洞的故事。一个坦诚分析限制条件的小项目，有时比只留下笼统成果的大型报告更有价值。

演讲框架：

1. 在允许的范围内说明用户和流程。
2. 描述项目开始前的原始问题。
3. 展示限制条件：数据、集成、期限、能力或监管要求。
4. 解释曾考虑过哪些方案。
5. 按阶段拆解所选路径。
6. 说明在推进过程中不得不做出哪些调整。
7. 展示经过验证的结果及其衡量方式。
8. 将可复用的做法与具体情境的细节区分开来。
9. 以团队的下一步行动收尾。

在 AWS 的客户故事中，经常能看到一个简单的框架：最初的困难、解决方案、结果。如果要搬上演讲台，还需要补充限制条件和失败转折，否则因果关系会显得过于顺滑。

我们会和演讲者一起提前准备报告。把标题作为用户任务来检查，梳理三个主要结论、流程图和允许公开的材料。排练不是为了统一手势，而是为了检验：没有参与项目的人能否理解其中的决策逻辑。

如果结果无法公开，就要对案例进行匿名化处理，或改用教学场景替代。不能为了增强说服力而编造数字。“降低”“加快”或“提高”这类说法，同样需要清晰的比较基准和客户确认。

如何安排实操环节？

实操环节围绕一个具体动作和可验证的结果展开。如果参与者只是观看主持人操作，那这只是演示。

这里的主动学习原则很简单：参与者自己完成一步并获得反馈。Cornell 将讨论、探究、创造和解决问题归入此类学习。

我们为每个工作坊准备一份说明卡：

形式取决于成熟度。分步工作坊按照同一流程引导小组。自主工作坊只给出任务和标准，路径由参与者自行选择。

针对具体问题的分析以诊所形式开展。对现有流程的共同分析有助于看清解决方案的架构，而简短咨询则安排在预先设定的时段进行。

不能先选定场地再拼凑实操环节。工位数量、供电、网络、音响、家具和安全通道都会影响容量和轮换。寻找场地时可以从场地目录入手，但最终是否适用要以结合技术图纸的实地查看为准。

工作坊的衔接环节要在彩排中检查：权限发放、环境启动、操作讲解、帮助进度落后的参与者、故障恢复以及过渡到下一环节。完整技术走查的总体流程在活动技术彩排指南中有说明。

产品发展规划与不设承诺的反馈

发展规划展示产品的方向和团队的确定程度。处于验证中的想法不能当作已承诺的版本发布。

GOV.UK 将发展规划描述为产品可能的方向，它会随着优先级变化而调整。这份文档有助于展示未来的工作，以及团队当前有意不做的事情。对于场景而言，这比日历更有用，日历中每个日期都看起来像承诺。

方便的标记方式：

• 已发布： 功能可用，可以演示并配以文档。
• 当前： 工作有较高的确定程度，但不给出未确认的日期。
• 下一步： 优先问题或预期结果；解决方案仍在明确中。
• 正在验证假设： 团队正在收集数据和反馈。
• 当前不在计划内： 预期的边界已明确说明。

对于每个方向，展示用户问题、目标受众、预期结果、依赖关系、风险和修订因素。原型必须有明确的状态标记。不能把它设计得和已发布的功能一样。

首先收集简短的个人回答或按标准投票。然后进入集体讨论，并明确价值条件、实施风险和必备要素。没有角色、场景和后果的“添加功能”请求仍然是一个过于贫乏的信号。

在信号卡片中记录角色、问题、背景和验证负责人。可能的状态：已接受、需要数据、已转交负责人或已答复关闭。

演示、问答与用户间交流

演示、问答和经验交流最好分成独立的环节。否则个别问题会挤占议程，而问题也会失去上下文和负责人。

演示需要一个论点、一个脚本和一位上线负责人。另外要准备屏幕上安全的数据，以及能佐证同一论点的备用方案。

提问时需连同上下文一并记录：

• 用户的角色和任务；
• 版本或环境（如需要）；
• 已执行的操作；
• 预期结果；
• 允许的回复方式；
• 负责人和状态。

群发消息不能替代承诺的单独回复。如果问题涉及客户数据，讨论将转入闭门咨询。在台上，主持人可以给出安全的通用原则，并说明后续跟进方式。

经验交流环节需要主题和引导。Cornell 将协作学习与小组工作、讨论和共同解决问题联系起来。对于专业受众，分组依据角色、行业、规模、实施阶段或场景。参与者会获得一个上下文模板，并有权不透露敏感细节。

这类会议的工作流程如下：

1. 每位参与者说明自己的角色和一项任务。
2. 大家按简短模板分别记录上下文。
3. 小组分析若干情况。
4. 引导者指出反复出现的障碍，但不涉及多余的个人数据。
5. 仅在自愿同意的情况下交换联系方式。

自由社交可以保留作为附加层。它不能替代主题交流，尤其当受众众多且彼此还不认识时。

混合模式、可访问性与数据

混合形式是两条相互关联的路径，而不是从会场进行的直播。线上参与者需要能够访问演示、提问、小组协作和材料。

我们从筹备之初就将可访问性融入场地、平台和材料中。W3C建议提前考虑现场、远程和混合参与者。Section508.gov还强调了文档、网站的可访问性，以及在邀请函中请求特殊条件的方式。

最低限度的混合层包括：

• 为所有参与者提供统一的目录和材料；
• 在线主持人，负责代表远程观众提问；
• 用于会场提问的麦克风；
• 公共问答渠道；
• 演讲时提供可访问的幻灯片和链接；
• 所选格式下的字幕和经过审核的录像；
• 如果有现场交流环节，则设立单独的在线交流室；
• 备用通信、本地录制和材料的替代发放方式。

对于拥有完整远程观众的活动，我们会将混合活动组织为两条相互关联的路径。会场后方的摄像头无法提供对界面、提问和小组讨论的平等访问。

对于现场部分，要检查从入口到参与者座位的路径：通道、座位安排、音响效果、灯光和帮助点。对于材料，要检查结构、对比度、文本大小和替代描述。

NIST的联邦数字身份指南中阐述了最小化原则：只请求特定功能所需的信息，并清楚地解释处理方式。对于会议注册来说，这是谨慎处理数据的总体准则。必填字段与可选的个性化内容分开，营销同意与访问基本议程也分开。问题、咨询记录和行为数据的保留期限需提前设定。

会议结束后应留下什么？

会议结束后，参与者需要符合其路线的材料以及清晰的下一步。团队则留下问题清单、产品信号和后续事项负责人。

材料矩阵需在活动前搭建：

材料 → 受众 → 源文件 → 负责人 → 审核人 → 版权 → 版本 → 渠道 → 就绪标准 → 备份

会议结束后，发布摘要、获准使用的照片和录像、实验室材料以及问题解答。针对每条路线准备各自的后续内容；对于闭门会议，则单独准备安全摘要。

详细的发布生产流程在关于会议后内容的文章中进行了分析。如果项目需要录像、访谈和按轨道分类的材料集，我们会提前将照片和视频制作、版权、画面中界面检查和审批流程纳入计划。

指标最好构建成阶梯：

GOV.UK 建议先确定用户问题，并将预期收益视为仍需数据验证的假设。因此，不能自动将活动日期后产品使用量的增长归因于会议。需要基线、选定群体、观察窗口以及对其他因素的考量。

最终内部复盘将议程与后续工作衔接起来。团队会解决快速问题、为复杂主题指定负责人、按路线准备材料，并告知参与者下一个检查点。我们可以将内容、场地、技术、分会场和材料发布整合为一个统一方案。 获取产品用户大会的报价。

来源

• Atlassian Team Europe FAQ
• Salesforce Dreamforce FAQ
• W3C WAI: Making Events Accessible
• Section508.gov: Accessible Meetings
• GOV.UK Service Manual: Developing a roadmap
• GOV.UK Service Manual: Measuring service benefits
• NIST: Privacy guidance
• Cornell University: Active Learning
• Cornell University: Collaborative Learning
• AWS Customer Success Stories