《设计原本》读书笔记一

第二章：理性模型
多数设计师会把所有的项线性相加，但线性方式不适合于衡量效用，因为边际效益会递减。（例如足够的电源插座是必要的，但过多的插座并不会提升总功能。但我们进行设计的时候，往往只是把数量简单相加）

在每个决策点设计师都可以有多种选择，因此设计的过程可以看作在“设计树”中寻找可行且较好的路径。（因此可以在某种程度上画出决策树来帮助思考）
TODO：尝试用思维导图来描述“设计树”

设计多数时间是在寻找“最低限度满足条件”的路径而不是最优路径。

第三章：理性模型的缺陷
设计中的最大难题是决定要设计什么。在初期就能获取完整的需求相当罕见，远非常态。

设计师的主要任务（和最有用的服务）在于帮助客户发现他们的需求，并提出对应的设计。

工程设计和研究工作不同，很少触及不能一眼看出通往解决方案的备选方案。（研究需要的是发现，可以在非常大的范围内探索，同时时间限制也不明显）

在逐步设计和并生成设计树的时候，其复杂性会超出人类思维理解的能力，因此其排序事关重大。同时由于组合爆炸的存在，我们无法遍历整个结构，因而很难对分支进行评估。

在设计过程中，所有因素相互牵制彼此交互，设计师对此的理解会逐渐加深，客户的观点也会随着反馈信息不断变化，因此前期的假设和需求都会持续变动。常见的问题是，人们发现只需负担很少的边际成本就可以增加某些需求，结果新的任务不断加入项目，导致需求蔓延，并且挤占了后期设计变更中需要的保留预算。

不仅是要求在变动，约束也是。

第四章：需求
在信息收集会议上，互投赞成票很流行，从而很多不切实际的要求会得到通过。同时，人们往往忽略了概念的完整性、效率、成本和健壮性。其结果是需求列表和约束往往让步于人际关系和官僚作风。需求制定者的领域知识也无法有效的传达到设计师。因此委员会方式制定需求在本质上有着过度研发的倾向。

要确保每一个新的需求都是从最初的总体需求中派生出来，而不是从某个用户代表或设计师的愿望出发而试图混入项目。要保证需求的单纯性。

组织通常会比其任何成员都更糟糕。

几乎每个人都知道：合同上写的一定会变化。

试图要求完整的需求往往源于人的欲望或组织的压力，比如固定价格合同，或者试图保证特定的交付。（要避免固定价格合同）

在建筑项目中，可以把设计和施工分为独立的合同。（但是在 IT 项目中，设计过程往往和施工过程紧密交错）

第五章：更好的模型
创新设计往往是问题和方案两者共同进行的迭代。（参考“共同演化模型”）

集市模型的问题：

只能在已经有收入的人群中在行得通
很多产品是副产品，通常仅仅为了满足构建者的需求而开发
市场选择机制进行质量调控
缺乏总体设计（在 Linux 案例中，可以把 Unix 作为规格说明）
当构建者和用户不同时，其设计难以进行
螺旋模型的问题：

以设计师而非用户为中心
难以形成合同