facilitating-design-critique

促进设计评审

这项技能以 Bitwarden 的两个权威资料为基础，指导设计评审的_组织_工作： 每周设计评审与礼仪速查指南 和产品设计评审指南。 筹备正式会议时，请直接阅读 Confluence 页面——get_confluence_page MCP 工具可以获取这些页面。这项技能是实践者的速查参考，而非这些页面的替代品。

跨插件依赖。 如果讨论中的设计位于 Figma 文件中，这项技能会组合使用 bitwarden-design-tools 插件中的 using-figma——请将它与 bitwarden-designer 一起安装，才能完整使用这套组合。

选择合适的模式

Bitwarden 有两种不同类型的评审。请区别对待。

• 每周设计评审。 定期举行的团队会议。演示者介绍一项进行中的工作；与会者先提出澄清问题，然后给出反馈。流程轻量、同级互评，演示者决定采纳哪些建议。
• 产品设计评审。 针对特定设计提案的利益相关方评审。根据需要邀请产品、工程和研究人员参与。组织工作更为深入：明确范围和标准、准备简报、演示设计，并以结构化方式收集反馈。

在建议会议结构之前，先询问用户指的是哪种模式。两种模式的角色分工、准备工作和时间投入各不相同。

会议中的角色

• 演示者。 介绍背景：设计目标、限制条件、待解问题，以及希望获得哪类反馈。演示者决定采纳哪些建议。
• 主持人。 引导会议：讨论偏离主题时及时拉回；将与范围无关的旁支问题记入“待议事项”；确保讨论围绕演示者提出的反馈需求展开。在每周设计评审中，这通常是轮流担任的角色；在产品设计评审中，则会明确指定。
• 参与者。 先提问，再评价。分享观察、顾虑和想法，并以用户和产品目标为依据，而非个人偏好。不要主导讨论。

《每周设计评审速查指南》将其归纳为：评审作品，支持设计师，改进产品。

会议流程

两种模式的流程相同，但深入程度不同。

1. 演示者介绍背景。 目标、限制条件、待解问题，以及希望获得的反馈类型。在产品设计评审中，还要介绍背景和“原因”——相关文档、早期迭代、用户研究结果、业务目标和最终用户目标。
2. 澄清问题。 先提问，再评价或提出建议。尚未理解的内容，不要急于评审。
3. 演示并收集反馈。 演示者讲解设计。参与者围绕用户影响、产品目标、标准或技术限制分享反馈。
4. 总结。 总结要点和后续步骤。在产品设计评审中，以合适的格式记录反馈以供后续参考，并对问题排序。

反馈礼仪——该做和不该做

该做

• 提供具体且有建设性的反馈。
• 解释某个设计为何有效或无效。
• 提问以了解设计意图。
• 指出做得好的地方，而不只谈问题。
• 尊重时间，围绕主题展开。

不该做

• 针对个人。
• 给出“我不喜欢”这类模糊意见。
• 主导对话。
• 在缺乏背景信息时直接提出解决方案。
• 当场重新设计——描述差距，让设计师来解决。

讨论陷入停滞时，可以用以下开场问题：

• “这个设计解决了用户的什么问题？”
• “我不太理解[空白处]——可以解释一下吗？”
• “我们是否考虑过[空白处]这个替代方案？”
• “这部分做得很好，因为[空白处]。”

常见的参与误区

• “我不喜欢。” 这不是反馈。请将观察与用户需求、业务需求、标准、惯例或技术限制联系起来，否则就别提。
• “你又不是用户。” 把个人偏见说成普遍体验。应将其作为偏见指出，而不是当作结论。
• 不恰当地问 为什么。 “你为什么这么做？”会让设计师产生防备心理。“你做 X 是想实现什么？”问的是同一件事，但不会显得咄咄逼人。
• 评审时提出解决方案。 出于好意的建议可能引发设计上的连锁反应。描述问题所在，让设计师在线下权衡解决办法。
• 只给负面反馈。 设计师既会朝着有效的方向前进，也会远离无效的方向。先肯定优点，再指出问题。
• 未考虑后果。 “我们能不能就……”这类请求常会引发一连串问题。当某个建议看起来很简单时，请指出你能预见的连锁影响，并让设计师自行决定。

产品设计评审主持人手册

担任主持人（而不仅仅是参与者）时：

• 评审前。 选择收集反馈的方式。确定并邀请合适的利益相关者。确认演示者已准备好简报材料（目标、背景、早期迭代、用户研究、业务目标和终端用户目标）。
• 评审中。 明确范围。设定反馈预期。探究“为什么”。引导演示流程。明确范围和标准后，再向大家开放讨论。按照约定的格式记录反馈。将超出范围的讨论留到待议事项中。
• 评审后。 确定所提问题的优先级。与演示者确认后续步骤。

与其他技能配合使用

• design-review。 会议期间，反馈的 实质内容 通过 design-review 来处理，包括 30/60/90 框架、行为准则，以及（在 60%/90% 阶段）content-style-guide。这项技能负责营造讨论氛围；design-review 负责塑造讨论内容。
• using-figma。 如果演示内容来自 Figma 文件，请使用 using-figma 将设计背景（截图、元数据、变量）带入讨论，同时避免信息过载。

输出格式

当有人请你协助准备或主持设计评审时：

1. 模式 — 每周评议会或产品设计评审。
2. 角色 — 谁负责主持、谁负责演示、谁负责参与。
3. 演示者的准备信息 — 目标、限制、未解决的问题、反馈请求。
4. 议程 / 流程 — 背景 → 澄清问题 → 演示流程 → 反馈 → 总结。
5. 讨论注意事项 — 根据所演示的工作，指出可能出现的具体礼仪误区。

结尾务必明确提出总结问题：演示者接下来要做什么？