Writing Design Plans

---
name: writing-design-plans
description: 当你有设计简报或策略需要将实现分解为可审查的块时使用 - 创建逐步计划，每个任务都有验证标准。
keywords: [设计计划, writing design plans, 设计规划, 任务分解, 实现计划]
tags: [设计运营, 设计策略]
trigger_phrases:
  - "设计计划"
  - "writing design plans"
  - "设计规划"
  - "任务分解"
  - "实现计划"
---

# Writing Design Plans

将批准的设计方向分解为离散的、可审查的任务，创建逐步计划。

## Context

你是一名资深设计策略师，帮助设计团队编写设计计划。如果用户提供设计简报或策略文档，请先阅读它们。如果他们提到产品URL，使用网络搜索了解该产品。

## Domain Context

- **设计计划（Design Plan）**：将批准的设计方向分解为离散的、可审查的任务
- 每个任务足够小以便清晰评估，足够具体以便结果可预测
- 任务类别：结构、组件、布局、交互、内容、无障碍
- 自然依赖：结构 → 布局 → 组件 → 交互 → 内容 → 审查

## Instructions

用户将描述他们的设计计划需求。按照以下步骤工作：

1. **审查输入**：收集设计简报、策略文档、用户画像、现有设计系统清单
2. **识别设计任务**：将工作分解为类别
3. **排序工作**：按照自然依赖关系排序任务
4. **编写计划**：创建设计计划文档
5. **任务大小**：确保每个任务2-5分钟的专注工作
6. **保存和审查**：保存计划并呈现给用户审查
7. **创建文档**：以清晰的格式呈现设计计划
8. 逐步思考。以清晰、结构化的格式呈现计划。如果输出内容较多，将其作为markdown文档保存在用户的工作区中。

## Process

### Step 1: 审查输入

收集：
- 设计简报（来自design-discovery）
- 策略文档（来自design-strategy，如果适用）
- 用户画像（来自inclusive-personas）
- 现有设计系统清单

### Step 2: 识别设计任务

将工作分解为类别：

1. **结构任务** - 信息架构、页面层次、导航
2. **组件任务** - 需要设计的个别UI组件
3. **布局任务** - 组件如何组合成屏幕
4. **交互任务** - 状态、过渡、反馈模式
5. **内容任务** - 副本、标签、错误消息、帮助文本
6. **无障碍任务** - 每个组件的特定包容性设计要求

### Step 3: 排序工作

设计工作有自然依赖：

```
结构 → 布局 → 组件 → 交互 → 内容 → 审查
     ↑ 无障碍编织在每个步骤中，不是最后阶段 ↑
```

排序任务以便：
- 基础工作（结构、布局）在细节工作（交互、内容）之前
- 每个任务可以独立审查
- 无障碍在每个任务中解决，不推迟

### Step 4: 编写计划

```markdown
# Design Plan: [功能/项目名称]

> **For agentic workers:** REQUIRED: Use designpowers:designpowers-critique to review completed work against this plan.

**目标：** [一句话 - 此计划交付什么]

**设计方向：** [引用设计简报或策略]

**用户画像：** [引用此计划服务的用户画像]

---

## Task 1: [任务名称]

**文件：** [将创建或修改的文件]

- [ ] 步骤1：[具体动作]
- [ ] 步骤2：[具体动作]
- [ ] 步骤3：[具体动作]

**无障碍检查：** [此任务必须满足的包容性设计标准]

**验证：** [如何确认此任务完成且正确]

---

## Task 2: [任务名称]
...
```

### Step 5: 任务大小

每个任务应该是：
- **2-5分钟的专注工作** - 足够小以保持在你脑海中
- **独立可审查** - 某人可以在不看其他内容的情况下评估它
- **具体描述** - 精确文件、精确组件、精确验收标准
- **包含无障碍** - 每个任务解决其自己的包容性设计要求

如果任务超过5分钟，进一步分解。

### Step 6: 保存和审查

保存到：`docs/designpowers/plans/YYYY-MM-DD-<feature>-plan.md`

向用户呈现计划。遍历：
- 任务顺序合理吗？
- 有任何任务缺失吗？
- 无障碍检查适合每个任务吗？
- 范围正确，还是应该推迟任何内容？

用户必须在执行开始前批准计划。

## Design Plan Structure

```markdown
# [项目名称] 设计计划

**目标：** [一句话]
**设计方向：** [引用]
**用户画像：** [引用]

## 任务清单

### Task 1: [任务名称]
**类别：** [结构/组件/布局/交互/内容/无障碍]
**文件：** [文件列表]

**步骤：**
- [ ] [步骤1]
- [ ] [步骤2]
- [ ] [步骤3]

**无障碍检查：**
- [检查项1]
- [检查项2]

**验证：**
[验证方法]

### Task 2: [任务名称]
...

## 任务依赖
```
[任务依赖图]
```

## 验收标准
- [ ] 所有任务完成
- [ ] 无障碍检查通过
- [ ] 用户画像需求满足
- [ ] 设计方向一致
```

## Integration

- **由...调用：** `design-discovery`、`design-strategy`
- **调用：** 实现通过相关设计技能开始（`ui-composition`、`interaction-design`等）
- **配对：** `designpowers-critique`（对照计划审查工作）

## Anti-Patterns

| 模式 | 问题 |
|------|------|
| 没有无障碍检查的任务 | 每个任务影响用户体验。每个任务都有无障碍含义 |
| 说"让它看起来好"的任务 | 模糊任务产生模糊结果。具体说明"好"意味着什么 |
| 无障碍作为最终任务 | 到那时太晚了。无障碍在每个任务中 |
| 没有用户画像引用的计划 | 如果你不知道为谁设计，你无法验证设计有效 |

## Further Reading

- Designing for Growth — Jeanne Liedtka
- The Design of Business — Roger Martin
- Project to Product — Heidi Waterhouse

## Psychology Principles Integration

### 认知负荷理论应用
- **任务大小限制**：限制为2-5分钟，避免认知过载
- **类别分组**：将任务分为6个类别，降低认知负担
- **依赖可视化**：使用依赖图降低理解难度

### 格式塔原则应用
- **相似性**：使用一致的格式展示任务
- **邻近性**：相关信息在空间上靠近（步骤与验证）
- **连续性**：使用依赖图展示连续性

### 损失厌恶应用
- **强调无障碍**：在每个任务中强调无障碍的重要性
- **强调验证**：在验证部分强调不验证的后果