| name | 05-review |
| description | 在概念开发完成后使用——评审、收集反馈、对照简报验证,并在交付前细化。 |
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 审计中的证据。审计将交叉检查:修改是否可追溯至标准,拒绝理由是否一致?
- 精简模式:至少记录一条主要评审决策。标准/深度模式:记录全部。