双钻模型：先做对的事，再把事做对

很多人第一次做产品时，最容易踩的坑不是“不够努力”，而是太快进入解决方案。​

脑子里刚冒出一个方向，就开始想页面怎么画、按钮放哪、要不要接 AI、要不要做登录注册、原型用什么工具画。忙了一圈之后，才发现最根本的问题根本没想清楚：用户到底是不是真的有这个痛点？这个问题值不值得现在解决？你以为自己在推进项目，其实只是很努力地在错误方向上加速。​

​

✅

双钻模型（Double Diamond）就是用来避免这种情况的。​

它最有价值的提醒是：“做对的事情”和“把事情做对”，是两个完全不同的阶段。 如果你还没搞清楚问题，就急着冲去做原型，通常只会把错误方向做得更完整。​

​

​

​

​

最小 SOP​

目的：看完后，你会更清楚做产品时什么时候该先想问题，什么时候才该开始想方案和原型，避免一上来就在错误方向上做得很认真。​

行动项：按 Discover → Define → Develop → Deliver 四步往下走，每一步只做当前阶段该做的事。​

结果：你会得到一个更清楚的问题定义、几种可比较的方案，以及一个可验证的最小版本。​

​

💡

你将学到以下内容​

双钻模型是什么，为什么它适合零基础做产品时使用​

Discover、Define、Develop、Deliver 四个阶段分别在做什么​

怎样区分“现在应该继续发散”还是“现在应该开始收敛”​

如何把双钻模型用在 AI 产品、原型设计和需求验证里​

​

​

双钻模型到底是什么​

双钻模型是英国 Design Council 推广的一套经典设计流程框架。它把一个完整的设计与创新过程，画成两个连续的钻石形状。​

之所以是“钻石”，是因为每个钻石都包含两种相反但都很重要的动作：​

•

发散：先把视野打开，看更多可能性​

•

收敛：再把范围缩小，做出判断和取舍​

整个过程一共四步：​

Discover：广泛了解用户、问题、环境和市场​

Define：从大量信息里提炼出真正值得解决的核心问题​

Develop：围绕核心问题发散多种解决方案​

Deliver：筛选、原型、测试并交付更合适的方案​

如果把这四步压缩成一句最容易记住的话，就是：​

•

第一个钻石：先搞清楚到底要解决什么问题​

•

第二个钻石：再决定用什么方案去解决它​

这也是你刚才说得很准确的那句话：​

•

第一个钻石：做对的事情​

•

第二个钻石：把事情做对​

​

​

​

为什么双钻模型特别适合新手​

新手做产品最常见的节奏，往往是这样的：​

•

想到一个点子​

•

觉得这个方向很酷​

•

马上开始画原型​

•

做着做着发现功能越来越多​

•

最后不知道自己到底在解决什么问题​

双钻模型的价值，不在于让流程变复杂，而在于 强迫你把“理解问题”和“设计方案”拆开 。​

这件事听起来很普通，但实际非常重要。因为很多失败的产品，不是执行不认真，而是：​

•

选错了问题​

•

误解了用户​

•

过早锁定了解决方案​

•

把大量时间花在细节打磨上，却没有验证方向​

双钻模型就是在不断提醒你：​

•

不要因为想法顺手，就默认问题已经成立​

•

不要因为方案能做出来，就默认它值得做​

•

不要因为原型看起来完整，就默认用户会真的需要​

​

第一个钻石：做对的事情​

第一个钻石关注的是 问题本身 ，而不是解决方案。​

你可以把它理解成一句话：先别急着做，先搞清楚到底值不值得做。​

​

​

3.1 Discover：先把问题空间打开​

Discover 阶段的核心任务，是 广泛调研，而不是快速下结论。​

这一步通常会做的事情包括：​

•

看用户在真实场景里怎么做​

•

访谈潜在用户，了解他们最近一次遇到问题是什么时候​

•

观察他们现在怎么凑合解决​

•

看竞品和替代方案都在怎么处理​

•

收集市场、流程、约束、上下游信息​

很多人会误以为 Discover 就是“多看点资料”。其实更关键的是：你要理解人和场景，而不只是搜一堆信息。​

比如你想做一个“AI 帮忙整理会议纪要”的工具，在 Discover 阶段更应该关注的是：​

•

用户开完会后到底哪里最痛苦​

•

是记录难，还是整理难，还是同步难​

•

他们现在是自己写、让实习生写、录音回听，还是干脆不整理​

•

哪些会议场景最需要纪要，哪些根本不需要​

这一步最重要的目标不是得出答案，而是 别太早以为自己已经知道答案。​

​

3.2 Define：从一堆信息里提炼出核心问题​

如果 Discover 是打开视野，Define 就是开始收束。​

Define 阶段要做的，不是把所有观察都保留下来，而是问：​

•

真正最值得优先解决的问题是哪一个​

•

哪个问题最常出现、最痛、最有价值​

•

我们第一版到底只盯住哪一个场景​

这一步的核心，是把一个宽泛话题，收敛成一个清晰问题定义。​

​

🌰

比如你一开始说：​

​

我想做一个提高开会效率的 AI 工具。​

​

到了 Define 阶段，更好的表达可能会变成：​

​

我们先解决项目型团队在 30 到 60 分钟协作会议结束后，无法在 10 分钟内输出带待办、责任人和截止时间的纪要这个问题。​

​

​

这时候问题就开始变清楚了：​

•

用户是谁​

•

场景是什么​

•

卡点是什么​

•

成功标准是什么​

Define 的本质，就是 从“问题很多”收敛到“这次先解决哪一个问题”。​

​

第二个钻石：把事情做对​

当你完成第一个钻石后，才真正适合进入第二个钻石。因为这时你解决的不是一个模糊方向，而是一个被收敛过的具体问题。​

​

​

4.1 Develop：围绕核心问题发散方案​

Develop 阶段的重点，是 围绕同一个问题，探索多种可能方案。​

​

⚠️

注意，这里的发散和 Discover 阶段不一样。​

•

Discover 的发散，是在探索问题空间​

•

Develop 的发散，是在探索解决方案空间​

​

比如还是会议纪要这个例子，到了 Develop 阶段，你可以开始想：​

•

是做网页工具，还是会议插件​

•

是上传录音后处理，还是实时记录​

•

是只做摘要，还是重点做待办提取​

•

是强调个人效率，还是强调团队同步​

•

是给用户自由编辑，还是直接输出结构化模板​

这一步很适合脑暴，也很适合和团队一起把方案拉开。​

但这里有一个前提：所有方案都必须服务同一个已定义的问题。如果问题没定义清楚，Develop 很容易又重新变成功能乱飞。​

​

4.2 Deliver：选择方案、做原型、测试和交付​

Deliver 阶段是第二个钻石里的收敛阶段。​

这时你要做的不是继续想更多，而是开始判断：​

•

哪个方案最适合当前阶段​

•

哪个版本最小但最有用​

•

哪些功能必须先做，哪些可以以后再说​

•

怎么做原型、测试和小范围验证​

很多人以为 Deliver 就等于“上线”。其实它更准确的意思是：把一个方案变成可测试、可验证、可迭代的东西。​

它可能是：​

•

一张低保真流程图​

•

一个 Figma 原型​

•

一个可运行的 MVP​

•

一次小规模用户测试​

•

一轮真实反馈后的迭代版本​

Deliver 的重点不是“完美交付”，而是 尽快把方案放进真实环境里验证。​

​

一个最容易记住的对照表​

如果你总是分不清四个阶段，可以直接记下面这个版本：​

​

​

再压缩一点，就是这样：​

•

Discover / Define：解决“做对的事情”​

•

Develop / Deliver：解决“把事情做对”​

​

双钻模型最常见的误区​

还没 Discover，就直接 Deliver​

这是最常见的一种。很多人刚有想法就开画原型、写 PRD、接模型、做页面。​

问题不是你做得不认真，而是你可能根本还没确认问题值不值得解决。​

Discover 很久，但始终不 Define​

另一种极端是一直调研、一直看资料、一直访谈，却迟迟不敢收敛。​

双钻不是让你无限发散，而是提醒你：发散之后必须进入判断和取舍。​

Define 之后，又偷偷改问题​

很多团队会在 Develop 时因为某个方案更容易做，就反过来修改问题定义，让它适配现有方案。​

这很危险。因为你可能不是在解决问题，而是在为自己偏爱的方案找理由。​

把 Deliver 误解成“大而全上线”​

Deliver 不是说必须把完整产品都做完才算结束。很多时候，一个可以测试的原型、一轮真实用户试用，已经是很好的 deliver。​

​

在 AI 产品里，双钻模型怎么用​

AI 产品特别容易掉进“能力先行”的坑里，因为模型能力看起来太诱人了。你会很想直接去想：​

•

要不要接多模态​

•

要不要做 Agent​

•

要不要加工作流​

•

要不要接语音、图像、联网搜索​

但双钻模型会逼你先问：​

•

用户到底在哪个环节真的卡住了​

•

这个卡点是不是非 AI 不可​

•

如果不用 AI，现有办法到底哪里最差​

•

AI 加进去之后，最核心的进展是什么​

这能帮你避免一种常见情况：能力很强，价值很弱。​

​

🔗

一个实用的顺序是：​

在 Discover 阶段观察用户现在怎么处理任务​

​

​

可以直接套用的双钻模板​

如果你正在做自己的产品，可以先按这个顺序往下写：​

Discover​

•

我观察到的用户是谁？​

•

他们最近一次遇到这个问题是什么时候？​

•

他们现在怎么解决？​

•

他们最烦、最慢、最不放心的地方是什么？​

Define​

•

这堆问题里，最值得优先解决的是哪一个？​

•

哪个场景最高频，或者最关键？​

•

我们第一版先只服务谁、只解决什么？​

•

成功解决后，用户状态会发生什么变化？​

Develop​

•

针对这个问题，有哪些可能方案？​

•

哪些方案最轻、最快、最容易验证？​

•

哪些是必须做，哪些是以后再说？​

Deliver​

•

我们最小可以交付什么来验证这个方向？​

•

是流程图、原型，还是 MVP？​

•

需要找谁测试？​

•

测试后怎样判断要继续、修改还是放弃？​

​

一个从零基础也能看懂的例子​

假设你想做一个“帮大学生准备求职简历”的 AI 工具。​

很多人一开始就会直接进入第二个钻石，开始想：​

•

要不要一键美化​

•

要不要智能改写​

•

要不要自动匹配 JD​

•

要不要生成自我介绍​

​

📌

但按双钻模型，更好的过程会是这样：​

第一个钻石​

Discover​

•

去聊应届生最近一次改简历是什么时候​

​

​

小结​

双钻模型最有力量的地方，是它帮你把一整团混乱拆成了四个更清楚的动作：​

•

先发散理解问题​

•

再收敛定义问题​

•

再发散探索方案​

•

最后收敛交付方案​

它不是让你变慢，而是让你 少走很多看起来很忙、其实方向不对的弯路。​

尤其在 AI 时代，做东西变得越来越快，双钻模型反而更重要。因为当“做出来”越来越容易时，真正稀缺的能力会变成：你有没有在解决一个值得解决的问题，以及你有没有用合适的方式去解决它。​

​

📌

记住这一句就够了：先做对的事情，再把事情做对。​

​

​

11. 如何利用 AI 帮你跑双钻流程​

双钻模型本身不是 AI 工具，但 AI 很适合在四个阶段里充当“加速器”。关键不是让 AI 替你决策，而是让它帮你扩展视野、整理信息、比较方案和生成验证材料。​

11.1 在 Discover 阶段，用 AI 先做一轮信息铺垫​

在正式访谈和调研前，你可以先让 AI 帮你做一些轻量级问题扫描，比如：​

•

市面上常见替代方案有哪些​

•

用户在公开社区里最常抱怨什么​

•

这个问题常见于哪些场景和人群​

•

现有产品通常忽略了什么​

这一步不能代替真实调研，但很适合帮你快速搭一个问题地图。​

一个很简单的小白输入可以是：​

​

代码块​

Plain Text

我想做一个帮大学生改简历的工具。​

​

AI 可能输出：​

​

代码块​

Plain Text

初步问题地图：​

​

1. 不知道该写什么经历​

2. 不知道怎么针对岗位修改​

3. 改了很多版还是不确定是否够好​

4. 需要别人帮看，但不方便总麻烦别人​

5. 因为不确定，所以一直拖着不投​

​

这种输出的作用不是替你下结论，而是让你更快进入 Discover。​

​

11.2 在 Define 阶段，让 AI 帮你收敛问题定义​

很多人收集了一堆资料之后，最难的是把问题收成一句真正清楚的话。你可以把调研笔记交给 AI，让它帮你压缩成几个候选问题定义：​

​

代码块​

Plain Text

​

这样你会更容易进入 Define，而不是一直停留在“问题好多”的状态里。​

你甚至可以把输入写得非常简单：​

​

代码块​

Plain Text

我现在收集到的问题有：​

1. 大家不知道简历写什么​

2. 大家不知道怎么改​

​

AI 可能输出：​

​

代码块​

Plain Text

建议优先解决的问题：​

​

“第一次投递实习的学生，不确定简历是否已经达到可投递水平，因此会反复修改并拖延投递。”​

​

原因：​

1. 这个问题更具体​

2. 它能解释拖延行为​

3. 更容易设计一个小版本去验证​

​

这类输出很有用，因为它帮你从一堆模糊问题里收出一个更像 MVP 起点的定义。​

​

11.3 在 Develop 阶段，用 AI 发散多个方案​

很多人一定义完问题，就只盯着脑子里第一个想到的方案。AI 在这一步很适合帮你强制发散：​

​

代码块​

Plain Text

我已经定义了一个核心问题：[你的问题定义]​

请你不要直接给我一个最终答案，而是从以下角度各提出 2-3 种解决方向：​

1. 最轻量的 MVP​

2. 最适合验证需求的方案​

3. 最适合提高体验的方案​

4. 不依赖 AI 的方案​

5. 依赖 AI 的方案​

最后请对比每种方案的优点、风险和验证成本。​

​

这样你就不会太早被单一方案绑住。​

一个简单输入可以是：​

​

代码块​

Plain Text

​

AI 可能输出：​

​

代码块​

Plain Text

方案 1：简历可投递检查清单​

方案 2：根据岗位描述做针对性改写​

方案 3：让用户上传简历后给出风险提示​

方案 4：提供优秀案例对照，帮助用户判断差距​

​

这时你就更容易进入“比较方案”，而不是一上来只盯着 AI 改写一个方向。​

​

11.4 在 Deliver 阶段，用 AI 帮你生成原型文案和测试材料​

​

🚀

当你进入 Deliver 阶段，AI 非常适合帮你加快这些工作：​

​

比如你可以让 AI 帮你生成一个 20 分钟用户测试脚本，或者帮你把 5 个用户反馈归纳成“继续做 / 修改方向 / 暂停”的判断依据。​

比如一个最小输入可以是：​

​

代码块​

Plain Text

我做了一个很简单的原型：​

用户上传简历，系统告诉他哪些地方还不适合投递。​

​

请帮我生成一份 15 分钟的用户测试脚本。​

​

AI 可能输出：​

​

代码块​

Plain Text

15 分钟测试脚本：​

​

1. 先请用户描述最近一次投简历经历​

2. 让用户独立完成上传简历​

3. 观察他是否看得懂反馈结果​

4. 询问：这些提示里哪些最有帮助，哪些让你困惑​

5. 询问：如果下次投递前，你会不会想再用一次​

​

这种输出很实用，因为它能帮你从“我做完原型了”走到“我接下来怎么测”。​

​

11.5 让 AI 扮演“阶段守门员”​

双钻模型最常见的问题，是人会跳阶段。你可以直接让 AI 充当一个守门员，提醒你现在到底在哪一步：​

​

代码块​

Plain Text

​

这对新手特别有帮助，因为你很容易在“还没想清楚问题时就开始画原型”。​

​

📚 Assignments​

请你根据上文内容，完成下列作业：​

选一个你最近想做的产品点子，写出它的 Discover、Define、Develop、Deliver 四步草稿​

在 Define 阶段，强迫自己把问题缩成一句具体的话​

在 Develop 阶段，至少列出 3 种不同方案，而不是只盯着第一个想到的做法​

在 Deliver 阶段，写出一个一周内能交付的最小验证版本​

​

延伸阅读​

这篇文章主要参考了 Design Council 关于 Double Diamond 的官方资料，适合继续往下看：​

•

Design Council: The Double Diamond​

•

Design Council: Framework for Innovation​

•

Design Council: History of the Double Diamond​

​

​