一個好的設計系統的秘訣
已發表: 2022-03-10這篇文章得到了我們親愛的 Backlight 朋友的大力支持,Backlight 是一個協作平台,使前端團隊能夠構建和發佈出色的設計系統。 謝謝!
理論上,每個人對“設計系統”的含義都有一個相對相似的概念,儘管隨著我們接近現實世界,細微差別開始出現。 目標可能仍然相同,但不同的組織將需要不同的策略來實現它們。 與工程和架構中的許多複雜任務一樣,沒有什麼靈丹妙藥可以打造一個好的設計系統。
儘管成功的努力有一些共同的模式,這些模式使得工具和最佳實踐得以出現。 在本文中,我們將了解哪些解決方案適合設計系統的保護傘,以及您在整個項目中需要關注的一些重要步驟和檢查點。 我們的經驗可能會有所不同,但希望你能從我個人失敗和成功的地方學到東西。
目標與意義
如果我們將“系統”視為協同工作的部件的組合,而將“設計”視為某事物的外觀和功能計劃。 然後我們可以將設計系統理解為定義的集合,這些定義將指示系統互連部分的外觀、感覺和工作模式。 這仍然是相當抽象的,但足以理解它不僅僅是看起來。
它不是您像拼圖一樣組裝並獲得一致佈局的組件庫。 一個設計系統確實有一個表現方面,但它也是關於功能和集成的。 這是關於經驗。
- 用戶體驗
具有可靠且功能一致的用戶界面。 - 開發者體驗
具有易於集成的組件和定義的模式。 - 利益相關者經驗
對產品如何發展和發展的總體概述。
有這麼多移動部件,可以理解的是,所有設計系統都沒有一個單一的答案。
有意與有機
當一個團隊決定創建一個設計系統時,他們需要預先決定兩種方法:
- 有機的
以現有應用程序為參考,提取其中的部分並將它們抽像到足以供另一個應用程序使用。 這種方法從一開始就包含較少的決策,但需要團隊做出更多的反應性努力來適應採用者新發現的需求。 架構決策傾向於根據需要而不是主動做出。 - 故意的
標記、模式和組件是提前考慮的。 定義最小可行產品 (MVP) 的邊界並開始工作。 對於這種方法,制定目標和要求是使期望與利益相關者保持一致的重要步驟。
有機的
當允許設計系統有機地發展時,努力的成功歸結為利益相關者和採用者的支持。 以及團隊在清除沿途發現的所有未知數時能夠做出反應的效率,而不會在持續的支持下過度破壞。 這是一條棘手的道路,溝通是關鍵。 沒有明確的行動路徑,因為它與團隊的環境緊密相關。
此外,在系統運行時很難對其進行調整(詢問您當地的電工),並且由於任務需要時間,要求可能會發生變化:市場不會等待您的組件庫。 對於有機設計系統來說,通常的“成敗”時刻是找出組件 MVP(最小可行產品)的開發故事。
一方面,我們的開發人員和設計人員希望打造最佳體驗和典型的代碼質量; 另一方面,有 KPI、ROI 及其首字母縮略詞來衡量成功。 找到平衡並保持可擴展性是很棘手的。 如何把未完成的東西抽像出來就更棘手了,避免那些後續任務在積壓中被遺忘是價值百萬的產品管理問題。
在處理有機方法時,能夠在您的設計系統上快速且漸進地迭代成為基本要求。 它還需要您的消費者開發人員更加清晰(如果有不同的團隊:一個創建設計系統,另一個創建產品功能)。 兩者都必須清楚地將期望與產品要求和開發人員體驗要求保持一致,以實現適當的共生。 因為如果設計系統使用起來很煩人,或者如果它以任何方式使用戶體驗變得更糟,那它什麼都不是。
故意的
在有產品使用之前,有意識地選擇構建設計系統時,需要進行更多的規劃、清除未知數和準備基礎設施。 另一方面,約束帶來了更多的清晰度。 目標和期望。 如果在離開港口之前對帆進行雙重檢查,風暴就不那麼可怕了。
當提前計劃時,系統的可預測性也會增加,這是因為設計系統成為自己的產品,而不是讓其他人變得更好的工具。 通過這種抽象,其他人使用的模式和解決方案更容易傳輸。
儘管最初選擇 Intentional 而不是 Organic 對於經驗較少的團隊來說可能會適得其反,因為沒有要測試的概念驗證,但在開始時避免常見的陷阱特別有幫助。 “站在巨人的肩膀上”是一個常見的行話,在這種情況下是真實的。 所以,這方面的最佳配方應該大致是:
- 確定基本要求;
- 對類似案例及早徹底研究;
- 略去 2 的結果以獲取隱含的解決方案和策略;
- 通過組合常見的解決方案並添加自己的醬汁,將其全部變為您自己的;
- 迭代。
這五個步驟聽起來簡單明了,但事實並非如此。 很容易跳過一個需求收集或縮短研究時間。 不過,有一條建議:如果您忘記了其中任何一個,您將在第 4 步支付利息。
為效率而建
當依賴項更新以任何方式破壞他們的應用程序時,沒有包消費者喜歡。 當所討論的包是設計系統的一部分時,也沒有什麼不同。 實際上,有人可以指出情況更糟。 內部依賴破壞應用程序的反彈往往比開源包更大,此外,UI 更改往往會首先在最終用戶面前“悄無聲息地破壞”:這尤其令人沮喪。
考慮到這一點,我們已經可以列出一些問題:
- API 文檔
使其易於發現和使用。 - 版本控制
指示發布預計將如何影響消費者。 - 變更日誌
指示每個版本進行的更改。 - 釋放
一種保持穩定代碼易於為所有消費者交付的明智方法。 - 開發環境
目前還沒有應用程序使用它,必須弄清楚如何展示和開發工件。
需要指出的是,這些項目中的每一項的優先級可能會根據您的里程而有所不同。 但隨著設計系統的擴展、採用的增加和功能的增長,它們的必要性將會增加。 它們可能不足以阻止團隊前進,但如果能力偏向於找出這些解決方案,它們肯定會阻礙生產力。
真相之源
許多團隊最終面臨的另一個痛點是識別設計系統中的真實來源。 是代碼、UI 還是文檔? 對於很多種類的產品,我們只看消費端,我們可以很容易地識別出主要的輸出是什麼。 在這種情況下變得棘手的原因是因為每種消費者都會以不同的方式使用它,因此答案會根據所詢問的人口統計數據而有所不同。
設計系統通常是組件庫、文檔和样式指南的混合體。 不僅每件文物的消費者不同,而且工匠也不同。 開發人員、設計師、技術作家; 需要不同的人來創建每個輸出。
熱土豆
為了保持交付的一致性,溝通和協作是關鍵。 並且已經建立的類似瀑布的過程對任何一方來說都不令人鼓舞。
沒有基於每個專業的協作或迭代設計(雙關語)空間。 設計師通常不知道一些代碼限制,而開發人員對輸出的用戶體驗一無所知。 這種方法並不是非常有偏見,可以用它創造出好的產品。 但是一個偉大的人是很難的,除非團隊積極努力糾正它,否則流程的每個部分幾乎都是斷開的。
總是令人驚嘆的 Dan Mall 和 Brad Frost 為新工藝創造了同樣偉大的名稱:Hot Potato。 這個過程不僅鼓勵溝通,而且通過統一工作的真實來源,直接將協作強加給團隊。 這樣一來,不僅每個交付的工件都有一個共同的來源,而且它們也是聯合團隊專業知識的產物。
然而,讓這種無摩擦的協作說起來容易做起來難。 甚至並排坐著躲避“你被靜音了”、“我的連接掉線了”和“你能聽到我說話嗎?” 煩惱,當信息交流並置時,往往很容易變得非正式,然後該過程可能最終難以記錄或過於同步。 我們想要更少的瓶頸,而不是更多。
同行之間的實時協作已經達到了很大的程度。 像 VSCode Share 或 Figma 的 FigJams、雲 IDE 一樣,有很多選擇。 但是當涉及到不同專業之間的迭代時,它並不是非常簡單。 將此添加到前面部分中提到的工具、架構或流程堆中,甚至在開始工作之前,您就有大量工作要做。
構建系統
如上所述,維護設計系統是一項繁重的工作。 最好的建議可能是盡量不要從頭開始做事。 在方便的地方使用社區資源。 這樣做可以減少維護系統特定點的時間,並且如果工程師和設計師已經熟悉系統的某些部分,這將有助於他們入職。
進來背光。 它是一個平台即服務,它以一種自以為是但靈活的方式將一系列工具組合在一起,以加速整個架構設置。 您可以從頭開始,也可以選擇最適合您項目的入門模板。 如果不是完全必要的話,不會重新發明輪子,它們在所有啟動器中都使用社區資源(我嘗試過的 Yogi 是基於 ChakraUI 的),對它們的維護更少,並且消費者不必擔心被鎖定。 此外,代碼將被推送到您的版本控制平台,因此只需幾個 shell 命令即可在必要時移出。
到那里後,它將安排與版本控制平台(支持 Gitlab 和 GitHub)、基於 Storybook 的沙箱、基於 VSCode 的 IDE、單元測試,甚至發佈到 NPM 註冊表(最後這取決於您與他們的計劃,它可以是您的帳戶或他們的帳戶)。
多個輸出
我們之前映射了大多數設計系統需要至少 3 種不同的輸出:文檔、代碼、用戶界面。 一旦架構準備好輸出它們中的每一個,團隊通常會發現另一個挑戰:保持它們同步。 開發人員總是渴望以原子方式進行更改,您觸摸一個地方,它們就會分散到使用該信息的每個地方。 在設計系統中,這並不總是很清楚如何完成。
如果您沒有遵循 Hot Potato Process,很容易忘記開發人員已經解決了哪些 UI 更新。 即使你這樣做了,也會有文檔。 背光通過搭配一切解決了這個問題。
一旦更改完成,無需離開平台的儀表板。 可以檢查更新的實時文檔。
而這一切只是觸及了他們可以用來提升你的架構的表面。 您還可以獲得:
- 使用“視覺審查”功能對拉取請求進行屏幕截圖測試
- 帶有內置單元測試的測試驅動開發支持
- 帶實時預覽的沙盒
它是您設計系統的完整開發環境。 即使您決定不使用它們的啟動器,您仍然可以獲得所有這些集成。 基礎設施可以讓您構建組件庫,從頭開始為您的設計系統提供支持。
實時遠程協作
如前所述,Hot Potato Process 可能會為團隊設置遠程和異步工作方式帶來麻煩。 背光解決了這兩個特點的組合:
- 設計整合;
- 分享一個實時鏈接。
設計集成將您的設計工具中的設計工件帶入同一平台。 因此,團隊的其他成員可以直接從同一個儀表板查看、添加評論和參考工作:
借助此功能,無論您的團隊位於何處,燙手山芋流程都可以從繪圖板開始。 在不切換標籤的情況下,它也可以通過鏈接共享功能來平滑地來回編碼過程,用他們的促銷 gif 來解釋比我自己做的任何事情都好。 開發人員可以共享其工作的實時遠程鏈接,而無需在任何地方發佈內容,也無需中間過程,這對於需要快速迭代詳細工作的團隊來說是一個很大的推動力。
外賣
如果還沒有,希望現在更清楚創建和維護設計系統需要什麼。 不僅僅是少數 CSS 類、標記定義和字體; 它是工具、積極的支持和倡導。 項目的有用性取決於其輸出的質量以及它適應不斷變化的需求的速度。
因此,如果不出意外,請準備好在創建項目時提高生產力和效率。 如果您仍在尋找自己的立場,Backlight 等工具將幫助您實現合理的默認設置和開箱即用的出色用戶體驗。 如果您已經熟悉特定架構,請明智地選擇您的戰鬥並使用社區來處理其餘部分。