过去一年我做的最重要的一个设计决定，不是在任何”设计阶段”里做出来的。
它是在一个周四的早上做出来的 —— 某个产品上线三个月之后。值班工程师随口提了一句，我们的客服邮箱里反复收到同样的一段字：“我怎么关掉……”。几乎每一次，用户都在试图关掉一个我们怀着好意、认真设计过的通知模式。界面上提供了两条把它安静下来的路径；两条都不是用户在找它的地方。我们做了一个设置。我们写了文档。我们甚至在上线前的研究里测试过它的可被发现性。但在”人们会到哪里去找这个开关”这件事上，我们错了 —— 错得明显，错在规模上。
那个周四的早上，以一种安静的方式，正是这篇文章想谈的东西。真正重要的设计 —— 人们真正在用的设计 —— 几乎从来不是上线那天发布出去的那个设计。它是上线四周后、八周后、十二周后存在的那个设计 —— 每一个那样的周里，它都吸收了一点上线前流程永远无法产生的真实证据。
在我所受训的那个行业里，这件事很少被当成”设计问题”来处理。它被当成”产品路线图问题”、“增长问题”、“客服工单问题”。等到设计师离开之后，它就变成剩下来的人手里能用的那些词汇下的某个问题。
我觉得这是一个错误。我也觉得 —— 把产品设计当成一种持续节奏，而不是一个离散的交付阶段 —— 会真正改变设计这件事本身是为了什么。
被继承下来的模型，以及它安静的代价
如果你是在咨询或广告代理那套传统里成长起来的，你熟悉那个形状：discovery → 概念 → 线框 → 高保真 → 交接 → 上线。每一步都有 deliverable，每一步都要签字确认。这里面隐含一个声明 —— 当”交接”发生的时候，设计已经完成了。
我不认识任何一个设计师真的相信这件事能在 v1 时发生。我们每个人上线的时候都带着一份”我打算之后回来处理”的妥协清单。但在这个行业的默认形状里，几乎从来不会真的回来。项目结束了。设计 deliverable 最终版本交付了。另外一个人 —— 通常是一个没参与过原本任何决定的人 —— 同时继承了这份完成的设计，和那张跟着它一起交过来的安静妥协清单。
结果就是 —— 我私下把它叫做设计版的技术债。不是没做完的功能，不是缺失的状态，而是累积的摩擦 —— 堆在原设计团队知道脆弱、而接手团队没有理由察觉到脆弱的那些位置上。原设计师手里有上下文。他们走了。上下文跟着走了。
这件事最明显地会在三个地方冒出来 —— 我列出来，是因为我发现把它们当成观察信号很有用：
- **表单会慢慢偏离规范。**一张上线时有特定校验节奏的表单，会悄悄变成十八张类似的表单 —— 其中十二张是某个不知道原版哪些细节承重的人照着抄的。
- **空状态会变老。**给产品前三周写的那句文案（“还没有内容 —— 邀请队友后再来看看”），六个月之后还在那里 —— 但那个状态那时已经是另一种意思了。
- **设置项会沉积。**每个新功能都加一个设置。没人删设置。一年之后，设置页变成一层层的考古地层，而 v1 时看起来干净的信息架构，已经不再匹配人们实际想做的事。
这三件事，严格来说，都不算”坏了”。这三件事一起，都是在安静地失效。
把设计变成一种运营节奏，意味着什么
我想描述的替代方案，不是”设计师终身 on-call”。而是 —— 这个设计系统 —— 里面的决定、推理、权衡 —— 会随着真实证据到来，带着意图，继续被编辑。作为一项运营活动来编辑，有特定节奏、有特定负责人、对准特定信号。
在我们的工作里，这件事有一个具体的形状：
1. 设计评审不是在上线那天结束 —— 它换节奏
上线前，我们按项目的自然节奏做设计评审 —— 一般是每周。上线后，至少在前 12 周里，我们切换到双周运营评审。它更短、更紧、输入是不一样的：不是”这里是新页面”，而是”这两周产品做了哪些我们都没预料到的事”。
输入的格式刻意做得很朴素 —— 一份简短的文档，三列：数据里发生了什么变化、客服那边听到了什么、接下来两周我们打算重新设计、压低、移除、或澄清哪些东西。没有 hero 稿。没有 design thinking 的表演。这里不是发明新产品的地方；这里是把已经上线的产品修对的地方。
2. 设计改动按运营节奏上线，而不是按项目节奏
在默认模型里，“上线后的一个设计改动”会触发一个小项目 —— 写一份 spec，排上路线图，分配时间，做出来。那个节奏跟不上信号。
我们的做法是：v1 之后，维持一个预批准的小设计改动预算 —— 通常每双周 5 到 15 个 —— 这些可以不经过新合约就上线。文案订正、表单微调、空状态更新、设置层级调整、错误路径里的 microcopy。每一个花一两个小时。在 12 周里累积起来，它们对产品可用性带来的改变，比我参与过任何一次上线后大改版都大。
3. 设计系统被当成有负责人的活文档
一个在上线那天被冻结的设计系统，一年之内就会变成考古项目。我们每一个设计系统都配一份运营规范 —— 谁拥有它、什么情况会触发改动、改动如何被记录、旧决定如何被退役。
实际效果：上线一年后，设计系统匹配的是产品当前实际的样子，而不是最初提案时的样子。新加入的参与者 —— 内部或外部 —— 仍然能用它，而不用先去考古一个特定决定为什么长成这样。
在两个案例里它长什么样
一家博物馆硬件合作方 —— 上线后的设计改动，才是重要的那一个
我们有一档硬件合作，是一台向博物馆投放的讲解设备，配着一个手机 App。这里不提合作方的名字，只说学到的东西 —— 经验是通用的，细节是他们的。
这台设备上线的时候配了一个手机 App，v1 时它的主要工作是设备配对和内容播放控制。我们认认真真为”单个访客在用一台设备”那个场景做了设计 —— 这是上线前调研里的默认场景。
博物馆现场工作人员不是那样用的。他们会成组使用，二十台一起，速度很快，而且经常面对一组在同一个房间里说两三种语言的访客。App 默认视图稳稳地定在”正在给当前访客播放内容”上，而对现场人员的使用场景来说，这是错的默认。他们需要一个*“设备组状态”*视图 —— 上线设计里不存在的那种视图。
如果我们是按传统合作模式走的，这会变成一个 Phase 2 项目 —— 写 spec、估时、议价、排期、下个季度交付。但因为我们走的是运营节奏评审 —— 第三周的双周评审把这个模式浮了上来，设计团队周五在共享画板上画了三个选项，一个新的顶层视图周三就上线了。它不是最终正确的设计；它是一个刻意克制的版本 —— 吸收信号、留下继续迭代的空间。“正确”的设计在三个节奏周期之后才长出来 —— 建立在数据之上，而不是在会议之上。
mymemo —— 真正难的工作是减法，不是加法
我们另一款产品合作方 mymemo 在上线时带着比事后看来所需的更丰富的功能集。这是在 2025 年做一款消费级 AI 产品的可预期结果：加一个能力成本很低，而每一个能力都带来一个新的控制面。到第二个月结束时，App 已经飘到这么一种状态 —— 让它独特的那些东西，比一些通用的东西更难被找到。
在运营节奏评审里，我们做的动作几乎全是减法。一个技术上能用的功能被藏到了 disclosure 下面。一个对 0.8% 会话重要的设置失去了它的顶层位置。一个我们在上线前因为有意思而喜欢的导航项，输给了一个事后证明真的被用的导航项。
这种编辑工作在传统交付模型里是别扭的。在一个已关闭的合约里做减法，感觉像承认错误；在一个运营节奏里做减法，感觉像在做本职工作。这个框架的变化，比听起来更重要。
它到底改变了什么
给正在想”设计合作方在我的组织里该放在哪”的客户：我想提供的框架是 —— 上线前发生的设计工作，比上线后发生的设计工作要小。一个到交接那天就结束的合作，完成的最多只是三分之一的工作。产品越有野心，这个比例越明显。
给正在想”我自己做的工作放在哪”的设计师：我想提供的框架是 —— 事后证明真正重要的决定，几乎都是在真实证据到手的时候做的。一种让你总是在真实证据到达的那一刻就退出每一个产品的职业形状，是一种被优化成”产出一些你永远学不到东西的作品”的职业形状。我发现反过来 —— 上线之后也留下来，以运营节奏持续介入 —— 是唯一可靠的，让一个人在这份工作上真的变好的方式。
上线的那个设计是一个假设。之后那段节奏，是它变成一个产品的方式。