先明确工作坊必须推动的决策
先确定本次会议要澄清问题、比较方案、界定首个版本，还是识别集成风险。
明确的结果可以避免讨论变成所有想法的无序汇总。
- 需要作出的决策
- 必须批准的人
- 所需证据
- 可以暂时保留的问题
带来真实工作的实例
截图、表单、电子表格、支持请求和匿名案例，往往能暴露理想流程图中看不到的例外。
选择两个常见案例和一个困难案例，用于区分稳定流程与高成本边界情况。
邀请能够看到系统不同部分的角色
管理者说明目标，一线用户指出信息在哪里被延迟、复制或修正。
参与者应足以覆盖关键视角，同时保持小规模以便真正作出决定。
- 流程负责人
- 高频用户
- 技术或安全代表
- 有权决策的人
让议程从证据逐步走向选择
先讨论背景和可观察的问题，再梳理流程、用户、数据、约束和首个可验证结果。
最后记录假设、负责人、待收集证据和下一次决策日期。
有价值的工作坊应以决策、明确的不确定性、负责人和具体下一步结束。
形成简洁可信的探索记录
输出应让未参会者也能理解当前状态、目标变化、用户、约束、风险和建议行动。
将假设与已批准决策分开，避免临时想法被误认为正式需求。
在研讨会前准备可验证的材料
高质量研讨会应从可观察的材料开始，而不是只依赖观点。请准备现有表单、界面截图、运营报告、支持请求、政策限制、代表性数据字段，以及团队目前使用的临时处理方式。
这些材料不需要经过精美整理。它们的作用是呈现真实工作顺序、最耗时的例外情况，以及信息如何跨越团队与系统边界。通过具体案例，参与者更容易区分事实、假设和个人偏好。
- 当前流程图或简要步骤
- 三到五个代表性案例，并包含至少一个例外
- 已知政策、集成与审批规则
- 可用运营指标和重复出现的支持问题
以明确决策、责任人和开放问题结束
只有当发现工作改变下一步决策时，它才真正有价值。应记录已经达成的共识、尚未验证的假设、每项后续工作的责任人，以及关闭开放问题所需的证据。
最后确定一个范围有限且可以验证的动作，例如测试一个关键旅程、原型化高风险交互，或确认某个集成合同。这样可以避免研讨会变成没有交付后果的愿望清单。
发现研讨会的结果应当是更少的不确定性和更清楚的责任，而不只是更多会议记录。