设计你的环境：一个地方或产品的特征，是由发生在那里的事件所赋予的

作者 | shaonan

来源|产品沉思录 ProductThinking

本文也受到 Basecamp 产品管理专家 Ryan Singer 的演讲《Designing with Forces：How to Applied Christopher Alexander in Everyday Work》的启发：

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

1、在形式和内容之间画出边界 2、识别对形式提出要求的作用力 3、将相关的力量分解成新的形式 4、将设计过的形式在环境中测试，重新发掘摩擦

◎以上图为例，解释下四个步骤

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

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

1、为了保证健康直接烧开饮用或冲泡饮品 2、用来让冬天刷碗没那么痛苦

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

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

同样，最早和 light 聊过有机会想重新设计一款 RSS 阅读器，用来更好地挖掘优质信息。但仔细思考后发现，现在并不是缺乏信息，而是缺乏优质信息；不是过滤器不够强大，而是缺少优质的内容供给；而没有优质供给的背后，是激励机制的问题 —— 毕竟知识类的内容不适合免费阅读 + 广告这种模式。

所以 RSS 阅读器只是形式，而我们目的是为了获取优质信息，环境因素是优质供给少。所以我们挪动了问题的边界，把信息聚合筛选问题，变成了激励机制模式设计的问题，得到了完全不一样的答案 —— 即小报童的付费专栏[1]。

当你重新定义了边界，要解决的问题就完全不同了。

需求是关于世界的事实，

而不是属性

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

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

设计产品的时候，最终都是用形式满足真实的情境，而不是符合「概念」。比如最早在设计 flomo 的导出功能时，为何采用的是 HTML 而不是 MD，PDF，WORD 等格式，原因是，今天任何一台电脑上都有浏览器，但未必都有Office/Adobe/MD 等应用。而对于大多数老百姓来说，多数人导出数据的真正目的保存下数据以求心安，其次才是希望能联动其他工具。所以导出之后如何最方便的查看，这是真实世界的限制。

同样在丁香医生上有个提问成功页面，有一个其他医生推荐列表，方便用户焦虑可以再问一个医生。但这显然并未真正的理解现实世界的样子，后续发现，对于儿科来说，母亲提问完之后，在等待医生回复的过程中依旧是焦虑的，而他们往往第一个会问比较贵（但多数回复会比较慢），这时候再推荐一组响应速度快的医生，就能很好地缓解这种焦虑情绪；而对于皮肤科来说，来问诊的都是年轻人，对价格比较敏感，排序要素就要以价格优先 —— 都是再问一个医生的需求，但是事实并不一样。

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

比如 Notion 的 Blocks 设计，从一句话到一个网页，再到一个视频，或者各种第三方工具，都可以被抽象为一个 Block，未来对接任何新的具体需求，都可以用这套形式来解决。

而为何 flomo 的回顾不做成艾宾浩斯曲线式那样，可以对每个 MEMO 进行再次提醒设置。是因为这会让每个 MEMO 都多一个额外的要素叫做回顾周期，且这个要素仅能在这一个情境下使用，对未来没有兼容性。如果按照这个思路来改进产品，用不了多久就会变成复杂的缝合怪。

仅仅有需求清单是不够的，因为往往是模糊和抽象的，需要考虑到底是什么元素在影响我们做决策。

识别模式，组合模式，

自下而上地生成

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

水池上面是洗手液和清洁剂，以及洗水果的小苏打和食用酒精；水池右侧是用来沥干碗筷的架子；水池左侧往往会用来切菜和防止临时的东西，所以案板在水池附近；厨余垃圾桶紧挨着水池，这样刷碗后的易腐垃圾可以方便地放进去；厨房中在工作台和水池中间，向下倒置方便取用擦拭，也不会浪费台面空间；水池右侧挨着是食器柜，可以方便地取用或者放回。

事件组成事件模式（如刷碗，沥干），摆放组成空间模式（如水池位置），如果模式之间和谐，就会形成一曲交响乐，如果不和谐，就会手忙脚乱。而设计厨房最基础的思路，并不是来安排有多好的燃气灶，有多好的油烟机，也不是去定制一个橱柜就结束了，而是从最小的元素 —— 即发生其中的事件是什么，开始自下而上地设计。整个厨房从搬进来到现在，除了燃气灶和水池的位置，其他已经进行过多轮的迭代和改进。

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

1.拿厨房平面图2.确定外墙的位置3.决定制作计数器多长时间4.决定冰箱放在哪里5.决定在墙上涂什么颜色6.决定在地板上放置哪些瓷砖

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

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

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

比如想象一下为何 flomo 不支持微信直接转发文章保存。当用户随手转发很方便，就会和自己记录的笔记混合在一起；当收藏的内容变多，就会把这里当仓库而不是笔记本；当收藏的东西更多而不去看，内心会有焦虑或惭愧，试图更少地打开这个工具；而当这里存储的大多数内容都不是他创造的，而是别人的东西，他就会倾向于抛弃这里，因为这里几乎没有他的痕迹。（当然我也承认，在这条原则上，还是有过动摇的）

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

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

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