2．溯因推理或设计思维

本研究的第一步就是要注意（协同）设计是通过特殊的逻辑形式进行的，而且还不足以把设计理解为一种科学或工程形式。科学通常关心的是描述和理解过去或现在的情况以及发现“事实”，而设计关心的是构想和实现可选择的情况，关心的是事实和价值。此外，工程通常关注解决事先给定的问题，并找到“最佳”的解决方法，而设计同时关注探寻多种问题的界定方法以及寻求不同的解决方案。笔者加上“通常”意在承认科学家或工程师的实践做法与教科书或者管理话语中“通常”描述或规定的实践是相当不同的。大量研究表明，在科学和工程实践中，事实与价值往往交织在一起，同时被处理的，而且问题的设定和解决方案的形成都是探索和迭代的过程。

把（协同）设计过程看作是溯因推理过程可能更加充分一些。“溯因”一词是由实用主义哲学家C.S．皮尔斯提出来的，它是一种不同于演绎或归纳的推理：“演绎证明了既定的事实，归纳表明了事情的可操作性，溯因仅仅表明了事情的可能性。”

以下举例说明这三种类型的推理。演绎推理是由两个或多个前提得出一个结论。例如，基于“人总是难免一死”（p→q），以及“苏格拉底是人”这两个前提（p），可以推断出“苏格拉底难免一死”（q）。这种类型的推理主要用于数学和逻辑。归纳推理是通过一系列的观察推断出一般性结论。例如，我们观察到“铜被加热后会膨胀”（p1→q1）, “钢被加热后会膨胀”（p2→q2），等等。那么就可以得出“金属被加热后会膨胀”的结论（p→q）。这种类型的推理主要用于自然科学和社会科学。溯因推理是根据当前所处的具体情况作为问题的出发点（p），同时迭代构想接近和设定该情况的途径（p → q）以及问题的可能解决方案（q）。这种类型的推理在设计中经常用到。

同样，多斯特（Dorst）最近认为，溯因推理是设计思维的“核心”。多斯特将演绎理解为从了解“是什么”和“怎么样”到“结果”的过程（例如，知道恒星的运动轨迹，就可以推断星星的位置），归纳的过程是从了解“是什么”和“结果”到可能的选项“怎么样”（例如，如果知道恒星及其位置，就可以归纳出恒星可能的运行机理）。他提出了两种溯因推理的形式。溯因推理1（封闭性问题解决）：根据给定的期望“结果”和给定的运行机理（“怎么样”），形成一个对象（“是什么”）；溯因推理2（开放性问题解决）：根据一个期望的结果，形成一个对象（“是什么”）和一个运行机理（“怎么样”）。后者与设计思维和设定的概念相关。设定是迭代制定框架（即组合结果和运行机理）以及制定可行的解决方案，从而在设计过程中创造性地在“结果”、“怎么样”和“是什么”之间转换。

因此，设计思维是一个迭代过程，问题和可能的解决方案是被同时探索、制订和评估的：“设计过程不仅包括解决问题，也包括发现问题”，从而使“问题设定和解决方案制定共同展开。”设计思维是用来解决“棘手问题”的，即在项目的开始，并不能明确界定使用的“事实”，并且无法选择一个“最佳”的解决方案的问题。现实世界中有很多问题都是“棘手问题”。

协同设计是不同的人参与设计思维的过程。在下面的章节中，笔者认为可以把协同设计理解并组合为合作设计思维过程，或者借鉴实用主义哲学家约翰·杜威的思想，协同设计是共同探究和构思的过程。