---
name: design-discovery
description: Pre-design 用户研究 + 市场分析 + 数据可行性 audit。触发：新 feature / 新 persona / 重大重设计。产出 6 项 deliverable（含 IA + feature list）+ data feasibility audit + MVP scope 声明，喂给 Stage 0.5 pre-design validation。
---

# Design Discovery 起手协议

## 1. 判断是否触发

AI 复述 user 的 design ask，**先问**："这个 task 需要 discovery 吗？"

- ✅ 触发：新 feature / 新 persona / 重大 redesign / "design proposal" 类 ask
- ❌ 不触发：bug fix / copy 改 / 已有 element 微调

不触发 → 跳过本 skill，直接进 Pre-Phase 0 / M0。

## 2. 5 项 deliverable（必产）

### Personas (3-5)

| Persona | 业务角色 | 频率 | 技术深度 | 主要决策 |
|---|---|---|---|---|

### Use scenarios (5+)

列 "谁 在什么时候 / 什么场景 / 什么目的 用"

### Pain points (5+, ranked)

按严重度 × 频率 排序

### User stories (5+ "As X I want Y so Z" 格式)

### Market / Competitive analysis (3+ 同类产品)

| 产品 | 强项 | 弱项 → 我们差异化机会 |
|---|---|---|

### Information Architecture (IA) + Feature List（第 6 项）

**IA 层级**（page hierarchy）：

| Level | Page / Section | 主要功能 |
|---|---|---|
| L1 | 顶级导航 | |
| L2 | 子页面 / tab | |

**Feature list**（按 persona 分组）：

| Feature | 服务 persona | Priority | 数据源依赖 |
|---|---|---|---|

## 3. 后置 deliverable

- **Pain → Feature mapping**：每 pain 哪 feature 解 / 不解 / next phase 解
- **MVP scope 声明**：当前设计服务哪些 persona / pain，缓哪些到 next phase

## 3.5 数据可行性 Audit（含 derived metric / chart 的 task 必做）

1. 列出已确认数据源（API / DB / 账单 / 第三方等）
2. 每个 feature 推导 derivable metrics，列公式 + 可算性

| Feature / Metric | 公式 | 数据源 | 可算? |
|---|---|---|---|
| | | | ✅ / ⚠️ 估算 / ❌ 不可算 |

3. ❌ 不可算 → 从 feature list 剔除或标注 defer；⚠️ 估算 → 标注 risk + 用户确认
4. 用户确认修订后 feature list → 进 Gate（§4）

**Why**：feature 设计前不确认数据可行性 = 反模式（实证：2026-05-11 SaaS Dashboard Driver attribution + Forecast 在 build 后才被 drop）。

## 4. Gate

全部 deliverable（含 IA + data audit）→ user 校 → 进 Stage 0.5。

## 5. 跳过 → 落复盘

若用户选择跳过 discovery，retrospect 必须 record 跳过决策。