05 Review

05-Review：评审与迭代

概述

在宣称一个设计"最终"之前，它必须经过评审。此技能管理结构化评审：对照简报、对照标准、与利益相关者一起。评审捕捉熟悉性隐藏的问题。目标不是让每个人都满意——是验证设计对用户、上下文和策略有效。

不可协商的规则

硬性门槛：没有至少一次对照设计简报和成功标准的结构化评审，任何设计都不算最终。 "我看起来不错"不是评审。

何时使用

• 概念开发完成后，交付之前
• 设计需要对照简报进行结构化评审时

何时不使用

• 概念生成期间（先完成 04-generate）
• 交付最终文件时（使用 06-deliver）
• "你喜欢吗？"——这不是评审。评审需要标准。
• 纯错字修复或文件格式调整（直接做，然后进入 06）

流程

1. 自我评审（在分享之前）

• 对照设计简报审查：它解决了所述问题吗？
• 对照策略标准审查：它符合策略吗？
• 对照护栏审查：它违反任何约束吗？
• 在给别人看之前修复明显问题

2. 同伴或专家评审

与未沉浸在这个项目中的人分享：

• 他们首先注意到什么？
• 什么令人困惑或不清晰？
• 什么感觉不对劲？
• 理由在没有解释的情况下还站得住吗？

3. 利益相关者评审

• 用理由展示设计（如需，调用 design-narrative）
• 引导反馈：问"这符合标准吗？"而不是"你喜欢吗？"
• 记录：什么有效、什么需要改变、什么被拒绝
• 区分有效反馈和主观偏好

4. 用户验证（如适用）

• 与真实用户或代表性用户测试
• 观察行为，不仅是意见
• 他们理解了什么？他们错过了什么？
• 他们会改变什么？

5. 迭代和记录

• 列出评审带来的所有修改
• 对每个修改：是必须修复、锦上添花、还是主观偏好？
• 处理必须修复项；将锦上添花项目标记为后续
• 记录决策：什么改了以及什么故意没改

6. 冲突检查（检测到冲突时强制执行）

评审常常暴露出矛盾。在退出评审之前，扫描以下情况：

• 利益相关者反馈与用户验证结果矛盾
• 两位评审者对同一元素给出了相反的反馈
• 被请求的修改违反了 03-strategy 的策略标准
• 设计方向与可行性反馈冲突

冲突解决块格式（与 03-strategy 相同）：

冲突检测：
- 源A：[反馈 / 数据点 — 引用原文]
- 源B：[冲突元素 — 引用原文]
- 性质：[为什么它们矛盾]

解决决策：
→ [选择了哪个方向]

理由：
→ [设计优先级逻辑]

取舍：
→ [什么被牺牲或推迟了]

规则：

• 冲突反馈不能取平均。必须做出决定。
• 03-strategy 的策略标准在可用性问题上优先于主观偏好。
• 在可用性问题上，用户验证数据优先于利益相关者意见。
• 如果冲突无法在不改变策略的情况下解决，升级回到 03-strategy。
• 记录每一个冲突解决方案。这些决策是 07-learn 审计中的证据。

理性化预防

危险信号

• 你将在没有给任何人看的情况下宣布工作"最终"
• 反馈只有"我喜欢"或"我不喜欢"（没有标准）
• 你忽略了所有反馈因为"他们不理解"
• 做了修改但没有记录原因

验证

• 已完成对照简报和标准的自我评审
• 至少一个外部评审者给出了反馈
• 利益相关者评审已进行，使用基于标准的提问
• 用户验证（或明确跳过决策）已记录
• 必须修复项已处理；锦上添花项已标记
• 修改和决策已记录理由

→ 下一步：使用 06-deliver 定稿资产、交付并生成规格。

设计决策日志（重要评审决策必填）

评审产生决策——改什么、保留什么、推迟什么。重要决策必须记录。

何时记录：

• 用有理据的决策推翻利益相关者反馈
• 在冲突反馈之间做出选择（链接到冲突解决块）
• 决定将修改推迟到未来迭代
• 任何修改或与原始策略方向矛盾的决策

日志格式（与 03-strategy 相同）：

决策：[评审中决定了什么]

选项：
A. [按请求修改]
B. [替代修改方案]
C. [保持原样 / 推迟 / 融合——描述]

选定：[选择]

拒绝：
A → [为什么——与策略、用户数据或可行性挂钩]
B → [为什么]

理由：
→ [为什么这个选择最有利于项目——与证据挂钩]

规则：

• "客户要求改所以我就改了"没有理由是空洞的决策。这次修改为什么服务项目？
• 被拒绝的反馈必须有理由。"他们不懂设计"不是理由。
• 日志条目是 07-learn 审计中的证据。审计将交叉检查：修改是否可追溯至标准，拒绝理由是否一致？
• 精简模式：至少记录一条主要评审决策。标准/深度模式：记录全部。