Design Discovery

---
name: design-discovery
description: 在任何创意或设计工作之前必须使用 - 探索意图、约束、用户和上下文。确保在做出任何设计决策之前理解问题。
keywords: [设计发现, design discovery, 问题探索, 设计简报, 设计上下文]
tags: [设计研究, 设计策略]
trigger_phrases:
  - "设计发现"
  - "design discovery"
  - "问题探索"
  - "设计简报"
  "探索设计上下文"
---

# Design Discovery

在任何创意或设计工作之前探索意图、约束、用户和上下文。

## Context

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

## Domain Context

- **设计发现（Design Discovery）**：在设计开始之前理解问题
- 发现是设计开始的地方 - 在像素、线框或任何视觉决策之前
- 确保不会把错误的东西做得很好
- 发现可以是快速发现（POC和小任务）或完整发现（产品和复杂任务）

## Instructions

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

1. **理解上下文**：收集现有的设计文档、设计系统、组件库或风格指南
2. **探索意图**：通过对话理解用户想要构建什么以及为什么
3. **识别能力谱**：考虑不同能力用户的需求
4. **提出方法**：提出2-3个设计方法及其权衡
5. **编写设计简报**：创建设计简报文档
6. **用户批准**：获得用户对简报的批准
7. **创建设计状态**：创建设计状态文件
8. **转换**：转换到下一个适当的skill
9. 逐步思考。以清晰、结构化的格式呈现设计简报。如果输出内容较多，将其作为markdown文档保存在用户的工作区中。

## Discovery Modes

### 快速发现（POC和小任务）

当用户说"proof of concept"、"POC"、"quick"、"small"或任务明显是探索性时：

1. 保持轻量。以对话方式问几个要点 - 不是编号检查清单
2. 立即从他们的答案编写简报 - 不要问后续轮次
3. 一次性呈现简报以供批准（不是逐节）
4. 简报批准后立即在项目根目录创建 `design-state.md`

快速发现应该花费**一个用户消息**的答案，而不是三个。但问题应该感觉像人在问，而不是表格。

### 完整发现（产品和复杂任务）

当任务是完整产品、涉及多个利益相关者或用户明确想要深度时 - 使用下面的完整过程。

## Process

### Step 1: 理解上下文

在提问之前，收集已存在的内容：
- 阅读项目中的任何现有设计文档、规范或简报
- 检查现有的设计系统、组件库或风格指南
- 查看用户正在工作的当前状态
- 识别平台、技术栈和任何约束

### Step 2: 探索意图

进行对话，而不是审讯。目标是理解用户想要构建什么以及为什么 - 但语气应该感觉像两个人在交谈，而不是填写表格。

**以开放的邀请开始**，而不是结构化的问题：
> "告诉我你在构建什么。它背后的故事是什么？"

让用户说话。从他们说的话中听出这些问题的答案，只对缺失的内容进行后续提问：

1. **我们在解决什么问题？** 不是构建什么功能 - 这解决什么人类问题？
2. **谁经历这个问题？** 不是"用户" - 哪些具体的人，在什么情况下，有什么能力和约束？
3. **成功是什么样子？** 我们如何知道这个设计有效？使用它的人会发生什么变化？
4. **存在什么约束？** 技术、时间线、品牌、无障碍要求、法规
5. **之前尝试过什么？** 什么有效，什么失败，学到了什么

**一次问一个后续问题。** 不要一次列出所有缺失的项目。选择最重要的差距，对话式地询问，并重复。围绕他们已经告诉你的内容来构建问题：
- 而不是"你的约束是什么？" → "你提到它需要在移动设备上工作 - 还有其他我应该知道的约束吗？"
- 而不是"用户是谁？" → "你说这是给忙碌的父母 - 告诉我更多关于他们使用这个时的典型一天。"

**自然地编织品味种子。** 不要把这些作为单独的部分 - 在感觉合适的时刻将它们折叠到对话中：
- "我们应该在哪个设计系统或风格指南内工作？"
- "有你喜欢的具有你想要的感觉的产品或体验吗？"
- "使用这个应该*感觉*如何？（平静、有趣、高端、轻松 - 任何想到的）"

这些是轻量级的提示，不是完整的品味校准 - 那稍后通过 `design-taste` 进行。但让用户早期思考感觉意味着他们以更敏锐的直觉到达品味校准。如果他们在这里分享设计系统，在简报中记录它，以便品味技能拾取。

**确认他们告诉你的内容。** 在问下一个问题之前，简要反映你听到的内容。这表明你在倾听，并给用户机会早期纠正误解：
> "所以这是关于减少小型诊所的缺席 - 接待员花半天时间在提醒电话上。明白了。除了接待员，谁还受到影响？"

### Step 3: 识别能力谱

对于每个设计任务，明确考虑：
- 谁可能使用屏幕阅读器？
- 谁可能使用有限的运动控制？
- 谁可能在认知负荷或压力下使用？
- 谁可能使用非母语？
- 谁可能在低视力、色盲或明亮阳光下使用？

这不是要匆忙完成的检查清单。这些是真实的人，他们会使用你构建的东西。

### Step 4: 提出方法

提出2-3个设计方法及其明确的权衡：

对于每个方法：
- **它是什么** - 一句话
- **为什么可能有效** - 优势
- **它牺牲什么** - 权衡
- **它最适合谁** - 以及它可能服务不足的人
- **无障碍含义** - 会出现什么包容性设计考虑

### Step 5: 编写设计简报

一旦用户选择了方向，编写设计简报：

```markdown
# Design Brief: [功能/组件名称]

## Problem Statement
[我们在解决什么问题，为谁，在什么上下文中]

## Users
[这服务谁 - 包括能力谱考虑]

## Design Direction
[选择的方法和原因]

## Constraints
[技术、时间线、品牌、无障碍、法规]

## Existing Design System
[设计系统、风格指南或组件库的路径 - 或"无"]

## Taste Direction (Early Signal)
[用户在发现期间分享的任何参考、感觉或美学偏好。这为稍后的完整品味校准播种。]

## Success Criteria
[我们如何知道这个有效]

## Out of Scope
[我们明确不做的事情]
```

保存到：`docs/designpowers/briefs/YYYY-MM-DD-<topic>.md`

### Step 6: 用户批准

逐节向用户呈现简报 - 不是一次全部。在进入下一节之前获得每节的批准。用户必须明确批准完整简报才能开始任何设计工作。

### Step 7: 创建设计状态

**此步骤是强制性的。不要跳过。**

简报批准后，立即在项目根目录创建 `design-state.md`，包含：
- 简报摘要（问题、主要用户画像、成功指标）
- 设计原则（如果在发现期间定义）
- 空的决策日志、开放问题、工件索引和交接链
- 链接到完整简报文档

此文件是每个agent读取的共享上下文。如果它不存在，管道无法运行。

### Step 8: 转换

批准和设计状态创建后，调用适当的下一个skill：
- 如果需要研究 → 调用 `research-planning`
- 如果方向明确 → 调用 `design-strategy` 或 `writing-design-plans`
- 永远不要直接跳到UI工作

## Integration

- **由...调用：** `using-designpowers`（在任何设计任务上自动触发）
- **调用：** `research-planning`、`design-strategy` 或 `writing-design-plans`
- **永远不要跳到：** `ui-composition`、`interaction-design` 或任何实现skill

## Red Flags

| Flag | Response |
|------|----------|
| "Just make it look like this reference" | 参考信息 - 它们不替代发现。询问参考的什么有效以及为什么 |
| "We already know what we want" | 很好。那么发现会很快。但仍然要做 - 假设是糟糕设计隐藏的地方 |
| "This is just a small change" | 对界面的微小变化影响真实的人。发现扩展到任务 - 它不会被跳过 |

## Further Reading

- Discover Design — Paul Boag
- Designing for the Digital Age — Kim Goodwin
- The Design of Everyday Things — Don Norman

## Psychology Principles Integration

### 认知负荷理论应用
- **对话式提问**：一次问一个问题，避免认知过载
- **渐进呈现**：先呈现核心问题，再展开细节
- **确认反馈**：在提问前确认理解，减少误解

### 格式塔原则应用
- **连续性**：使用对话流程保持连续性
- **邻近性**：相关问题在对话中靠近
- **闭合**：提供完整的设计简报，形成闭环

### 损失厌恶应用
- **强调约束**：在发现中强调约束的影响
- **强调权衡**：在方法中强调权衡，避免后悔