「系统架构」四个字，让UX团队和工程团队互相看了十分钟。不是没听懂，是发现说的根本不是一件事。
一位UX设计师在内部会议上讲解设计系统，台下工程师满脸困惑。会后追问才知道：工程师理解的「系统设计」是分布式架构、数据流、容灾方案；设计师讲的是组件库、视觉规范、交互模式。同一个英文词「system design」，在两个工种的词典里完全是两条平行线。
这篇文章的源头就是这场误会。作者决定把两条线摊开，看看UX领域的「系统级设计」和工程领域的「系统设计」到底差在哪——尤其是在做开发者体验平台这种两边都得伺候的产品时。
工程师的「系统设计」：画图纸之前先造地基
对工程师来说，系统设计是技术蓝图。定义架构、基础设施、数据流向、通信模式，决定软件怎么建、怎么扩、怎么维护。
功能需求只是及格线。真正的考题是非功能需求：性能扛不扛得住峰值，出故障能不能自愈，数据安不安全。这些要是前期没想明白，上线后就是生产事故和凌晨on-call。
好的系统设计能提前拦住昂贵的架构错误。用户量涨十倍的时候，系统能不能平滑扩容？数据库选型、API设计、缓存策略，这些决策越早越清晰，后期技术债越少。新工程师入职，也能靠架构文档快速摸清全貌，而不是在代码库里盲人摸象。
UX的「系统级设计」：让100个页面长得像一个妈生的
设计师嘴里的「设计系统」，是一套让产品视觉和交互保持一致的规则集。按钮圆角多少、错误提示怎么弹、表单校验什么时机触发——全部写成文档、做成组件，供全团队复用。
它的核心价值是效率和质量的双重保险。不用每个页面重新发明按钮，设计师省时间，工程师省代码，用户也不会在A页面和B页面看到两种完全不同的「确认」按钮而怀疑人生。
但当设计师在会议上说「system design」时，工程师脑子里浮现的是微服务拆分和数据库分片。这种术语撞车，在跨职能协作里制造了真实的沟通成本。
开发者体验平台：被迫当翻译的第三战场
作者专门提到自己正在做开发者体验平台（Developer Experience Platform）。这类产品的特殊之处在于：它的用户是开发者，但它的设计者需要同时理解两种「系统」语言。
平台要提供CLI工具、SDK、文档——这些是工程师视角的系统设计要支撑的。但工具怎么命名、错误信息怎么写、文档结构怎么组织，又是UX系统级设计的管辖范围。
一个API文档页面，工程师可能只关心请求参数和响应码；但设计师会追问：这个错误示例能不能一眼看懂？状态码表格和实际代码片段的间距会不会让人视觉疲劳？搜索框放在右上角还是左侧导航更顺手？
两边都对，但优先级打架。开发者体验平台的产品经理，本质上是在做双语同传。
术语撞车的真实代价
回到文章开头那场会议。作者的反思很直接：如果术语本身就会造成认知偏差，那协作流程里必须提前对齐词典。
这不是小题大做。在大型组织里，「系统设计」四个字可能同时出现在技术评审会和设计走查会，参会人员重叠，理解却分叉。一个小时的会，前二十分钟花在确认「你说的到底是哪个系统」。
更隐蔽的代价是决策延迟。当工程师以为设计师在讲高可用架构，设计师以为工程师在聊组件复用，双方都在等对方给出「真正重要」的输入，结果谁也没拿到自己想要的。
怎么解：给同一个词加前缀
作者的解法很朴素——在内部明确区分「technical system design」（技术系统设计）和「UX system-level design」（UX系统级设计）。不是创造新词，是给旧词加限定符。
这个策略的妙处在于不挑战既有习惯。工程师和设计师各自领域的「系统设计」都是成熟概念，强行统一反而制造混乱。加前缀相当于在会议室门口挂两块牌子，进门之前先看清楚要去哪个房间。
对于开发者体验平台这类跨界产品，这种区分更关键。因为平台的设计者需要同时用两种语言思考，而平台的用户（开发者）又会对两种「系统」都有接触。术语不清，产品文档、API参考、教程视频全会变成鸡同鸭讲。
文章没给数据，但埋了一个值得量化的观察：当团队规模超过某个阈值，术语歧义造成的会议损耗和返工成本会指数级上升。作者没说这个阈值是多少，但暗示了它真实存在——尤其是在设计系统和工程架构都需要频繁迭代的场景里。
热门跟贴