系统思维和设计思维：怎么一起用

系统思维和设计思维的区别，主要在关注点上：系统思维看的是关系、反馈、边界和反复出现的模式；设计思维做的是开发并测试满足人需求的做法。两者可以配合。系统地图能揭示一个问题为什么一直存在；以人为中心的原型能在一个可控的规模上测试某项干预。两个方法都不保证成功，也都不能替代证据。先把问题定义清楚：你需要理解一个相互作用着的模式，开发一段体验或一项服务，还是两样都要？整个过程里，都要把假设、受影响的人、以及某个改动可能带来的更广影响摆在明面上。

对比

这个对比说的是关注点差异，不是各自独占的领域。系统层面的工作会涉及受影响的人，设计层面的工作也可以检视更大的系统。

MIT 对系统思维的说明强调各部分之间的相互连接。Stanford d.school 的设计思维手册把同理、定义、构想、原型、测试列为设计思维的几个模式。这并不意味着必须按一条僵硬的单向流程走。

实例拆解

假设一个社区服务出现了预约未到场的情况。这个服务希望更多人到场，同时不增加不必要的压力和行政负担。

系统思维这一遍会问：预约是怎么订的、人们收到什么信息、提醒什么时候发、排期怎么改、错过预约之后会发生什么。在一个明确划定的范围内，这遍还包括交通、人员配置、承载量和延迟。

地图给出几种可能的解释：人们可能收到的时间不明确、没法改期、遇到现实中的到场限制，或者已经不需要这项服务了。这些是假设，不是对参与者的诊断。

设计思维这一遍会通过合适的、征得同意的流程和参与者交谈，做一个小型的提醒或改期原型。它要问的是：人们看得懂这条信息吗、按它去做行得通吗、觉得这个方案有用吗。

这张表和这个场景是原创的。它们并不表示提醒总能减少预约未到场，也不表示每个参与者都需要同样一条信息。

组合两种方法

1. 框定结果和边界。 说清楚在考察谁的体验、哪一个流程。
2. 收集相关证据和不同视角。 把观察和解读分开。
3. 画出候选关系。 在反馈和延迟确实可能起作用的地方把它们放进去。
4. 选一个有边界的干预。 明确它预期要改变什么。
5. 做一个规模合适的原型。 让参与方式和信息使用程度与任务相称。
6. 测试可用性和系统影响。 一条信息可以既表达清楚，又把工作量推给一个人手不足的渠道。
7. 修改方案，也修改解释。 一次测试既可能暴露出缺失的关系，也可能暴露出设计问题。

放到预约这个例子里，一条提醒可能让改期请求变多。这既可能提高到场率，也可能抬高行政工作量。一个在局部成功的原型，仍然需要一个可行的办法来接住这波反应。

反馈回路指南讲了一个响应如何放大或抵消某个模式。冰山模型帮忙从一个可见的事件，走到反复出现的安排和假设。

局限

不要只凭名声就挑一个方法。一个简单的事实错误可能只需要纠正，不需要开一场精心设计的工作坊。一个有明确口径的计算，可能需要的是合适的模型，而不是一场开放式头脑风暴。

系统地图可能画得太大，大到没法检验。记下它的边界，并标明哪些关系是有证据支持的、哪些是推断的、哪些还不知道。箭头更多并不等于解释更好。

设计原型可能过拟合到参与的人身上。想一想谁没参加、他们的限制条件是否不同，以及这项服务在目标规模上还跑不跑得动。几条好评不等于一次完整的结果评估。

两种做法都需要一个关于下一步的决定。记下提出的改动、证据、负责人、剩下的不确定处，以及复盘条件。决策框架指南能帮你在还有几个行动都可行的时候，选一种比较方式。

想了解关系和反复出现的模式，看系统思维。要看怎么说和证据的通用评估方法，看批判性思维。

常见问题

哪个方法更好？

看任务。理解一个相互作用着的模式，和开发一个可用的干预，是相关但不同的两种需要。把相关的动作组合起来，而不是宣布一个普适的赢家。

我能不能先做原型，再画完整的系统地图？

可以，只要这次测试规模合适、可回滚，而且它的重要影响有人监测。完整的模型很少能拿到。把假设和边界写明确。

设计思维是不是忽略了系统？

不是。这个区分是关注点上的。好的设计工作会考虑系统约束和后果；好的系统工作也会纳入人的体验和需要。