---
name: double-diamond-skill
description: |
  双钻模型（Double Diamond）的结构化思维工具。基于 British Design Council、IDEO 设计流程等一手来源的深度调研，
  提炼 4 个核心原理和完整的操作协议。
  触发词：「双钻模型」「double diamond」「发散收敛」「问题定义」「design process」「discover define develop deliver」。
---

# 双钻模型 · 思维工具

> "The Double Diamond is a visual representation of the design and innovation process. It's a simple way to describe the steps taken in any design and innovation project." — British Design Council

## 激活条件与触发词

- 直接调用：「用双钻模型分析...」「discover define...」
- 语义触发：用户面对模糊的复杂问题需要结构化流程、不确定该怎样从问题到方案
- 组合调用：「先用双钻模型走完整流程，再用设计思维的共情方法做 Discover」

## 方法框架概览

双钻模型的核心是两轮发散收敛的结构化探索，它通过先探索问题空间再探索方案空间、每个空间先发散再收敛来确保解决正确的问题并用正确的方式解决。

## 核心原理（3-7个，每个须附 ≥2 个跨域证据）

### 原理 1: 先发散后收敛是解决复杂问题的基本节奏

**一句话定义**：不要急着找答案——先尽可能多的发现可能性，再集中精力选出最优解。

**跨域证据**：
1. 创意设计：IDEO 项目开始时不画图而是广泛观察用户行为（发散），然后聚集到最有启发的洞察（收敛）（来源：Kelley, The Art of Innovation, 2001）
2. 科学研究：科学发现遵循"产生假设（发散）→设计实验证实/证伪（收敛）"的循环（来源：Popper, The Logic of Scientific Discovery, 1934）

**应用方式**：在每个阶段开始之前明确问"现在是发散还是收敛阶段？"。发散时禁止评估，收敛时禁止发散。

**局限**：发散需要时间。在极度时间受限的场景中可能跳过发散直接收敛（即凭经验直觉判断）。

### 原理 2: 问题空间和方案空间需分别探索

**一句话定义**：花时间找到一个正确的问题，比快速解决一个错误的问题更有价值。

**跨域证据**：
1. 企业转型：BBC 数字化转型先花 6 个月理解"观众在数字时代真正需要什么"（问题空间）再设计数字化产品（方案空间）（来源：BBC, Digital Transformation Case, 2010）
2. 产品战略：Vettery 重设计前花大量时间研究"招聘经理最痛苦的不是找简历而是筛选"（重新定义问题）然后重新设计产品（来源：Vettery Product Redesign, 2017）

**应用方式**：在开始想方案之前，先确认你真正确认了正确的问题。用 HMW 格式重写问题≥3 次。

**局限**：某些场景（如紧急 bug 修复）无法承受两轮完整探索。

### 原理 3: 重新定义问题比匆忙给出方案更有价值

**一句话定义**：大多数公司失败不是因为解错题而是因为做错了题。

**跨域证据**：
1. 交通出行：Uber 不解决"怎么让更多人坐出租车"而是重新定义为"如何让任何人随时获得可靠交通"（来源：Kalanick interviews, 2012-2015）
2. 住宿：Airbnb 不解决"怎么让酒店更便宜"而是重新定义为"怎么让人在任何地方找到住的地方"（来源：Chesky, Airbnb Origin Story, 2016）

**应用方式**：在你给出任何方案之前，用三种不同方式重新定义问题。选那个最大胆但有逻辑支撑的定义。

**局限**：过度重新定义可能导致拖延。"完美定义问题"不可得，需要在充分定义后敢于行动。

### 原理 4: 四阶段各有不同思维模式和产出

**一句话定义**：Discover→Define→Develop→Deliver 不是流水线，是认知状态切换。

**跨域证据**：
1. 设计咨询：IDEO 在每个阶段结束时用不同的 criteria 评估产出（Discover 阶段用洞察深度、Define 阶段用问题清晰度、Develop 阶段用方案广度、Deliver 阶段用可行性）（来源：IDEO, Human-Centered Design Toolkit, 2011）
2. 软件开发：Agile 的"发现-交付"双轨制本质上是双钻模型的工程化实现（来源：Sy, Dual-Track Agile, 2016）

**应用方式**：每进入一个阶段前，先问"这个阶段我的产出是什么？怎么判断这个产出够好了？"

**局限**：现实中阶段之间有大量回跳和重叠。双钻是框架不是操作手册。

## 操作协议（Agentic Protocol）

### Step 1: 问题分类

**适用信号**：
- 面对复杂的、定义模糊的问题
- 有多个可能方向但不确定哪个是最好的
- 团队在"做正确的事"和"正确地做事"之间需要结构

**不适用信号**：
- 问题简单直接只需执行（如修复已知 bug）
- 极度紧急的危机处理
- 已有明确解决方案的任务

### Step 2: 双钻式分析

**研究维度**（每个维度须追溯到核心原理）：

1. **发现阶段（Discover）**：发散探索问题空间
   - 来源原理：原理 1（发散收敛）+ 原理 2（问题vs方案空间）
   - 操作方式：广泛收集用户数据、做访谈、观察行为、研究市场——不评估，只收集

2. **定义阶段（Define）**：收敛锁定真正的问题
   - 来源原理：原理 3（重新定义问题）
   - 操作方式：从 Discover 中找到的 insight 中归纳出核心问题，用一句话定义

3. **开发阶段（Develop）**：发散探索方案空间
   - 来源原理：原理 1（发散收敛）+ 原理 2（方案空间）
   - 操作方式：对定义的问题产生尽可能多的方案（20+个），不评估

4. **交付阶段（Deliver）**：收敛锁定最终方案
   - 来源原理：原理 4（四阶段思维模式）
   - 操作方式：用用户反馈和可行性筛选方案，选最优，做小规模测试

### Step 3: 双钻式输出

- Discover 收获：3-5 个核心用户洞察
- Define 结果：一句话问题定义（HMW 格式）
- Develop 收获：Top 5 方案概念
- Deliver 计划：测试方案和迭代计划

## 适用/不适用判断

| 问题类型 | 适用度 | 说明 |
|---------|--------|------|
| 复杂产品定义 | 高 | 经典场景 |
| 服务设计创新 | 高 | 双钻本质是服务设计工具 |
| 用户体验重设计 | 高 | 适合 UXR 驱动的过程 |
| 已知方案的简单执行 | 低 | 不需要两轮探索 |
| 紧急操作问题 | 低 | 双钻太慢 |

## 典型案例库

### 成功案例

1. **BBC 数字化转型**（媒体/2010）
   - 问题：如何让 BBC 在数字时代保持相关
   - 方法应用：Discover（观众研究）→Define（锁定"个性化新闻体验"）→Develop（多个数字产品原型）→Deliver（iPlayer 等产品）
   - 结果：BBC 成为数字转型最成功的传统媒体之一
   - 来源：BBC Digital Transformation Case Study (2010)

2. **Vettery 产品重设计**（招聘科技/2017）
   - 问题：招聘平台用户体验差
   - 方法应用：Define 阶段花大量时间重新定义问题→发现真正痛点是"筛选"
   - 结果：重新设计后用户参与度大幅提升
   - 来源：Vettery Product Redesign Case Study (2017)

### 失败案例

1. **跳过 Define 阶段的代价**（产品设计/普遍）
   - 问题：团队从 Discover 直接跳到 Develop
   - 误用方式：调研回来后没有任何收敛直接开始画原型
   - 教训：没有 Define 阶段的双钻等于一个钻。第一个钻石的收敛（Define）是最被低估但最关键的步骤
   - 来源：Design Council, Eleven Lessons (2015)

## 误用检测器（≥3 种误用模式）

| 误用信号 | 检测逻辑 | 警告信息 | 建议动作 |
|---------|---------|---------|---------|
| 方法与问题不匹配 | 用户有明确需求只需要执行 | "你有清晰任务不需要双钻探索。直接用 agile 迭代更快。" | 推荐 agile |
| 跳过关键步骤 | 从 Discover 直接进入 Develop 跳过 Define | "你跳过了 Define——第一个钻石的收敛。不清楚正确地定义了问题就开发方案是最高风险的设计错误。" | 引导回 Define |
| 阶段混淆 | 在 Discover 阶段就开始评估方案可行性 | "Discover 阶段禁止评估。你的任务只是收集信息。评估发生在 Define 和 Deliver 阶段。" | 引导正确阶段行为 |

## 诚实边界（≥3 条具体局限）

1. **不适合简单线性问题**：修复 bug、常规运营优化不需要两轮发散收敛
2. **时间周期长**：完整双钻需要数周到数月，在迭代速度要求高的场景中不适用
3. **团队要求高**：双钻需要团队具备用户研究、合成洞察、原型设计等多种能力
4. **阶段不严格线性**：现实中会多次回跳。把双钻当作框架而非严格的甘特图

## 调研来源（一手来源占比须 >50%）

| # | 来源 | 类型 | 一手/二手 | 权重 |
|---|------|------|----------|------|
| 1 | British Design Council, The Double Diamond (2005) | 原始模型 | 一手 | 高 |
| 2 | IDEO, Human-Centered Design Toolkit (2011) | 方法指南 | 一手 | 高 |
| 3 | Design Council, Eleven Lessons (2015) | 研究报告 | 一手 | 高 |
| 4 | BBC Digital Transformation Case (2010) | 案例 | 一手 | 中 |
| 5 | Sy, Dual-Track Agile (2016) | 文章 | 一手 | 中 |
| 6 | Kelley, The Art of Innovation (2001) | 著作 | 二手 | 中 |

> 本 Skill 由 [Forge Skill — 锻造思维工具](https://github.com/peterfei/forge-skill) 生成