Christopher Alexander 于2022/03/17 过世，享年 85 岁。他被广泛地描述为过去半个世纪最有影响力的建筑师和城市规划专家。 作为一位著名的建筑师，其以人为本的设计理念影响了诸如城市设计，软件设计和社会学等诸多领域，甚至被认为是模式语言运动之父 —— Wikipedia 便是来自于他的这种设计理念。
而我在 2014 年的时候读到其 1979 年的著作《建筑的永恒之道》，被其隽永的语言所打动，可以说改变了看待「产品设计」的视角。
但由于个人能力原因，无法消化其背后的思想，只断断续续记录了一些碎片。时隔多年再次阅读，希望能从中找到建筑设计与产品设计的交叉点。
本文也受到 Basecamp 产品管理专家 Ryan Singer 的演讲《Designing with Forces： How to Applied Christopher Alexander in Everyday Work》的启发。

形式（form）与情境（Context）适合

每个设计问题都始于努力实现两个实体之间的适应性：形式及其上下文。
形式是问题的解决方案；上下文定义了问题。第一次通过设计来解决现实问题时，其实是在决定形式上下文边界在哪里，以及可以将其挪动到哪里。

  • 在形式和内容之间画出边界

  • 识别对形式提出要求的作用力

  • 将相关的力量分解成新的形式

  • 将设计过的形式在环境中测试，重新发掘摩擦
    以下图为例，解释下四个步骤。

人们的目的是获得热水，厨房里随处可见的热水壶就是形式，而在厨房中使用明火将水烧开，则是其情境的上下文。在这个环境中，同时还有许多的作用力，比如加热的方式可以是天然气，也可以是电，但在某些地方则是柴火；烧热之后我们要立即使用，所以要求热水壶上面有把手和壶嘴，可以方便地让我们提起来等等。

Alexander 在书中指出，**任何一个边界内，都由一系列事件，重复组成某种模式。**当我们在设计一个形式时，我们应该知道这个世界上实际上有哪些形式和这个相关，以及哪些事件在影响我们要做的事情。

比如在厨房中烧开热水，往往有个几个应用：

  1. 为了保证健康直接烧开饮用或冲泡饮品

  2. 用来让冬天刷碗没那么痛苦

如果我们希望把模式 2 更好地解决，那么未必是设计一个更好地热水壶，而是来看如何满足下面几个约束条件：快速的把水加热到四十度，和水池更近一些，出水量不需要很大但需要持续。

移动问题的边界，就会得到全新的形式。如这种接驳式水龙头就能让冬天刷碗没有那么痛苦，同时也不破坏现有的结构，成功地把相关力量分解成了新的形式，并且适合当下的环境。

简单总结下就是：误用（形式） → 再识别（事件）→ 重新定义（边界） → 新的解决方案（形式）

早期我和 light 聊过想重新设计一款 RSS 阅读器，用来更好地筛选优质信息。但慢慢发现，问题并不是筛选工具不够好，而是根本没有足够的优质内容；而优质内容的缺乏，又是因为激励机制的问题 —— 知识类内容并不适合「免费 + 广告」的模式。

所以我们把边界从「阅读工具」挪到了「激励机制」，最终做成了小报童的付费专栏。

这是一个典型的边界重构过程：

  • 误用（形式）：以为“信息过载问题”可以靠更智能的 RSS 工具解决；

  • 再识别（事件）：实际问题是内容供给侧出了问题；

  • 重新定义（边界）：转向对创作者的激励机制设计，才得到了真正的解法。
    当你重新定义了边界，要解决的问题就完全不同了。

需求是关于世界的事实，而不是属性

许多时候我们会把用户需求抽象为一个属性，如学生怎么用，产品经理怎么用，老人怎么用。但这都是把世界简化为了某些属性，而不是真实发生的事情。

如同下面的锤子，你固然可以抽象出来一个叫做「锤子」的概念，但是却不会在贴瓷砖的时候用铁锤，在钉钉子的时候用软木锤。当然你更想不到砸开核桃的话用诺基亚 720 也可以 —— 从这个角度看它也是锤子。

设计产品的时候，最终都是用形式满足真实的情境，而不是符合「概念」。比如最早在设计 flomo 的导出功能时，为何采用的是 HTML 而不是 MD，PDF，WORD 等格式，原因是，今天任何一台电脑上都有浏览器，但未必都有Office/Adobe/MD 等应用。

而对于大多数老百姓来说，多数人导出数据的真正目的保存下数据以求心安，其次才是希望能联动其他工具。所以导出之后如何最方便的查看，这是真实世界的限制。

但并非是有多少种事实就要设计多少种形式，这会导致产品无比复杂。好的形式不但能解决当前的问题，还能兼容未来的可能性。

再比如 flomo 的「AI 洞察」功能，本质上并不是为某个具体需求设计的功能，而是一个可以被不断组合的“抽象结构”：

任意方式选出一组笔记 × 调用合适的 Prompt = 洞察报告

目前，用户已经可以通过搜索、相关笔记、标签、找一找、浮窗等多种方式筛出一组笔记；而随着场景的变化，我们只需更换 Prompt，就能得到适配不同情境的洞察结果。

换句话说：我们并不需要为每一个具体场景单独设计一个洞察功能，而是设计一个「可以持续演化的结构」。 不是解决一个问题，而是为未来的问题预留了解法的空间。

这也印证了前面的观点：需求清单只是表象，真正决定形式的，是底层事件与可组合的模式结构。

识别模式，组合模式，自下而上地生成

家是模式的集合，比如在我家的厨房中，就有许多模式在其中发生，以洗手池为例。

  • 水池上面是洗手液和清洁剂，以及洗水果的小苏打和食用酒精

  • 水池右侧是用来沥干碗筷的架子

  • 水池左侧往往会用来切菜和防止临时的东西，所以案板在水池附近

  • 厨余垃圾桶紧挨着水池，这样刷碗后的易腐垃圾可以方便地放进去

  • 厨房中在工作台和水池中间，向下倒置方便取用擦拭，也不会浪费台面空间

  • 水池右侧挨着是食器柜，可以方便地取用或者放回

事件组成事件模式（如刷碗，沥干），摆放组成空间模式（如水池位置），如果模式之间和谐，就会形成一曲交响乐，如果不和谐，就会手忙脚乱。

而设计厨房最基础的思路，并不是来安排有多好的燃气灶，有多好的油烟机，也不是去定制一个橱柜就结束了，而是从最小的元素 —— 即发生其中的事件是什么，开始自下而上地设计。整个厨房从搬进来到现在，除了燃气灶和水池的位置，其他已经进行过多轮的迭代和改进。

但我们传统的设计思路是，并不去识别这些模式，而是机械地根据流程来设计：

  • 拿厨房平面图

  • 确定外墙的位置

  • 决定制作计数器多长时间

  • 决定冰箱放在哪里

  • 决定在墙上涂什么颜色

  • 决定在地板上放置哪些瓷砖

对于这种自下而上的设计思路，Alexander 有一段诗意的描写：

一个地方的特征，则是由发生在那里的事件所赋予的。不想象事件发生的场所，就不能想象任何方式的事件；不想象我自己睡在哪，我就不能想象睡眠。不能想象哪里发生了什么，就不可能想到那个地方。不想象床、睡眠，起床 —— 我就不能想象起居室。

同样，在这本书之前，我看待产品设计也是有类似的标准流程；而真正读懂他这段话，会把一切产品都看做是「溪流」 —— 即一系列事件的组合，像溪水一样流淌在每个人生活中的环境。

比如想象一下为何 flomo 不支持微信直接转发文章保存。

  • 当用户随手转发很方便，就会和自己记录的笔记混合在一起；

  • 当收藏的内容变多，就会把这里当仓库而不是笔记本；

  • 当收藏的东西更多而不去看，内心会有焦虑或惭愧，试图更少地打开这个工具；

  • 而当这里存储的大多数内容都不是他创造的，而是别人的东西，他就会倾向于抛弃这里，因为这里几乎没有他的痕迹。

从单点来看，转发收藏很方便，值得做。但从溪流的角度拉长时间来看，这样做最终会导致 flomo 成为死水潭，所以这未必就是一个好选择了。

溪流的视角还能让我们自下而上地来设计产品。比如我们对 flomo 并没有几年的「战略」规划，而是顺着时间和事件思考：当一个人记录很多的时候，他可能会需要回顾；而所有的回顾又分为主动回顾和被动回顾，所以如何把搜索做好，如何挖掘每日回顾背后的逻辑，便是水到渠成的事情。之于这些回顾能给他带来什么价值，就像是下图所示一样，我们在期待和用户的交互过程中识别出来新的可能。

正如一朵花不能制造，却只能从种子中产生一样，你要做的是设计好目的和环境，剩下的交由它自己去发生。

图片 via Ryan Singe

小结

通过在情境中划定范围，来识别其中的上下文；
在范围内识别相关的事件，通过事件识别模式；
将常见的模式组合，生成成新的形式。
这种「模式与情景」匹配的思考方式，对于我们有两种意义：

  1. 通过解决问题过程的明确路径。这样我们就可以逐步使每个问题的中心适应邻近问题的中心，让后将他们编织成一个更大的组合。

  2. **允许我们避免过度设计细节。**因为在开始的时候，往往无法理解所有事件细节，更不能理解这些事件之间的相互作用，规划的过于详细是浪费时间。
    另，我们自身也是由川流不息的事件所塑造的，行胜于言。

推荐阅读