2021年中，我的Figma庫里已經(jīng)塞滿了47種組件變體。數(shù)據(jù)表格、金融圖表、投資人卡片布局——該有的都有了。文檔寫得詳盡，每個padding值背后都有設計理由。

上個月，我對照生產(chǎn)環(huán)境的真實界面，發(fā)現(xiàn)按鈕圓角對不上，表單標簽的灰色偏差了幾個色階，該16px的間距成了14px。沒有哪處是災難性的，但湊在一起，產(chǎn)品就是不夠"整"。

系統(tǒng)很完整，交付很零散。兩件事同時成立。

從0到1的興奮，掩蓋不了從1到100的失速

2019年底加入VALK時，這里連設計團隊都沒有。從零開始聽起來很爽——不用繼承別人的爛攤子，每個決策都是自己的。

2020年中，組件庫跑起來了。年底，文檔補全。2021年中，覆蓋幾乎所有UI模式。我當時確實挺得意。

但代碼和組件的分裂是靜悄悄的。沒有某個崩潰的早晨，只有無數(shù)個"差不多就行"的下午。前端工程師沒讀文檔，不是因為他懶，是因為文檔在Figma里，而他寫代碼時在編輯器、在代碼庫、在看已經(jīng)存在的組件。那是他的參考系，不是我的。

我后來意識到一個尷尬的事實：設計系統(tǒng)在我手里是系統(tǒng)，在他手里是建議。

文檔的悖論：寫得越細，越?jīng)]人看

我在Krasnaya Polyana的山間小屋里寫這篇文章。租來的房子很安靜，適合想事情。本來說是來清空腦袋的，結果每天打開Figma，盯著那個gap發(fā)呆——系統(tǒng)說該這樣，上線的是那樣。

我花了真功夫?qū)懳臋n。不是羅列參數(shù)，是解釋為什么主按鈕用那個padding，為什么選這個藍而不是旁邊那個看起來差不多的。設計決策的上下文。

但文檔的讀者只有我自己。前端工程師沒讀過大部分，這不是批評，是觀察。他干活快，質(zhì)量也不錯，只是他的工作流里沒有"打開Figma讀設計文檔"這個環(huán)節(jié)。代碼庫里已有的組件，才是他復制粘貼的起點。

我試過把規(guī)范同步到代碼側(cè)，但我是唯一的設計師，沒有專門的DesignOps人手。每次迭代，F(xiàn)igma更新在先，代碼追趕在后，縫隙就這么產(chǎn)生了。

單人團隊的結構性困境

很多設計系統(tǒng)的文章假設你有團隊。專人維護文檔，專人做DesignOps，專人跟前端對齊token。我讀到這些時會覺得，嗯，道理都對，但我的現(xiàn)實是：一個人畫界面，一個人寫規(guī)范，一個人追落地。

這不是抱怨，是復盤的前提。小團隊做設計系統(tǒng)，得接受某些"最佳實踐"根本夠不著。我的策略后來變了：不再追求Figma和代碼的像素級同步，而是抓最關鍵的變量——顏色、字體、間距階梯。其他的，允許一定漂移。

這個妥協(xié)讓我不舒服，但比假裝系統(tǒng)完美運行要誠實。

回頭看那兩個按鈕圓角的差異，14px和16px，用戶根本不會注意到。我注意到，是因為我建了那個系統(tǒng)。這種敏感度是設計師的職業(yè)病，也是負擔。

你現(xiàn)在維護的設計系統(tǒng)，有多少組件是"理論上存在"而"實際上沒人用"的？