# Design Critique

> 通过清晰的反馈框架和可操作的成果来促进结构化的设计评审。

- Skill: `wanghaisheng/design-critique` (Agent Skill)
- Install (CLI): `npx skillmds@latest add wanghaisheng/design-critique`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wanghaisheng/design-critique/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: wanghaisheng (https://skillmd.com/u/wanghaisheng)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wanghaisheng/design-critique

---


# Design Critique

促进生产性设计评审以改进工作和培养团队的专家。

## What You Do

构建和促进产生清晰、可操作反馈的设计评审。

## Critique Framework

### Before the Critique
- 设计师分享背景：目标、约束、目标受众、工作阶段
- 定义需要什么反馈（布局？流程？文案？全部？）
- 设定规则：建设性、具体、可操作

### During the Critique
1. **Present（展示）** (5分钟) — 设计师介绍工作和目标
2. **Clarify（澄清）** (5分钟) — 理解问题，而非评判
3. **Feedback rounds（反馈轮）** — 按类别或优先级结构化
4. **Discuss（讨论）** — 对关键张力的开放对话
5. **Capture（记录）** — 记录决策和行动项

### Feedback Format
- 'I notice...'（观察，而非评判）
- 'I wonder...'（问题或探索）
- 'What if...'（建议或替代方案）
- 'I think... because...'（有理由的观点）

### After the Critique
- 设计师总结要点
- 带有负责人和截止日期的行动项
- 如需要，进行后续评审

## Critique Types

- **Desk crit（桌面评审）**：非正式、1对1、快速反馈
- **Team crit（团队评审）**：定期、结构化、全团队
- **Cross-team crit（跨团队评审）**：项目外的新视角
- **Stakeholder review（利益相关者评审）**：决策导向、审批导向

## Common Pitfalls

- 委员会式设计（意见太多，没有方向）
- 关注个人偏好而非用户需求
- 评审太早（探索中）或太晚（打磨中）
- 没有明确的下一步

## Best Practices

- 将探索评审与改进评审分开
- 评审工作，而非个人
- 始终将反馈与目标和用户需求联系起来
- 轮换主持人角色
- 使评审成为常规仪式，而非事件

## Psychology Principles Integration

### 希克-海曼定律应用
- **聚焦反馈**：每次评审聚焦3-5个关键问题，避免信息过载
- **分步反馈**：将反馈分为多个轮次（结构→内容→细节）
- **优先级排序**：使用优先级标记（P0/P1/P2）降低决策负担

### 认知负荷理论应用
- **反馈结构化**：使用固定的反馈格式（I notice/I wonder/What if/I think）
- **信息分区**：将反馈分为4±1个类别（布局、交互、内容、视觉、可访问性）
- **渐进呈现**：先呈现高层级问题，再展开细节

### 损失厌恶应用
- **建设性批评**：强调改进机会，而非缺陷
- **可操作建议**：提供具体可行的改进方案，而非抽象批评
- **正面强化**：首先肯定好的设计，再提出改进建议

### 多模态反馈应用
- **视觉反馈**：使用标注和截图明确指出问题位置
- **书面记录**：所有反馈必须书面化，避免口头遗忘
- **行动追踪**：记录反馈的执行状态，确保闭环

## 中文术语

- 桌面评审 (Desk crit)
- 团队评审 (Team crit)
- 跨团队评审 (Cross-team crit)
- 利益相关者评审 (Stakeholder review)