[筆記] 如何著手開發 Design System 設計系統

去年參加過 台中前端社群 舉辦並由 jigsawye 大大主講的活動 Design System 設計系統,現在才想到來筆記一下當時吸收到的概念。

Design System

提升產品辨識度,擴充與整合開發能量的利器。

在多人開發專案或需求新增快速,開發時程緊湊,容易出現這樣的狀況:明明是同樣類型的元件,但樣式、API 實作方式卻各不相同,導致使用者體驗不一致,重複實作相同的元件也大大降低了開發效率。

此時最好的做法就是:由開發者與設計師一起討論,定義樣式規範及元件的使用時機,打造模組化、低耦合的元件庫。如此也能創造出符合企業形象、具有辨識度的 Design System ( 設計系統 )。


什麼是 Design System

Design system 定義了產品的整理設計,由一組共享、整合的元素及原則所組成

為什麼要 Design System

  • 一致的使用者體驗
  • 加速開發流程
  • 專注解決問題
  • 展現企業形象

市面上的 Design System

  • Material Design(Google)

  • Ant Design(螞蟻金融科技、OceanBase 雲平台)

  • Base Web(Uber)

  • Primer Design System(Github)

  • Evergreen(Segmentio)


Color

通常需要定義一系列的 color、typography、spacing 等等。

不同的 design system 之間也會有自己另外的視覺定義,像是 shadows、border radios 的差異等等。

Design system 的顏色通常包含識別色,功能色以及中性色。
且通常包含其衍生色(深系及淺系)。


Reference

識別色

代表整個 design system 的視覺元素,使用場警包含關鍵操作、選取狀態、呈現重要訊息、圖形主色調等。

功能色

通常狀態跟顏色對應,分別用在提醒、成功、錯誤、警告的場景。

Reference

中性色

灰階色,用在文字、背景、邊框、分割線等地方。

不同的 design system 也會衍生出更多的色彩設計,像是背景專用色。

Typography

主要定義幾個方向,包含 font family、base font size、font scale & line height、font weight、font color

Font Family

在中文使用情境下建議使用系統內建的字型。
在另外定義及等寬字型。

Base Font Size

建議的基本字體大小為 14px, 以確保基於螢幕閱讀距離(50 cm)和最佳閱讀角度(0.3)的用戶在大多數情況的最佳閱讀效率。


Reference

Font scale & Line height

決定字體比例與行高。

字體比例與行高決定了 font system 的動態與美感,font scale 是一系列不同大小的字體,行高可以理解為包裹在字體外面的隱形盒子。

以 Ant Design 為例, Ant Design 的靈感來自五聲音階和自然法則,定義了 10 種不同的字體大小和相應的行高。

Reference

Font Weight

在大多數情況下,只需要 regular(400) and medium(500)就足夠應付大多數情境,對於粗體英文單字可以使用 semibold(600)。

Font Color

如果文字與背景太過接近會導致難以閱讀,建議正文、標題和背景顏色之間的對比度為 7:1 或更高。

Sizing & Spacing

Padding 和 margin,以 4 的倍數為佳

0, 4, 8, 12, 16, 24, 32, 48, 64

Breakpoints

用於 RWD 的 breakpoints,依使用情境設定

480, 576, 768, 992, 1200, 1600


問題點

  • 多人的專案在開發時,類似的元件做了好幾個,有的以 Bootstrap 為底來修改,有的直接 CSS(styled-components)實作。

  • 不同的元件間實作相似的 API ,像是 input 的 onPressEnter,button 的 loading 狀態 ,導致不一致的使用者體驗。

  • 複雜的元件邏輯仰賴各種第三方套件,維護困難。

著手解決

整併元件

把共用元件整理起來,放到單一資料夾,重複的使用邏輯也整理再一起。至少將類似的元件整理在一起。

整理文件

幫把一個元件整併元後,使用 Storybook 寫基本的範例作為文件範例供其他開發者參考。

精煉過程

種子期

已有初步的 design system 的概念,但多為開源現成的樣式,較缺乏使用體驗以及視覺上的獨特性與統一性。
因此需要進一步開發 design system 的定義。

蒐集與探索

搜集

針對產品進行紀錄,分析不同頁面元件的狀況,找尋 相似的元件,卻有分歧,使用者體驗不同的樣式或行為

造成的原因可能是迭代開發過程中,產品經由不同的設計師或工程師之手。

探索

在搜集、了解產品的元件使用狀況後,可以向外參考市面上的 design system 產品作為設計規範參考,像是 Ant design 或 Evergreen 等範例,可以幫助開發者理解完整的 design system 需要具備哪些元素。

建構與測試

完成前期的搜集與探索後,此時可以挑選幾個較為複雜或較常使用的頁面,讓多種元件羅列出來,進行 redesign 再設計,並產生幾個提案,經由團隊討論或訪談確定方向。

定義

在確立了頁面提案後,可以開始進行細節的元件定義,包括使用的色彩、字體、陰影、間距、元件狀態、模組呈現等,同時訂下元件規範,同時也可對產品標示(Logo),進行調整,已達成獨特及統一性。

實作細節

Stylesheet

  • 常見的開發方式是 css 與 javascript 分開寫,使用的人再另外 import css 。
  • 或是像 styled-components 的 CSS-in-JS 套件。
  • 對於開發人員即使用套件的人,CSS-in-JS 的做法較為友善,import 即可使用,無需在處理 CSS 的 bundle 問題。

Typescript

  • 新專案建議採用 Typescript,尤其是 design system 這種提供給外部使用者使用的套件更是必備,防止傳入的參數沒定義好,或是沒做好 error handle 的狀況。

Linter & Prettier

  • 在新的專案加上 ESlint 及 Prettier
  • 加強 coding style 避免出現奇怪的寫法
  • 在其他開發者加入時可統一格式

Testing

  • 每個元件都寫上測試,至少要有 snapshot
  • 推薦使用 Jest + Testing Library

文件

  • 建議可以使用現成的文件框架
    • Docusaurus v2
    • Docz
  • 支援 MDX
  • 支援 code editor
  • API 寫清楚
  • 大量範例

效能改善

因為產品有大量 render component 的情形,假設元件有大量複雜邏輯的情況,會導致效能低落。

  • 善用 devtool 找出效能瓶頸。
  • 改善 render 效能,善用 memorize
  • React.mome / useMemo / useCallback
  • 善用 React Portal 將 absolute 的元件 render 在 root

Server Side Render 的問題

  • 要用到 window / document 的地方需要加上檢查
  • 善用 useEffect / componentDidmount 只會在 client side 執行的特性。

img

使用現成的 design system 再修改樣式

  • 自行開發的維護成本較高
  • 站在巨人的肩膀上,有成熟的 API 及文件
  • 缺點是可控制性不高,較不利於客製化

img
Reference

建立私有 NPM 以管理以及共享套件

可以透過 verdaccio 來管理以及共享套件

img

版本號

  • 版本號依循 Semantic Versioning
  • 不隨意 break API
  • Breaking changes 在 changelog 寫清楚
  • Break / deprecate 前加上警告

參考