不同層面的一致性如何改善用戶體驗？
設計系統 (Design Systems) 是一套整合的設計元素共享系統，設計界正對這門知識趨之若鶩。我們做設計系統時，有想過是順應潮流去做，還是真正明白它的真正意義和目標？我做設計系統的經驗不算豐富，只是讀百家之言略有感想，所以我希望在本系列的文章充分分享我對設計系統的理解、反思和看法，特別是一些討論不多的觀點。如果您有任何想法，歡迎留言交流。
由於篇幅在執筆時已超出預期，所以文章會分為多篇發佈。
讓我們先從基礎開始談起 😊
UI Kit 與前端開發框架
設計系統最為人熟悉是將零碎的 UI 整合成可重用的組件 (component)。有時設計師和工程師分別使用 UI Kit 和前端開發框架來加快工作流程，但它們與設計系統有甚麼不同呢？
UI Kit
Dribbble 和設計資源商店中常見的設計系統，其實不少也是 UI Kit。它提供部份基本組件的設計幫助你快速組裝頁面。視覺風格緊貼潮流，例如套用陰影很重的玻璃和陶瓷風格，但由於缺乏設計原則和對組件的闡述，其概念在技術和互動方面通常不切實際，因此不太實用。
前端開發框架 (front-end framework)
在這之前，比較流行的是 Bootstrap 這類前端開發框架。它除了有預製的組件外，還使用 Sass 儲存顏色碼、圓角弧度和間距等變數，亦可稱為 design tokens，是設計系統化的開端；其 12 列的佈局也成為了今天的標準。同樣地，它缺乏設計基礎，而且文檔對非工程師又很難理解，所以它只是方便工程師的工具。
因此，UI Kit 和前端開發框架可以是設計系統的一部份，但它不等於設計系統本身。
作為數碼產品的生態系統
設計系統最基本是整合 UI 元素。隨着業界對設計系統的標準逐年提高，現在已發展成數碼產品的生態系統。我認為箇中原因是為了迎合日益增加的電子平台和設備。
傳統的品牌指引 (brand guidelines) 側重品牌的視覺形象，並不足以保持各個「數碼門面」的一致性。正如我們透過實體店的商品、裝潢、服務流程和店員的待客態度來評價一個品牌，「數碼門面」的 UI、網頁風格、功能流程、互動體驗、文案和公關也是如此。為了在各平台營造一致的品牌形象和標準化的服務，我們需要新的「規格書」——設計系統來規範「數碼門面」上的各種元素。由此可見，設計系統包攬了許多範疇，包括設計原則 (design principles)、風格指引 (style guide)、組件庫 (component/design library)。更重要的是，一般人認為不屬於設計範疇的語調 (voice and tone)、內容指引和程式碼片段均包括在內，使設計系統一躍成為數碼產品的綜合規範、指導原則和開發流程——一個完整的產品生態系統。
設計系統的組成不一定如上圖所示，可以根據內容的輕重而有分別。例如可以將品牌形象、內容指引 (content guide) 和無障礙 (accessibility) 守則，與設計原則、設計基礎及組件庫並列。
不同層面的一致性與用戶體驗
設計系統日益受到重視不無原因。它將零碎的設計整合成可重用和可擴展的模組，以提升開發效率，因而被視為商業策略和產品路線圖的核心。一言蔽之，它的優點是「一致」和「高效」，然而我們該如何解讀這兩個好處呢？
原子設計裏的一致性
許多設計師也明白一致的 UI 組件可以減少用戶的認知負荷 (cognitive load)，使他們更容易掌握和熟悉頁面的互動和用法，毋須記住這個那個。例如：
- 所有主按鈕的樣式一致 → 有助識別主按鈕及其功能；
- 某類流程使用指定的分割排版 → 分辨該流程及其他流程
在做設計系統時，統一基本組件比較容易，所以我們可以進一步追求模組、頁面，甚至流程的一致性。這種層遞原則源自 Brad Frost 的原子設計方法論 (Atomic Design Methodology)。它將介面元素分為五個層次：原子 (atoms)、分子 (molecules)、組織 (organisms)、模板 (templates) 及頁面 (pages)。我覺得將元素分得如此細緻有點吹毛求疵，只需約略明白永遠由小組件組成大組件就夠了，而且組件層級愈高，用戶目標會逐漸從功能轉向流程。
跨平台的一致性
除了保持組件一致，我們還可以用更宏觀的角度理解「一致性」，將它擴展到各個平台和產品。
隨着電子設備愈來愈多，現在大大小小的螢幕也要求有良好的使用體驗。因此，統一各瀏覽平台如網頁、app、kiosk 和其他電子螢幕的元素變得重要，使用戶在轉換設備，甚至是使用 Apple 系統的「接手」(Handoff) 功能時，也能熟悉功能、識別品牌，並擁有無縫的體驗。
這聽起來不難，但實際上除了處理適應性 (responsive) 和調適性 (adaptive) 的問題，還要考慮手機版網頁與手機 app 的設計能否一致。常見的通病是不必要地將網頁跟 app 當成完全不相關的平台去設計。儘管 web、iOS 和 Android 有平台特定 (platform-specific) 的做法，例如基本組件外觀不同，app 有更精簡和線性 (linear) 的資訊架構 (information architecture)，但許多僅供顯示 (display-only) 的組件其實是通用的。在某些情況下，我甚至認為，除了平台特定的組件和流程需要適當地轉換，將手機 app 當成手機版網頁來設計也不為過。當然，我們終究要把各平台的定位和使用場景一併考慮，但與其問「甚麼需要一樣」，倒不如問「為甚麼不一樣」會比較合適和直接。
讓我們來看看外賣平台 foodpanda 的「團購」功能。
用戶可以透過別人分享的 foodpanda 團購連結，然後在 app 或網頁中加入到該團購訂單。foodpanda 沒有因為平台差異而放棄功能，他們追求在兩平台有一致的體驗。雖然介面仍然有少許分別，例如導覽——網頁版側欄和 app 版的底部區域，也有組件——「三文魚腩手卷」的組件外觀，但主要內容的佈局幾乎相同。因此， app 用戶會發現網頁版很熟悉，從此多了一種下單方式，而新用戶即使沒有安裝 app，也可以先在安裝門檻較低的網頁版上體驗服務，繼而轉換成 app 的固定用戶。
跨產品的一致性
公司發展到一定規模便會有多條產品線。例如 Google 有 Gmail、Docs、Sheets、Google Search、Android 等等。即使規模較小，也可以有多個產品，例如網上商店 (電商)、網站、活動頁面、電郵通訊和社交媒體專頁。雖然每條產品線的經營方式、功能和營運團隊都不同，但產品之間若能夠保持一定程度（毋須完全）的一致，不僅能幫助用戶熟悉功能，還可以讓品牌形象更加鮮明。
設計系統如何兼顧多個平台和產品？
視乎產品性質，設計系統不一定只有一個，更常見是「子母式」的設計系統。
以 Spotify 的設計系統 Encore 為例，他們有一個基礎 (Foundation) 的設計系統，統一了 Spotify 旗下產品的品牌視覺和關鍵的風格樣式，即 design token。它的組件分為 web 和 mobile app 版本，而主要的產品會有次級的本地設計系統 (Local Design System)，包含該產品特有的設計元素，但這些元素不會用在其他產品上。如果你的產品也有類似的情況，可以參考一下他們的做法。
這亦帶出了品牌規模愈大，設計系統愈巨型，便更倚賴團隊之間的緊密合作。利用適合的技術，使營運設計系統更有效率，幫助團隊拉近各平台或產品之間的差距。
提高成本效益
很多公司現今需要兼顧多個平台和產品線。個別開發會很耗費資源，而且容易出現不一致的情況。透過設計系統，除了使元素一致，更實際的好處是提高開發的成本效益。組件可以在設計稿和程式碼中重複使用，加快了設計和開發過程，節省了資金，但更顯而易見的是減少了溝通成本。
溝通不暢和專案管理效率低下的主因往往是欠缺文檔。相比之下，設計系統從設計原則、品牌價值、設計元素到內容文案，特別是組件和模組的用法，都有規範和記錄，使設計系統成為唯一的事實根據 (single source of truth)，避免設計師做出不同的設計、減少理解上的分歧，並促進團隊成員間達成共識。無論是行銷團隊的社交貼文、商業團隊的簡報，還是產品經理的提案和線框稿 (wireframe)，不同團隊都可以根據設計系統，製作符合規範、品牌價值和視覺的事物，減輕設計團隊的負擔。因此，公司理應視設計系統為公司資產和團隊之間的橋樑，而非單純設計師個人主張的東西。
重點整理
- 設計系統不只有 UI 整合，而且是數碼產品的生態系統。
- 保持原子設計、各瀏覽平台和產品的一致性。
- 多層面的一致性造就「子母式」的設計系統。
- 設計系統減少開發時間、金錢成本和溝通成本。
下一篇文章我會說說建立設計系統的一二事。
如果需要參考大品牌的設計系統，可以到「設計師道具箱」看看我整理的清單。
🧰 設計師道具箱 – bitly.com/pharm-toolbox
你會覺得文章太長太難懂嗎？務必留言告知。要是想讀個精簡版，歡迎跟隨設計雜學的 IG，我會不定期分享設計新聞、寫寫筆記。
Constance Tang 