「系統(tǒng)架構(gòu)」四個(gè)字，讓UX團(tuán)隊(duì)和工程團(tuán)隊(duì)互相看了十分鐘。不是沒聽懂，是發(fā)現(xiàn)說的根本不是一件事。

一位UX設(shè)計(jì)師在內(nèi)部會(huì)議上講解設(shè)計(jì)系統(tǒng)，臺(tái)下工程師滿臉困惑。會(huì)后追問才知道：工程師理解的「系統(tǒng)設(shè)計(jì)」是分布式架構(gòu)、數(shù)據(jù)流、容災(zāi)方案；設(shè)計(jì)師講的是組件庫、視覺規(guī)范、交互模式。同一個(gè)英文詞「system design」，在兩個(gè)工種的詞典里完全是兩條平行線。

這篇文章的源頭就是這場誤會(huì)。作者決定把兩條線攤開，看看UX領(lǐng)域的「系統(tǒng)級(jí)設(shè)計(jì)」和工程領(lǐng)域的「系統(tǒng)設(shè)計(jì)」到底差在哪——尤其是在做開發(fā)者體驗(yàn)平臺(tái)這種兩邊都得伺候的產(chǎn)品時(shí)。

工程師的「系統(tǒng)設(shè)計(jì)」：畫圖紙之前先造地基

對(duì)工程師來說，系統(tǒng)設(shè)計(jì)是技術(shù)藍(lán)圖。定義架構(gòu)、基礎(chǔ)設(shè)施、數(shù)據(jù)流向、通信模式，決定軟件怎么建、怎么擴(kuò)、怎么維護(hù)。

功能需求只是及格線。真正的考題是非功能需求：性能扛不扛得住峰值，出故障能不能自愈，數(shù)據(jù)安不安全。這些要是前期沒想明白，上線后就是生產(chǎn)事故和凌晨on-call。

好的系統(tǒng)設(shè)計(jì)能提前攔住昂貴的架構(gòu)錯(cuò)誤。用戶量漲十倍的時(shí)候，系統(tǒng)能不能平滑擴(kuò)容？數(shù)據(jù)庫選型、API設(shè)計(jì)、緩存策略，這些決策越早越清晰，后期技術(shù)債越少。新工程師入職，也能靠架構(gòu)文檔快速摸清全貌，而不是在代碼庫里盲人摸象。

UX的「系統(tǒng)級(jí)設(shè)計(jì)」：讓100個(gè)頁面長得像一個(gè)媽生的

設(shè)計(jì)師嘴里的「設(shè)計(jì)系統(tǒng)」，是一套讓產(chǎn)品視覺和交互保持一致的規(guī)則集。按鈕圓角多少、錯(cuò)誤提示怎么彈、表單校驗(yàn)什么時(shí)機(jī)觸發(fā)——全部寫成文檔、做成組件，供全團(tuán)隊(duì)復(fù)用。

它的核心價(jià)值是效率和質(zhì)量的雙重保險(xiǎn)。不用每個(gè)頁面重新發(fā)明按鈕，設(shè)計(jì)師省時(shí)間，工程師省代碼，用戶也不會(huì)在A頁面和B頁面看到兩種完全不同的「確認(rèn)」按鈕而懷疑人生。

但當(dāng)設(shè)計(jì)師在會(huì)議上說「system design」時(shí)，工程師腦子里浮現(xiàn)的是微服務(wù)拆分和數(shù)據(jù)庫分片。這種術(shù)語撞車，在跨職能協(xié)作里制造了真實(shí)的溝通成本。

開發(fā)者體驗(yàn)平臺(tái)：被迫當(dāng)翻譯的第三戰(zhàn)場

作者專門提到自己正在做開發(fā)者體驗(yàn)平臺(tái)（Developer Experience Platform）。這類產(chǎn)品的特殊之處在于：它的用戶是開發(fā)者，但它的設(shè)計(jì)者需要同時(shí)理解兩種「系統(tǒng)」語言。

平臺(tái)要提供CLI工具、SDK、文檔——這些是工程師視角的系統(tǒng)設(shè)計(jì)要支撐的。但工具怎么命名、錯(cuò)誤信息怎么寫、文檔結(jié)構(gòu)怎么組織，又是UX系統(tǒng)級(jí)設(shè)計(jì)的管轄范圍。

一個(gè)API文檔頁面，工程師可能只關(guān)心請(qǐng)求參數(shù)和響應(yīng)碼；但設(shè)計(jì)師會(huì)追問：這個(gè)錯(cuò)誤示例能不能一眼看懂？狀態(tài)碼表格和實(shí)際代碼片段的間距會(huì)不會(huì)讓人視覺疲勞？搜索框放在右上角還是左側(cè)導(dǎo)航更順手？

兩邊都對(duì)，但優(yōu)先級(jí)打架。開發(fā)者體驗(yàn)平臺(tái)的產(chǎn)品經(jīng)理，本質(zhì)上是在做雙語同傳。

術(shù)語撞車的真實(shí)代價(jià)

回到文章開頭那場會(huì)議。作者的反思很直接：如果術(shù)語本身就會(huì)造成認(rèn)知偏差，那協(xié)作流程里必須提前對(duì)齊詞典。

這不是小題大做。在大型組織里，「系統(tǒng)設(shè)計(jì)」四個(gè)字可能同時(shí)出現(xiàn)在技術(shù)評(píng)審會(huì)和設(shè)計(jì)走查會(huì)，參會(huì)人員重疊，理解卻分叉。一個(gè)小時(shí)的會(huì)，前二十分鐘花在確認(rèn)「你說的到底是哪個(gè)系統(tǒng)」。

更隱蔽的代價(jià)是決策延遲。當(dāng)工程師以為設(shè)計(jì)師在講高可用架構(gòu)，設(shè)計(jì)師以為工程師在聊組件復(fù)用，雙方都在等對(duì)方給出「真正重要」的輸入，結(jié)果誰也沒拿到自己想要的。

怎么解：給同一個(gè)詞加前綴

作者的解法很樸素——在內(nèi)部明確區(qū)分「technical system design」（技術(shù)系統(tǒng)設(shè)計(jì)）和「UX system-level design」（UX系統(tǒng)級(jí)設(shè)計(jì)）。不是創(chuàng)造新詞，是給舊詞加限定符。

這個(gè)策略的妙處在于不挑戰(zhàn)既有習(xí)慣。工程師和設(shè)計(jì)師各自領(lǐng)域的「系統(tǒng)設(shè)計(jì)」都是成熟概念，強(qiáng)行統(tǒng)一反而制造混亂。加前綴相當(dāng)于在會(huì)議室門口掛兩塊牌子，進(jìn)門之前先看清楚要去哪個(gè)房間。

對(duì)于開發(fā)者體驗(yàn)平臺(tái)這類跨界產(chǎn)品，這種區(qū)分更關(guān)鍵。因?yàn)槠脚_(tái)的設(shè)計(jì)者需要同時(shí)用兩種語言思考，而平臺(tái)的用戶（開發(fā)者）又會(huì)對(duì)兩種「系統(tǒng)」都有接觸。術(shù)語不清，產(chǎn)品文檔、API參考、教程視頻全會(huì)變成雞同鴨講。

文章沒給數(shù)據(jù)，但埋了一個(gè)值得量化的觀察：當(dāng)團(tuán)隊(duì)規(guī)模超過某個(gè)閾值，術(shù)語歧義造成的會(huì)議損耗和返工成本會(huì)指數(shù)級(jí)上升。作者沒說這個(gè)閾值是多少，但暗示了它真實(shí)存在——尤其是在設(shè)計(jì)系統(tǒng)和工程架構(gòu)都需要頻繁迭代的場景里。