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),有多少組件是"理論上存在"而"實際上沒人用"的?
特別聲明:以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布,本平臺僅提供信息存儲服務。
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.