同一個詞，工程師和設計師吵了半小時

「系統架構」四個字，讓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參考、教程視頻全會變成雞同鴨講。

文章沒給數據，但埋了一個值得量化的觀察：當團隊規模超過某個閾值，術語歧義造成的會議損耗和返工成本會指數級上升。作者沒說這個閾值是多少，但暗示了它真實存在——尤其是在設計系統和工程架構都需要頻繁迭代的場景里。