「系統(tǒng)架構(gòu)」四個字,讓UX團隊和工程團隊互相看了十分鐘。不是沒聽懂,是發(fā)現(xiàn)說的根本不是一件事。
一位UX設(shè)計師在內(nèi)部會議上講解設(shè)計系統(tǒng),臺下工程師滿臉困惑。會后追問才知道:工程師理解的「系統(tǒng)設(shè)計」是分布式架構(gòu)、數(shù)據(jù)流、容災(zāi)方案;設(shè)計師講的是組件庫、視覺規(guī)范、交互模式。同一個英文詞「system design」,在兩個工種的詞典里完全是兩條平行線。
![]()
這篇文章的源頭就是這場誤會。作者決定把兩條線攤開,看看UX領(lǐng)域的「系統(tǒng)級設(shè)計」和工程領(lǐng)域的「系統(tǒng)設(shè)計」到底差在哪——尤其是在做開發(fā)者體驗平臺這種兩邊都得伺候的產(chǎn)品時。
工程師的「系統(tǒng)設(shè)計」:畫圖紙之前先造地基
對工程師來說,系統(tǒng)設(shè)計是技術(shù)藍圖。定義架構(gòu)、基礎(chǔ)設(shè)施、數(shù)據(jù)流向、通信模式,決定軟件怎么建、怎么擴、怎么維護。
功能需求只是及格線。真正的考題是非功能需求:性能扛不扛得住峰值,出故障能不能自愈,數(shù)據(jù)安不安全。這些要是前期沒想明白,上線后就是生產(chǎn)事故和凌晨on-call。
好的系統(tǒng)設(shè)計能提前攔住昂貴的架構(gòu)錯誤。用戶量漲十倍的時候,系統(tǒng)能不能平滑擴容?數(shù)據(jù)庫選型、API設(shè)計、緩存策略,這些決策越早越清晰,后期技術(shù)債越少。新工程師入職,也能靠架構(gòu)文檔快速摸清全貌,而不是在代碼庫里盲人摸象。
UX的「系統(tǒng)級設(shè)計」:讓100個頁面長得像一個媽生的
設(shè)計師嘴里的「設(shè)計系統(tǒng)」,是一套讓產(chǎn)品視覺和交互保持一致的規(guī)則集。按鈕圓角多少、錯誤提示怎么彈、表單校驗什么時機觸發(fā)——全部寫成文檔、做成組件,供全團隊復(fù)用。
它的核心價值是效率和質(zhì)量的雙重保險。不用每個頁面重新發(fā)明按鈕,設(shè)計師省時間,工程師省代碼,用戶也不會在A頁面和B頁面看到兩種完全不同的「確認」按鈕而懷疑人生。
但當(dāng)設(shè)計師在會議上說「system design」時,工程師腦子里浮現(xiàn)的是微服務(wù)拆分和數(shù)據(jù)庫分片。這種術(shù)語撞車,在跨職能協(xié)作里制造了真實的溝通成本。
開發(fā)者體驗平臺:被迫當(dāng)翻譯的第三戰(zhàn)場
作者專門提到自己正在做開發(fā)者體驗平臺(Developer Experience Platform)。這類產(chǎn)品的特殊之處在于:它的用戶是開發(fā)者,但它的設(shè)計者需要同時理解兩種「系統(tǒng)」語言。
平臺要提供CLI工具、SDK、文檔——這些是工程師視角的系統(tǒng)設(shè)計要支撐的。但工具怎么命名、錯誤信息怎么寫、文檔結(jié)構(gòu)怎么組織,又是UX系統(tǒng)級設(shè)計的管轄范圍。
一個API文檔頁面,工程師可能只關(guān)心請求參數(shù)和響應(yīng)碼;但設(shè)計師會追問:這個錯誤示例能不能一眼看懂?狀態(tài)碼表格和實際代碼片段的間距會不會讓人視覺疲勞?搜索框放在右上角還是左側(cè)導(dǎo)航更順手?
兩邊都對,但優(yōu)先級打架。開發(fā)者體驗平臺的產(chǎn)品經(jīng)理,本質(zhì)上是在做雙語同傳。
術(shù)語撞車的真實代價
回到文章開頭那場會議。作者的反思很直接:如果術(shù)語本身就會造成認知偏差,那協(xié)作流程里必須提前對齊詞典。
這不是小題大做。在大型組織里,「系統(tǒng)設(shè)計」四個字可能同時出現(xiàn)在技術(shù)評審會和設(shè)計走查會,參會人員重疊,理解卻分叉。一個小時的會,前二十分鐘花在確認「你說的到底是哪個系統(tǒng)」。
更隱蔽的代價是決策延遲。當(dāng)工程師以為設(shè)計師在講高可用架構(gòu),設(shè)計師以為工程師在聊組件復(fù)用,雙方都在等對方給出「真正重要」的輸入,結(jié)果誰也沒拿到自己想要的。
怎么解:給同一個詞加前綴
作者的解法很樸素——在內(nèi)部明確區(qū)分「technical system design」(技術(shù)系統(tǒng)設(shè)計)和「UX system-level design」(UX系統(tǒng)級設(shè)計)。不是創(chuàng)造新詞,是給舊詞加限定符。
這個策略的妙處在于不挑戰(zhàn)既有習(xí)慣。工程師和設(shè)計師各自領(lǐng)域的「系統(tǒng)設(shè)計」都是成熟概念,強行統(tǒng)一反而制造混亂。加前綴相當(dāng)于在會議室門口掛兩塊牌子,進門之前先看清楚要去哪個房間。
對于開發(fā)者體驗平臺這類跨界產(chǎn)品,這種區(qū)分更關(guān)鍵。因為平臺的設(shè)計者需要同時用兩種語言思考,而平臺的用戶(開發(fā)者)又會對兩種「系統(tǒng)」都有接觸。術(shù)語不清,產(chǎn)品文檔、API參考、教程視頻全會變成雞同鴨講。
文章沒給數(shù)據(jù),但埋了一個值得量化的觀察:當(dāng)團隊規(guī)模超過某個閾值,術(shù)語歧義造成的會議損耗和返工成本會指數(shù)級上升。作者沒說這個閾值是多少,但暗示了它真實存在——尤其是在設(shè)計系統(tǒng)和工程架構(gòu)都需要頻繁迭代的場景里。
特別聲明:以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布,本平臺僅提供信息存儲服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.