AI 辅助闭环原有问卷
创建、发送、统计
- 引导者为一次迭代创建问卷，再将链接分享给团队成员。
- 成员匿名提交 1—7 分反馈，系统只呈现回复数量和维度得分。
- 讨论、报告与行动跟进发生在系统之外，流程没有下一步。
企业级 AI 应用系统设计 · IGX · 2026
Squad
Health
将传统的问卷流程重构为持续的团队健康检查：让真实的团队信号，沉淀为共同承诺，并在每一次迭代中形成可见的学习与改进。
再带到下一轮。
项目概览
团队。周期。状态。
- 角色
- 企业数字化与 AI 应用系统设计，负责需求整合、系统方案、交互规则和 AI 辅助前端原型构建。
- 周期
- 2026.6.24—8.5，六周完成专项设计并交付开发；该功能属于我 2024—2026 持续参与的 IBM Garage／IGX 工作。
- 协作
- 与产品负责人、架构师、技术负责人、交付团队及 IBM Garage 教练团队共同评审。
- 状态
- 通过多轮跨职能评审并完成研发交接，现已在 IGX 上线，供 Garage 教练团队使用。
我如何参与
我将一次性的问卷流程重新定义为可信、可执行的复盘系统闭环，让团队的真实信号转化为明确的决定、行动和下一轮学习。
我主导的工作
- 将原有问卷重构为持续运转的复盘闭环。
- 设计端到端体验，涵盖匿名反馈、AI 会前预读、会议引导与行动跟进。
- 主导 AI 辅助原型构建，以及可供研发使用的设计交接。
我协作完成的工作
- 与一名 UX 设计师和 Garage 教练团队梳理反馈、验证工作流程。
- 通过三轮评审，与产品、架构、工程和交付负责人对齐范围与可行性。
结果
项目通过多轮跨职能评审并完成研发交接，现已在 IGX 上线，供 Garage 教练团队使用；可运行前端原型、系统流程、规格说明和 AI 提示词让后续团队能够追溯关键系统决策。
01
明确功能在整体系统中的定位
IBM Garage 方法 · IGX
Squad Health 不只是一份问卷，更是将迭代经验转化为实际行动的关键环节。
2024 至 2026 年间，我持续参与 IGX 多项功能的设计与演进。IGX 是一个数字化平台，旨在让 IBM Garage 的工作方式清晰可见，并落实到具体行动中。Squad Health 服务于迭代复盘环节，将项目交付过程中的经验与洞察，融入团队后续的工作节奏。
Garage 方法→IGX→迭代回顾→Squad Health
02
重新定义问题
为什么需要改变
从问卷分数，走向持续的团队改进。
团队健康检查
收集信号、充分准备、共同决策、持续跟进
- 围绕一次迭代创建健康检查，收集团队的匿名反馈，并由 AI 整理成可供会前审阅的摘要。
- 引导团队完成从回顾与归类，到投票、讨论和结果确认的完整复盘流程。
- 将复盘结论转化为明确的行动事项，指定负责人和截止日期，并将执行记录带入下一次迭代，作为后续复盘的参考。
Garage 教练团队 · 初始需求
团队需要的不是一份更好用的问卷，而是一套能推动后续行动、并让经验在多次迭代中持续积累的机制。
最初的邮件沟通清楚地指出了问题：原有问卷只停留在收集反馈和展示评分，复盘报告、工作坊、行动追踪以及历次回顾的背景信息则分散在不同工具和流程中。
既有功能 · 问卷
创建 → 发送 → 回答 → 统计
01创建 
02发送 
03回答 
04统计
Garage 教练团队希望 IGX 提供的支持
他们的需求让项目重点从“收集问卷”，转向“帮助团队将反馈转化为经验沉淀和可追踪的改进行动”。
“IGX could support action logging, notifications, and tracking of retrospective action items. This would help teams follow up more systematically after each retrospective.”
Garage 教练团队 · 行动跟进
“Please summarize the Squad Health Survey for a squad, Iterations 4–6.” AI could then provide insights by topic, not only one summarized score.
Garage 教练团队 · 跨迭代洞察
“IGX could support AI to generate an initial summary … used as supporting input for Retro sessions and report generation.”
Garage 教练团队 · AI 辅助会前准备
当前复盘方式 · 调研发现
IGX 只负责问卷创建、发送和匿名反馈收集，其余复盘流程则分散在三个工具中：
VOTE 用于展示评分，FigJam 用于团队讨论，Confluence 用于保存复盘记录和行动事项。
- 01VOTE report
分数与要点
- 02FigJam
引导式讨论
- 03Confluence
记录与行动事项
03
明确需要验证的问题
从功能需求转化为产品问题
真正需要设计的，是问卷之外的复盘闭环。
我将复盘中最容易失去信任或中断推进的四个关键环节，作为此次重新设计的切入点。这些问题帮助我们系统审视原有体验，并在决定具体方案前收集充分依据。
坦诚
如何让成员在匿名且可信任的条件下，愿意给出真实而坦诚的反馈？
理解
如何让引导者带着上下文进入会议，而不是临场解读一个分数？
决策
团队如何在不丢失不同声音的前提下，收敛出真正需要改进的事项？
跟进
如何让复盘持续连接到它所产生的行动，而不是止于会议？
研究洞察梳理
从利益相关方的反馈中，提炼产品方向。
我梳理了 Garage 教练团队的需求，并分析现有工作流程，从中归纳出核心主题、设计原则与设计目标，为 Squad Health 的后续设计提供方向。
04
设计持续运转的复盘闭环
产品架构
让一次复盘从收集反馈开始，持续影响下一次迭代。
我将每次复盘设计为一条完整、连续的记录，贯穿检查设置、匿名反馈、会前准备、团队讨论和行动跟进，并为下一次迭代提供背景与依据。
05
将闭环落为可运行的系统
从系统架构到关键业务场景
这个闭环必须在会前、会中和会后都能运作。
我把会前、会中、会后设计成引导者真正能跑起来的一条服务：创建会话、定时匿名发送、会前准备与会中引导，再到确认复盘结论、明确行动负责人，并将本次洞察带入下一次迭代。
01 · 设置并收集反馈
确认参与者，并以无法追溯个人身份的方式收集真实反馈。
引导者可为指定团队和迭代安排单次或定期复盘，并确认邀请对象及专属链接的发送时间。问卷保留七个固定的健康度维度，以便持续对比，同时最多可添加三个自定义问题。
- 会前发送或现场填写，均使用同一组匿名专属链接。
- 仅显示完成进度，并提醒尚未提交的成员；不实时展示可能暴露个人身份的评分。
- 问卷关闭前可随时调整参与者名单，也可通过邮箱邀请外部人员。系统保存的回答不会关联任何身份信息。
02 · 准备与引导
用 AI 做好会前准备，但让引导者始终主导会议。
AI 会综合反馈覆盖率、评分变化、文字评论、历史行动和自定义问题，生成可编辑的会前摘要与讨论主题。复盘开始时，团队可根据自己的工作习惯选择合适的会议空间。
- 使用 IGX 白板：在同一空间内完成回顾、归类、投票和讨论，并直接保留过程记录，无需导出。
- 使用外部工具：继续使用 FigJam、Mural、Microsoft Whiteboard，或仅记录会议笔记；IGX 则负责议程和计时。
- 复盘结束时，将外部白板或相关材料导回 IGX。AI 生成结论初稿，再由引导者审核并确认最终保留的内容。
03 · 确认、行动与学习
将讨论转化为责任明确的下一步行动，并从多次复盘中发现趋势。
复盘结束前，团队需要审核并确认讨论成果。会议不能止于模糊的承诺：每一项保留的行动都必须明确负责人和截止日期。随着多次迭代积累，这些记录还会形成面向 Garage 负责人的洞察报告。
- 结束前审核复盘结论：IGX 白板记录会自动带入；上传的外部材料也会被提取，并进入同一审核流程。
- 将达成共识的改进事项转为行动任务，明确状态、负责人和截止日期。
- 跨多次迭代呈现趋势、关键主题、行动落实情况，以及下一阶段的关注重点。
06
借助 AI 构建、评审与迭代
可控的 AI 辅助开发交付
AI 加速前端构建；产品决策始终由人主导。
我使用 AI 编程代理和 Figma MCP，将设计规范转化为高保真的 React 原型，并直接基于可运行的产品开展评审，让反馈更具体。每一项重要调整都需要同时更新交互规则和实际实现，而不是事后仅记录在演示文稿中。
构建规范
在要求 AI 生成界面前，先定义每一个状态。
- 明确完整生命周期。为复盘设置、匿名发送、反馈收集、会前摘要、会议讨论、复盘总结、行动事项和洞察报告等环节，分别定义清晰的状态与规则。
- 基于统一设计依据构建。以 Figma 关键界面、页面规格、交互矩阵和源素材作为实现依据，确保产出符合设计要求。
- 评审可运行的产品。每条反馈都会同步落实到交互规则、界面状态和代码逻辑中，并纳入最终交付内容。
可追溯的构建过程
可运行的代码，完整记录每一次产品决策。
原型代码库将产品决策沉淀为具体的实现变更，而不只是保留静态的界面截图。
mainIGX-new-squad-health
5810747构建匿名成员问卷流程5c08e2f会议投票、便签反馈与成员视图38995ac扩展参与与会议流程2fabab1新增成员会议链接流程
客户评审
利益相关方在会议中直接体验并检验可运行的原型。
我与 Garage 教练和交付团队开展了一次在线评审。大家基于真实的产品流程提出反馈，并以此推动方案进入下一阶段。
三轮跨职能评审
只有明确下一步决策，项目才会进入下一阶段。
- 第一轮评审
这次评审直接改变了设计方案
产品经理、架构师和技术负责人共同参与评审，并明确了三项关键规则：
- 匿名机制：仅显示完成情况，不实时展示评分，保存的回答也不包含身份信息。
- 会议方式：无论使用 IGX 白板还是外部工具，所有过程与结果都保留在同一条复盘记录中。
- 结束条件：行动事项必须明确负责人和截止日期，才能结束本次复盘。
- 第二轮评审
产品负责人评审完整流程原型
所有流程实现后，我通过预设场景完整演示了复盘设置、反馈收集、AI 会前摘要、会议讨论、复盘总结、行动事项和洞察报告，并用演示文稿说明每项设计背后的原因。
最直接的认可体现在评审之后：产品负责人亲自将方案带到客户面前，并组织了后续的 Garage 教练团队评审。
- 第三轮评审
回到最初的需求方，快速完成验证闭环
客户评审邀请了最初通过邮件提出需求的 Garage 教练团队。我首先回顾了他们最关注的问题：行动跟进、AI 会前准备，以及跨迭代的洞察积累，随后通过原型完整展示产品如何回应这些需求。
由于原型可以独立运行，他们能够在会议中直接体验和检验产品，而不必等待后续演示。目前，Squad Health 已在这些 Garage 教练团队的实际工作中上线使用。
07
交付与反思
我的交付成果
交付的不只是界面，而是一套可运行的产品方案。
这套交付让团队能够完整查看和验证健康检查的全流程，包括高保真原型、背后的交互与状态规则、客户演示路径、评审决策，以及开发所需的实现上下文。
- 引导者、团队成员和会议链接三类原型路径
- 覆盖复盘设置、问卷填写、复盘总结、行动事项和洞察报告的完整生命周期
- 页面规格、交互矩阵和设计指南
- AI 提示词、演示数据，以及供开发参考的实现说明
我的收获
与 AI 协作进行设计，让我再次理解了设计 AI 产品时的同一个原则。
真正重要的不是 AI 能多流畅地生成内容，而是它的过程和结果能否被追溯与验证。只有当 AI 的判断可以被检查时，它才真正有价值。设计师与 AI 协作时也应遵循产品本身的原则：让 AI 快速推进，但由人审核并确认最终结果。
我设计了一套“AI 提供建议、人做最终决策”的系统，而整个项目也正是以这种方式完成并交付的。
如果重新来做
01在真实的异常情况下验证设计
原型中的 AI 输出是预设的，因此不会出现幻觉。但这也意味着，这套设计重点防范的风险从未在真实使用中发生。只用表现稳定的 AI 来验证信任机制，得到的仍然只是假设，而不是经过验证的结论。
02补上真实使用验证这一环
项目缺少从“评审”到“真实使用”之间的关键环节：由研究人员将原型带入实际研究，让真实用户在时间压力下完成任务，并记录由此产生的问题。评审只能验证方案是否合理，真正的使用测试才能验证产品是否有效。
结语
真正的难点，不是得到一个更准确的分数，
而是让团队能够信任并落实下一步决策。
AI 加快了从设计规则到可评审产品的实现过程，但无法替代设计判断。整个方案需要为隐私保护、会议引导、投票机制和行动责任设定清晰边界，同时也要坦诚说明原型现阶段还无法解决的问题。