设计思维、双钻模型与复杂问题解决
设计思维的价值
很多 UX 项目的风险，常常在第一次会议就埋下了。有人说重做首页，有人说加会员功能，有人说接入 AI，设计师看似拿到了需求，其实拿到的只是一个未经验证的解法。
客户可能一开始就说："我们想重做首页。"业务方可能说："我们需要一个新的会员功能。"老板可能说："竞品都有 AI，我们也要加。"这些需求听起来都很明确，但它们往往只是方案，不一定是真正的问题。
如果团队直接接住这些方案，很快就会进入执行：画原型、排期、开发、上线。等上线后才发现，首页变漂亮了，用户仍然找不到"开始配置"的入口；会员功能做出来了，用户仍然不愿意续费，因为续费前最关心的权益差异没人说清；AI 聊天框上线了，客服成本没有降，反而多了一批"AI 说错了怎么办"的追问。
设计思维和双钻模型像一次"倒带"。评审会原本要看首页稿，团队却先回放新用户第一次进入产品的十分钟：他看见五个入口，点进模板库，又退回首页，最后没有创建第一个项目。问题从"首页够不够高级"，变成"第一步任务有没有被接住"。这才是它们真正能发挥作用的地方。
复杂问题不能靠一次头脑风暴解决，也不能靠用户一句话、老板一个判断或竞品一个截图解决。团队需要先打开问题空间，再收敛出值得解决的问题；再打开方案空间，最后收敛到可验证、可交付的方案。
问题空间与方案空间
设计思维到底是什么？不是灵感生成工具，是帮助团队在不确定中理解人、定义问题、探索方案和验证假设的工作方式。
当用户说"报销系统太难用"，团队不能马上开始重画表单。设计思维会先追问：难用发生在哪一步？是票据上传、费用分类、审批规则、驳回原因，还是进度不透明？不同问题会导向完全不同的方案。
设计思维通常被表达为同理、定义、构思、原型、测试五个词。但这些词不应该被理解成固定线性流程。更准确地说，它是在信息不完整时靠近人和情境，摆出多个可能原因，再用草图、原型、访谈、数据或小实验排除错误方向。
双钻模型是 Design Council 用来表达设计过程的经典框架。它用两个"发散-收敛"的菱形描述四个阶段：发现、定义、发展、交付。1
第一个钻石处理问题空间。发现阶段打开视野，收集用户、业务、技术、服务和组织证据；定义阶段收敛问题，明确真正值得解决的挑战。
第二个钻石处理方案空间。发展阶段打开多个可能方案；交付阶段收敛、测试、迭代并准备落地。
双钻的价值不在四个英文词本身。它提醒团队两件事：不要太早说"问题就是这个"，也不要太早说"方案就是这个"。
发散是打开可能性，收敛是做选择。发散不是漫无边际地想点子，而是有目的地扩大观察范围。比如听业务方说法的同时，也看用户行为、客服工单、数据漏斗、后台流程和竞品差异。收敛也不是谁声音大听谁的，而是基于证据和约束做判断。比如哪些问题影响最大，哪些用户最关键，哪些方案风险最低，哪些假设必须先验证。
问题空间回答"到底发生了什么、为什么值得解决"。方案空间回答"可以怎么解决、如何验证和落地"。
很多项目失败，是因为团队把问题空间压缩得太短。用户反馈"找不到入口"，团队直接加一个按钮；客户说"流程慢"，团队直接缩短页面；老板说"要 AI"，团队直接放一个聊天框。看起来快速响应，实际可能只是把表面现象做成了功能。
假设
假设是团队对问题、原因、用户行为和方案效果的可验证判断。
例如："用户在第三步放弃，是因为费用出现太晚导致不信任。"这就是假设。它可以通过数据、访谈、可用性测试或 A/B 测试验证。比起"用户觉得体验不好"，假设更可行动，也更容易被证伪。
概念边界
设计思维不是固定五步法。 很多教材会把设计思维写成同理、定义、构思、原型、测试五步。这种表达适合入门，但真实项目往往不会线性进行。你可能在原型测试后发现问题定义错了，需要回到研究；也可能在方案评审时发现业务约束比想象复杂，需要重新定义机会；还可能在上线后发现指标没有变化，需要回到问题空间重新分析。设计思维是一种反复学习、验证和调整的方式，不是"按五步走完就成功"。
双钻不是项目排期模板。 双钻能帮助团队理解项目阶段，但不能直接当作排期模板。有些项目的发现阶段可能只需要几天，因为问题已经被大量数据和研究证明；有些项目的定义阶段可能要持续数周，因为利益相关者多、规则复杂、风险高。双钻描述的是思考逻辑，不是固定工期。如果团队只是把排期表分成 Discover、Define、Develop、Deliver 四栏，却没有真正发散和收敛，双钻就变成了包装。
工作坊不能替代设计思维。 工作坊可以帮助团队快速对齐，但工作坊本身不是设计思维。一次便利贴工作坊能收集观点，却不能替代用户研究；能产生想法，却不能证明想法有效；能让团队兴奋，却不能自动形成产品决策。好的工作坊前面要有证据输入，后面要有决策输出和验证计划。否则，它只是一场气氛不错的会议。
创新不等于新功能。 复杂问题的解决方案不一定是新功能。有时最好的方案是删掉一个步骤，重写一段说明，改变后台交接方式，调整默认规则，增加人工支持，或者决定不做某个功能。比如发现用户续费犹豫的原因是权益差异不清，就先别急着加积分商城；发现报销失败集中在票据规则，就先别急着重做整套表单。
设计思维与敏捷应互补而非替代。 设计思维更强调发现问题、定义机会和探索方案；敏捷开发更强调持续交付和迭代。两者可以配合，但不能互相替代。如果没有问题定义，敏捷只是更快地交付不确定价值。如果只有设计探索，没有工程交付，设计思维也会停在概念阶段。成熟团队会让发现、定义、设计、开发、验证形成连续工作流。
双钻的四个阶段
第一个阶段是发现。团队要问：我们到底看见了什么？证据可以来自访谈、观察、数据、客服工单、业务指标、服务流程、竞品分析和利益相关者讨论。
第二个阶段是定义。团队要问：这些材料指向哪个真正值得解决的问题？目标用户是谁，他们在什么情境下遇到什么阻碍，这个阻碍为什么重要？
第三个阶段是发展。团队要问：除了眼前这个方案，还有没有更便宜、更稳、更容易验证的方向？比如同一个"新用户不上手"问题，可以有内容引导、流程简化、模板推荐、人工陪跑、默认配置、产品内反馈等多个方案。
第四个阶段是交付。团队要问：怎么把方案变成可执行结果，并在上线后继续观察真实影响？原型、可用性测试、实验、技术评估和上线复盘，都属于这一步。
双钻模型最容易被误解的地方不是"发散"本身，而是不知道什么时候该收敛。某 SaaS 团队在发现阶段做了三个月研究，每次汇报都带着新资料——更厚的访谈记录、更多的竞品截图、更细的用户分群。产品经理第五次催问"能不能开始设计"时，研究负责人反问"你确定问题已经清楚了？"关系僵了。
这不是研究不被尊重。这是研究变成了"不开始设计"的挡箭牌。最后团队在第四个月强制收敛，回看前八周的访谈记录时发现，答案在第二周的第三次访谈里就已经出现了——后面的十周不是在收集证据，是在躲避决定。收敛不是结束探索，而是承认"现有的证据已经够做出一个足够好的判断"。
方法
假设客户说："我们要重做 App 首页。"
低质量执行会直接问："你喜欢什么风格？"然后进入视觉设计。
更好的做法是先把需求翻译成问题假设：为什么要重做首页？是用户找不到核心功能？新用户不知道从哪里开始？老用户觉得信息太乱？业务希望突出新产品？还是管理层认为品牌形象过时？
接着收集证据：首页点击数据、搜索词、客服反馈、用户访谈、可用性测试、运营位转化、业务优先级。最后可能发现，首页最大的问题不是"不够高级"，而是新用户第一次进入后看见五个入口，却不知道哪一个会带自己完成首个关键任务。此时方案可能不是重做视觉风格，而是重排任务入口、减少运营干扰，并给新用户一个明确的开始动作。
假设清单
双钻不是只产出洞察，也要产出可验证假设。
一份假设清单可以包含：
| 假设 | 证据来源 | 风险 | 验证方式 | |---|---|---|---| | 新用户不知道第一步该做什么 | 访谈、行为路径、帮助文档访问 | 可能只是样本偏差 | 新手任务测试、漏斗分析 | | 价格说明出现太晚导致支付前放弃 | 漏斗数据、客服工单 | 可能受促销和价格影响 | A/B 测试、可用性测试 | | 后台审批慢的感知来自进度不透明 | 用户访谈、催办工单 | 真实处理时长也可能过长 | 服务蓝图、工单分析 | | 用户不采用新功能是因为不知道价值 | 采用率、访谈 | 功能本身可能无价值 | 原型测试、引导实验 |
假设的价值在于让团队承认不确定性。它不是结论，而是下一步验证的对象。
利益相关者协作
复杂问题很少只属于设计团队。
如果是医保报销流程，用户、医院、医保部门、支付系统、客服、线下窗口、政策制定者都可能影响体验。如果是企业软件权限配置，管理员、员工、IT、安全、法务、人事、供应商都会参与。如果是 AI 产品，模型团队、数据团队、产品、设计、法务、客服和安全团队都必须参与。
因此，设计思维中的共创不是为了热闹，而是为了让不同角色把各自的约束、证据和风险带到同一张桌上。
进入交付前
在进入开发或正式实施前，团队至少要回答五个问题。
问题是否已经被证据支持？目标用户和关键情境是否清楚？方案解决的是根因还是表面现象？成功指标是否明确？哪些风险和假设还没有验证？
如果这些问题答不上来，进入交付只会把不确定性推到后面。项目不是不会推进，而是更可能在上线后用更高成本修正。
实际场景
场景 1：客户要求"重做页面"。 客户说"页面太乱，想重做"，这类需求很常见。如果团队只把它理解为 UI 项目，交付物可能是一套更干净的界面。但如果问题来自信息架构混乱、业务优先级冲突、用户任务不清、内容堆叠或运营位过多，单纯重做视觉不会解决根因。双钻的做法是先进入发现阶段：看用户真实任务、页面点击、搜索行为、客服反馈和业务目标。再进入定义阶段：到底是"页面不好看"，还是"用户不知道从哪里完成关键任务"？
场景 2：业务提出"加 AI 功能"。 现在很多项目会从一句话开始："我们也要加 AI。" 这句话本身不是问题定义。团队要先问：AI 要解决谁的什么问题？用户是否需要自动生成、智能推荐、风险识别、问答解释，还是人工流程提效？如果只是为了显得先进，AI 可能增加误导、维护成本和信任风险。设计思维在这里的作用，是把技术冲动拉回用户任务。先验证问题，再判断 AI 是否是合适方案。很多时候，客服真正缺的不是一个会寒暄的聊天框，而是能看懂订单状态、知道哪些问题必须转人工、能把错误回答留下复盘记录的工作流。用户真正需要的，也可能只是更清楚的状态、更好的模板、更少的重复输入，或者更可靠的人工接管。
场景 3：企业后台效率低。 企业后台项目经常有很多"需求"：批量导入、审批提醒、权限模板、统计报表、字段配置。每个需求都有道理，但资源永远有限。设计思维会帮助团队从需求清单回到工作流。用户真正卡在哪里？是重复录入、规则不清、跨系统切换、审批等待，还是错误后无法恢复？如果根因是审批规则和职责不清，新增报表未必有用；如果根因是字段命名不一致，做更多提醒也可能只是增加噪音。
场景 4：公共服务问题。 公共服务问题往往更复杂，因为它牵涉政策、服务、组织、线下渠道和不同能力的人群。比如一个补贴申请服务，用户体验差可能不是网页问题，而是资格规则复杂、材料难准备、线上线下信息不一致、审核周期不透明、咨询渠道分散。此时设计思维不能只停留在界面，而要和服务设计、政策设计、内容设计、数据和运营一起工作。相关公共设计证据可见 GOV.UK 的 Public Design Evidence Review。4
案例
Design Council 的双钻框架不是公司产品案例，而是方法来源。它把设计过程清楚表达给设计师和非设计师：先发现和定义问题，再发展和交付方案。 它的价值在于帮助团队避免两种常见错误：一是太早假定问题，二是太早锁定方案。双钻也能用来评估项目：有足够的问题探索吗，有方案验证吗，还是一上来就进入制作。双钻是过程框架，不是成功保证。团队如果没有真实研究、没有明确决策、没有可执行验证，画出双钻也不会自动让项目更好。2
Intuit 的 Design for Delight 是一个企业将设计思维内化为创新方法的公开案例。其核心原则包括 Deep Customer Empathy、Go Broad to Go Narrow 和 Rapid Experiments with Customers。 深度客户同理帮助团队理解真实问题，广泛探索再收敛帮助团队避免单一方案偏见，快速实验帮助团队用更低成本验证关键假设。它说明设计思维不只是 UX 团队内部方法，也可以成为跨团队工作语言。3
IBM Enterprise Design Thinking 和 Sponsor User Program 用来说明大型组织如何把用户参与、团队对齐和业务目标连接起来。IBM 相关资料强调 Hills、Playbacks、Sponsor Users 等机制，用于帮助团队围绕人本结果推进工作。 Forrester/IBM 的 TEI 材料也常被用来讨论组织层设计思维价值，可作为估算方法的参考。 需要注意的是，这份材料属于厂商委托研究，引用时应说明其来源背景。56
一个工作坊是否有用，不取决于墙上贴了多少便利贴，而取决于会前是否有真实证据，会后是否改变了决策，上线后是否继续验证。
在发现阶段，可以看证据覆盖是否充分——是否包含用户研究、行为数据、客服工单、业务指标、服务流程和利益相关者观点；是否只听了内部意见；是否识别了关键假设。在定义阶段，可以看问题陈述质量——是否说明目标用户、情境、阻碍、影响和证据；是否把功能需求误当问题；是否明确了成功标准。在发展阶段，可以看方案广度和假设质量——是否探索了多个方案方向；是否有筛选标准；是否识别了高风险假设；是否避免一开始就锁定某个方案。在交付阶段，可以看验证指标——原型测试结果、任务成功率、错误率、完成时间、采用率、转化率、客服工单、投诉率、上线后复盘。
还有一类组织指标也值得关注：返工率、跨部门对齐速度、项目因问题定义不清而推倒的次数、可复用洞察的沉淀数量。
这些指标都需要放在具体语境中解释。设计思维通常和产品策略、工程能力、组织协作、市场环境一起发生作用，不能把所有结果都归因于某次工作坊或某个框架。
常见误区
工作坊可以帮助对齐，但不能替代研究、分析、验证和决策。好的做法是工作坊前准备证据，工作坊中形成判断，工作坊后安排验证和责任人。
双钻描述的是发散和收敛的思考逻辑，不是所有项目都必须严格按四个阶段平均分配时间。正确的做法是根据问题的不确定性来调整每个阶段的深度，而不是机械地套用固定工期。
用户能描述痛点，但痛点背后的根因需要分析。把用户反馈转化为任务、情境、行为和证据，再定义问题，而不是直接把用户原话当作问题定义。
想法多不等于质量高。如果没有问题定义和筛选标准，头脑风暴只会制造更多噪音。先明确判断标准，再发散方案。
原型不只是展示工具，更是学习工具。低保真原型也可以验证关键假设。先问"这个原型要验证什么"，再决定保真度。
设计思维能降低不确定性、改善协作和提高问题定义质量，但商业结果还受产品、技术、市场、运营、销售和组织执行影响。把设计思维写成证据链和决策方法，而不是写成万能 ROI 公式。
设计思维和双钻模型的价值，不在于让项目看起来更专业，而在于把"我们觉得应该这样做"改成"我们为什么这样判断、哪些证据支持、哪里还要验证"。先理解人和情境，再定义问题，再探索方案，再验证学习。问题空间要先发散再收敛，方案空间也要先发散再收敛。
不要把方法论停留在口号和模板上。问题陈述、假设清单、验证计划和决策记录才是真正有用的。一个专业团队不会只说"我们用设计思维"，而会把判断摊开：从哪些用户行为和业务信号进入问题，为什么把首页视觉需求改写成新手任务问题。它还会说明：为什么先验证模板推荐而不是直接开发 AI 助手，上线后准备看哪些结果。
方法不能替代判断，但好的方法能让判断更透明、更有证据、更容易协作。
Design Council 的 *Framework for Innovation* 完整阐述了双钻模型从发现到交付的逻辑，是团队对齐的基础读物。1
注释
1 Design Council, Framework for Innovation / Double Diamond。双钻包含发现、定义、发展、交付和发散/收敛逻辑。 🔗 https://www.designcouncil.org.uk/our-resources/framework-for-innovation/
2 ISO 9241-210。人本设计强调理解情境、需求、方案和评估的迭代。 🔗 https://www.iso.org/standard/77520.html
3 Intuit, Design for Delight。企业可将设计思维内化为同理、发散收敛和快速实验方法。 🔗 https://www.intuit.com/company/corporate-responsibility/job-readiness/design-for-delight/
4 GOV.UK Public Design Evidence Review: Case Study Bank。公共服务复杂问题可使用设计实践处理政策、服务和组织问题。 🔗 https://www.gov.uk/government/publications/the-public-design-evidence-review/public-design-evidence-review-case-study-bank-html
5 IBM Enterprise Design Thinking。大型组织可通过 Sponsor Users、Hills、Playbacks 等机制推进设计思维。 🔗 https://www.ibm.com/design/thinking/
6 Forrester, The Total Economic Impact of IBM Design Thinking。设计思维 ROI 估算需谨慎使用厂商委托研究。 🔗 https://www.forrester.com/report/The-Total-Economic-Impact-Methodology-A-Foundational-Framework-For-Investment-Decisions/RES42030