双钻模型是一种把“解决什么问题”和“怎样解决问题”分开推进的设计方法。第一个钻石先扩大了解范围，再收敛出值得处理的问题；第二个钻石先提出不同方案，再通过原型和小范围验证筛选。它适合需求含糊、团队急着做功能、用户抱怨与解决方案混在一起的项目。若只是修复已定位的按钮错误，就不必把四个阶段完整走一遍。
对产品经理和设计师而言，双钻的实际作用是减少“功能已经做完，才发现问题理解错了”的返工。方案阶段可以用墨刀原型把不同路径做成可点击页面，让参与者尝试完成任务，再决定留下哪条路径、修改什么规则。
双钻模型的四个阶段分别做什么
Design Council 的双钻模型使用 Discover、Define、Develop、Deliver 四个阶段，常译为发现、定义、发展、交付。两次先发散后收敛，分别针对问题和解决方案。实际工作可以往返，不是必须依次完成的四个审批关卡。
| 阶段 | 要回答的问题 | 可以做的工作 | 应留下的材料 |
|---|---|---|---|
| 发现 Discover | 谁在什么情况下遇到了什么困难？ | 观察当前操作，访谈当事人，对照服务记录 | 具体经历、原话与待确认的解释 |
| 定义 Define | 本次首先解决哪种困难？ | 归类问题，找共同条件，明确范围与约束 | 问题陈述、目标用户、本次不处理的范围 |
| 发展 Develop | 同一个问题还有哪些解决办法？ | 画不同流程，制作可比较的原型，评估成本 | 候选方案及各自要验证的假设 |
| 交付 Deliver | 什么可以继续投入，什么要修改或放弃？ | 测试任务，调整方案，小范围运行后观察 | 方案决定、未解决问题与后续观察安排 |
“发散”不是无限收集资料，“收敛”也不是领导挑一个喜欢的方案。发现阶段只收集会改变问题判断的信息；定义阶段应说明为何先处理这个问题；方案阶段允许提出成本和形态不同的办法；交付阶段则要看它是否真的改善了目标任务。
从“约不到会议室”开始：先查清是哪种问题
以社区共享会议室预约为练习。运营提出“做一个新的预约日历”，用户却只说“会议室总是约不到”。这两句话之间还缺少原因：可能房间确实不够，也可能页面没有展示空闲时段，或者房间被预约后无人使用。不同原因需要不同措施，不能仅凭一句抱怨就进入日历绘制。
发现阶段：问最近一次经历，而不是想要什么功能
先请使用者回忆最近一次预约：当时需要几个人的房间，目标时段是什么，打开了哪些页面，在哪一步放弃，后来如何解决。能查看操作过程时，让对方按原来的方式走一遍；不能查看时，区分对方的回忆与系统实际记录。不要用“有个日历是不是更方便”引导回答。
同时接触场地管理人员，了解开放时间、清洁间隔、预约权限和取消规则。现场明明有空房，却因维护或活动锁定不能预约，与界面漏显示空闲房不是同一类问题。记录里应保留这些条件，避免把运营限制都算成界面缺陷。
| 记录内容 | 练习中的写法 | 下一步怎么确认 |
|---|---|---|
| 用户描述 | “我点开几个房间，都显示这个时间已占用。” | 还原日期、人数和设备条件 |
| 可以观察的行为 | 在房间详情与日期选择之间反复返回 | 检查是否必须逐间进入才能看空闲时段 |
| 团队解释 | 用户可能无法同时比较多个房间 | 对照其他人的经历，并测试直接展示时段的方案 |
| 其他可能原因 | 目标时段真的没有满足条件的房间 | 与可预约库存及管理规则核对 |
这张记录表的意义是防止把猜测升级成事实。若只访谈了白天来场地办公的人，就不能据此代表晚上举办活动的人。下一轮找谁，应由当前缺少哪类使用条件决定；用户研究方法的选择可以继续阅读用户研究方法。
定义阶段：把抱怨改写成可处理的问题
假设核对后，主要障碍是“需要在多个房间详情中反复查看可用时段”。问题陈述可以写成：需要临时预约小型会议室的社区成员，难以在指定日期找到符合人数和设备要求的空闲时段，因为房间状态分散在多个详情页。这段话说明了谁、做什么、受什么阻碍，但没有提前规定必须做日历。
本轮可以把目标定为“用户能够找到一个符合条件的可用时段，并确认预约结果”；暂不处理新增场地、会员价格和长期包租。约束包括既有开放时间、人数上限、清洁间隔和权限规则。把这些写在方案旁边，团队才不会在不同前提下比较设计。
如果发现问题主要是房间供给不足，应回到运营方案讨论，而不是继续美化筛选器。定义阶段允许改变原始需求，这正是第一个钻石有价值的地方。
发展阶段：比较解决路径，不只比较两种视觉风格
面对同一个预约问题，可以提出三种不同路径：先选日期再看可用房间；先选房间再看一周空闲时段；输入人数、设备和时间范围，由列表展示符合条件的组合。它们改变的是用户寻找答案的方式，不只是卡片颜色。
| 候选路径 | 适合的起点 | 需要验证的风险 |
|---|---|---|
| 日期 → 可用房间 | 用户时间确定，房间可替换 | 列表是否清楚区分可预约、已占用和条件不符 |
| 房间 → 一周时段 | 用户需要指定设备，可以调整时间 | 在手机上查看一周是否过密、跨日是否容易误选 |
| 条件 → 可用组合 | 人数、设备和时间都有要求 | 没有结果时，是否说明应该放宽哪个条件 |
先为最有希望的两条路径制作等保真度原型：使用相同的房间、日期、人数和可用状态，避免一份精致、一份潦草造成偏好。每份至少包含查找入口、可用结果、预约确认与成功结果；再补一个无匹配时段的分支。视觉细节只需要清楚到能够完成任务，无须先画齐所有管理页面。
在墨刀中，把两条路径放在清楚命名的页面组里，连接选择时段、返回修改、确认预约等动作。占用不能只用灰色表达，要同时标注“已占用”；提交后要能确认房间、日期和时段。评审评论应落在具体页面或元素上，例如“返回后丢失人数条件”，方便下一次修改，而不是留下“体验再优化一下”。
交付阶段：让用户完成任务，再决定如何改
测试任务可以这样写：“你要在周六下午组织六人讨论，需要投屏设备，请找到一个可用时段完成预约。”不给参与者提示应该先点日期还是房间，也不要先演示正确路径。观察对方怎样寻找信息、在哪里停顿、是否误把已占用时段当成可预约。
同一个人测试两份方案可能因为熟悉任务而在第二次表现更好。可以调整方案出现的顺序，并分别记录第一次遇到的困难；参与人数少时，重点是找到可解释的障碍，不把几个人的偏好直接推广成所有用户的比例。
- 能够找到房间，但确认时段看错：先改日期和时间的展示、确认页及返回修改路径，再复测同类任务。
- 一直没有可预约结果：核对库存与筛选条件；若确实无供给，界面应说明原因和可用替代时段。
- 看见可用时段却不敢提交：查清费用、取消规则或权限是否不明确，未必需要重做整个布局。
- 方案解决不了定义的问题：退回发展阶段换路径；如果发现真实障碍与原判断不同，则退回定义甚至发现阶段。
原型验证的是理解与操作路径。正式上线还要由研发处理并发预约、权限、保存失败和状态一致性，不能把“原型能点通”当成这些能力已经具备。小范围上线后，可以观察查找失败原因、预约冲突和取消后的状态更新，再决定是否扩大使用范围。
双钻模型与设计冲刺、设计思维有什么区别
双钻更适合帮助团队说明当前是在理解问题，还是在探索解决办法，以及何时需要回退。设计冲刺把一组设计与测试活动放入明确的时间安排，适合围绕一个问题集中推进；它可以用于第二个钻石，也可能帮助团队重新理解问题。设计思维则常被用来概括以人为中心、持续试验的思考与工作方式，各组织的阶段划分不同。
因此，不必在这些名称中选一个排斥其他方法。需要集中安排一轮原型测试时，可参考设计冲刺与原型验证的安排；需要判断当前是否过早锁定解决方案时，再用双钻检查问题定义。它们解决的管理问题不同。
团队第一次用双钻，怎样避免把流程做重
从一个真实、范围明确的问题开始，为四个阶段各留一块记录区即可。发现区放经历和疑问，定义区放问题陈述，发展区放候选路径，交付区放试用结果和决定。不要为了填满模板而收集资料，也不要要求所有项目按相同时间比例执行。
对每次讨论，只追问当前还缺哪条信息：问题不清就去看用户如何操作；路径不清就画出两个候选；测试发现错误就修改并复测。会议结束时明确下一步动作与负责人。最终应留下的是能继续推进的选择，而不只是两枚画得漂亮的钻石。
