關於設計系統「基礎」的愚蠢

Home 程式開發 關於設計系統「基礎」的愚蠢
關於設計系統「基礎」的愚蠢
程式開發

“基礎”的概念,是建立人們使用的設計系統的最大威脅之一。

在建立像建築物這樣的物理結構時,地基非常重要,原因有很多。 最重要的是,用老房子的話來說,地基「應該永遠長存」。

在製作數位產品時,它不那麼重要了。

事實上,有一個很好的論點是,存在許多軟體開發實踐來解耦盡可能多的“永久”部分的依賴。 版本控制系統中的合併功能允許我們隨時編輯、刪除或擴充產品的任何部分,而不會損壞代碼庫的其餘部分。 刪除任何給定軟體中編寫的第一行代碼只需要一個 pull request 即可。 數位產品是我們現代的忒修斯之船。

重要的事先說

我不完全確定建立一個好的數位產品的第一步是從建立顏色和排版等“基礎”開始的想法來自哪裡。也許這是瀑布方法的遺物,這意味著建立數位產品是一系列相互依賴的依賴關係。

將數位產品中的任何事物都視為“基礎”的危險在於,它意味著您必須首先關注這個事物,其他一切都需要建立在這個支撐結構上。

不管是什麼原因,我們對潛在客戶和客戶的樣本量表明這是一個合理的先入為主的概念。當我們在 90 天工作簿中啟動設計系統時,我們遇到的最常見問題之一是缺乏關於建立顏色、排版和間距指南的內容,大多數人稱之為“基礎”。它不在工作簿中的主要原因是因為我們認為在前 90 天內至少有 52 件更重要的事情需要關注。

我們與許多潛在客戶的對話是類似底下:

我們正在磨練我們最初的設計語言和我們的一些基本原件,但我們還沒有太多進度。已經有開始一段時間了,但我們似乎永遠無法取得我們想要取得的進展。我們正在為我們的設計團隊計劃一個外部空間,以完成基礎。一旦我們完成了這些,你能幫助我們建立後面的工作與管理模型嗎?

以我的經驗,這種“如果你建造它,他們就會來”的心態是最終成為設計系統墓地的最大貢獻者。

在最簡單的情況下,它是不準確和不切實際的。人類不擅長準確的預測。您是否曾嘗試通過首先選擇調色板和字體然後建立畫面來設計畫面?不可避免地,一旦您將這些選擇實際應用於特定上下文,您就必須更改它。它改變了它作為“基礎”的資格。 (下面有更多關於這個想法的訊息。)

如果不在“基礎”上工作,那麼第一步應該是什麼?頻譜的兩端表明了不同的起點:

  1. 您正在一個擁有許多現有網站和應用程式的大型企業組織中建立一個設計系統
  2. 您正在一家尚未建立第一個網站或應用程式的新公司或新創公司建立設計系統

對於擁有許多現有數位產品的組織

首先確定當前網站和應用程式中現有的有用模式。 品牌團隊或產品團隊已經選擇品牌字體的可能性非常高,這應該是這樣的。 建立品牌標準是品牌團隊的工作。 幫助使這些標準在用戶介面中易於實施是設計系統團隊的工作。 設計系統是用於建立需要與其他組織系統協同工作的介面的系統。

對於新公司或新創公司

首先為新公司建立設計系統是過早的優化。

當然,你需要一個字體和一個調色板來建立你的第一個 MVP。 不過選得快。 花 30 分鐘做出這個決定,而不是 30 天。

我給你挑。 從 Adobe Color 中選擇一個調色板。 使用 Helvetica。 不喜歡 Helvetica? 使用國際米蘭。 不喜歡國際米蘭? 使用機器人。 不喜歡機器人? 你已經在這個決定上花費了比對你的創業有價值的時間更多的時間。 在這一點上,任何不花在追求產品市場匹配上的時間都可能是浪費時間。

波動性,然後是穩定性

在過去的十年裡,我還沒有找到比 Michael Lopp 的 “Stables and Volatiles” 更好地描述產品建立的敘述文章:

成功的 1.0 之誕生是一場與慣例和常識的戰爭。 它是圍繞少數幾個相信“我們可以將這個新事物帶入世界”的 Volatile 建立起來的,但沒有人相信他們。

這也是我在設計系統方面的經歷。 如果沒有一兩個 Volatile 願意通過非常規的決策和蠻力將其存在,就幾乎不可能發佈設計系統的第一個版本。

以“基礎”開始設計系統是合乎邏輯和合理的。 感覺像是常識。 然而它很少成功,或者找到受眾被採用。

風格指南與設計系統

我發現那些高估設計系統中“基礎”重要性的人與那些真正試圖建立風格指南而不是設計系統的人之間存在高度相關性(即使他們沒有意識到這一點或差異)。

樣式指南是規則的集合。他們告訴你在給定的上下文中允許做什麼和不允許做什麼。使用這個藍色。不允許使用幾何圖案。只有冷色調。雖然最好的風格指南允許您在規則範圍內進行創作,但大多數只能通過審查和消除不必要的變化來實現一致性。有用,但限制很多。

相反,設計系統應該是過程的集合。最好的是告訴您能做什麼,並為您提供工具來做這件事。

風格指南和設計系統之間最重要的區別可能是他們對變革理念的態度。大多數風格指南都試圖限制變化。設計系統為輕鬆、優雅和可擴展地發生變化奠定了基礎。設計系統在變革的時刻最有價值。當一個大的品牌重塑出現時,一個連接良好的設計系統可以將這種工作從幾個月甚至幾年的單獨修改和重構現有應用程式程式碼減少到幾週甚至幾天。

在設計系統的背景下,我發現很難將“基礎”的想法與不斷追求優雅的組織變革框架相協調。

重塑「基礎」

如果“基礎”是“顏色”或“排版”之類的誤導性標籤,我們應該如何稱呼它們?

什麼都不用。

就稱它們為:“顏色”和“排版”。 如今設計系統工作的一個趨勢是,一切都是元件—感謝 React—所以這些也可以是元件。 像您做其他所有事情一樣按字母順序歸檔它們。

如果你真的需要一個概括性的術語,請考慮像“Identity”這樣的東西,它並不意味著層次結構或順序,並允許這些部分像其他所有元件一樣獨立、可重用和可修改。

「基礎」的警示故事

我們最近與一位客戶合作,他來找我們,因為他們的設計系統沒有看到足夠的吸引力,儘管過去一年它已經啟動並運行,內置了一些元件和“基礎”。

我們與他們一起設定一些基準,以確定如果更廣泛地採用設計系統可以提供多少幫助。在那次試點工作中,我們幾乎沒有談論顏色和排版,而是將大部分時間花在了團隊文化活動、為有趣的內部工具集思廣益和燙手山芋上。

在我們共同工作結束時看到一些非常有說服力的證據後,領導層決定在設計系統工作上投入更多資金—但他們要求他們花更多時間開發更多的“基礎”,這與我們的最終建議背道而馳。

六個月後,該團隊推出了一個漂亮的、新的、定制的參考網站——可能是我見過的最漂亮的參考網站—其中包含一組重組的 design tokens 和大量關於設計語言的文件。設計系統支持 Slack 頻道沒有太大變化;功能設計師和工程師提出的關於如何使用可用的小元件集以及滿足他們需求的新組件何時繼續湧入的問題,每天大約 3-5 個。

一個月後,設計系統團隊宣布他們將減少設計系統支援和與功能團隊共同工作的時間,轉而將時間用於將“基礎”作為首要任務。

在他們最初開始設計系統工作近兩年後,他們正在從功能團隊那裡獲取應用程式,他們希望在新的基礎庫準備就緒後試用它……無論何時。

>”>原文連結>>

相關文章