Components 與 Patterns 究竟有什麼區別

01-29

上期的周刊我們介紹了 Design System 中最為重要的一個概念 - Principles，作為整個 Design System 的核心，它將指引著我們整個產品設計、開發的過程和決策，同時它也體現在我們整個 System 的基礎建設中。

今天第三期的周刊將給大家介紹 System 中的 Components 和 Patterns，作為我們整個產品建設中的「磚、瓦、泥」，System 的「魂」也需要直接體現在它們的設計中。

在 Design System 的討論中，Components（組件）和 Patterns（模式）是一組非常容易混淆的概念。有些 System 中只有 Components，另一些卻只有 Patterns，還有一些兩個都有。

由於我們不在其業務背景之中，理解他們的理念、初衷並不是那麼容易，所以今天的這一期我們將 Components 和 Patterns 放在一起來討論，看看他們之間究竟有哪些差異？我們應該如何去創建、使用它們。

Components 是什麼？

在這個系列的第一期，對 Components 有過一個基礎定義。它是整個產品設計的基礎，是組成一個界面的最基礎元素，為完成一個基礎操作提供支持。

早在 Web 時代我們就有了 Components 的概念，輸入框、按鈕、文字、鏈接、下拉菜單… 從網頁開始出現，這些元素就已經被大家所認知、牢記。無論頁面的設計如何變化，它們基本上都是由這些組件所組成的。

當然，網頁時代的早期我們可用的組件並不多，偶爾出現一些新的形式也都是基於現有的組件組合或變形而來的。

所以對於用戶來說記住並理解它們的用途並不太難，這也就為日後的設計的不斷發展提供了一個可被認定、認知的基礎。

移動互聯網時代的到來，用戶的互聯網環境已經逐步遷移到了手機。於是對於設計師和用戶大家開始接觸到了 iOS、Android、Microsoft 等新的平台，開始與這些新的組件打交道。

事實上這些元素並沒有發生太大的變化，它們很多只是基於屏幕大小和可觸控的新特性發生了進化。而我們所看到的那些組件在不同平台上的差異性更多是源於系統平台本身以及它們的設計理念差異。

這個現狀給設計師帶來了更多的麻煩，我們在設計產品的同時還需要更多的關注不同操作平台的組件差異性，以順應不同用戶的使用習慣。

當然，隨著行業的不斷發展我們所面臨的麻煩會更多，我們現在所能看到的 VR 設備、線下實體以及我們還未看到的新的形式都會讓 Components 不斷的進化，也變得更複雜。

Patterns 是什麼？

相對於 Components，Patterns 要處理的事情會更複雜一些。它的目標是為完成一個任務提供基礎操作，是解決一系列問題的全局解決方案。

舉一個直接的案例，在 Material Design 中有一個叫做 Confirmation & Acknowledgement （確認與知會）的 Pattern（見上圖）。

簡單來說當用戶在 App 中執行了一個操作，我們需要給予反饋，告知用戶，而這個 Pattern 要解決的問題就是為這一系列場景提供一套設計解決方案。

其實無論是 Components 還是 Pattern，它們都是目標都是為具體的問題提供實際、可復用的解決方案，為整個產品開發過程提供一致性保障、提供決策依據以及提升效率降低開發成本。

Components 與 Patterns 有什麼差異？

基於上面的描述，大家應該對 Components 和 Patterns 有了一個基礎認知，但它倆之間的具體差異還是比較模糊，所以接下來我們從功能角度來接著聊聊它倆的差異。

事實上大多數的 Design System 並沒有特別清晰的去定義它倆，有些只給出了 Components，有些只給出 Patterns，比如下圖中的 Salesforce、Carbon、MailChimp。這背後其實與對應的業務領域及這些 System的理念有很大的關係，我們在後面會再提及。

相較而言 Material Design 對於 Components 和 Patterns 有明顯的定義和區分。從這些關鍵詞的定義上我們基本可以看出Components 關注的是產品中的某個點，相對簡單；而 Pattern 關注得更多是一件事兒，也相對更為複雜。

還是回到前面 Confirmation & Acknowledgement （確認與知會）的案例，Pattern 抽象了業務的可能性並提供了一個通用性的解決方案。

操作觸發、給予反饋，這裡面包含的情景和複雜度顯然是高於利用菜單展示一列信息的。Material Design 將它大致分成了兩種主要情景：

重要操作，需要用戶確認
非重要操作，需要知會用戶

Material Design 分別使用了 Dialogs（重）和 Snackbar（輕）兩種設計形式來回應著兩種情景，為其提供更為合適的解決方案。

從業務場景抽離出來看，這個 Pattern 不僅可以用於信息列表的處理，還可以用於處理購物車、wishlist、聯繫人… 這些業務場景各不相同，但都可以使用同一種設計模式。而這些 Design Pattern 也正是由我們前面所提到的 Components 組合而來的。

再回到細節部分，Components 作為「磚、瓦、泥」是有明確的使用指導的，每個組件的尺寸規範使用方法都有明確的文檔給予細節的支持。

而 Patterns 作為一種通用解決方案則更加靈活、鬆散，面向的不是一個具體界面而是一個產品（用戶）的需求而服務的。

我們可以再來看一個更為直觀的例子 - 播放器。下圖是 YouTube 的在線播放器，從 System 的角度來說它會被應用在平台的很多情景中。

我們可以將它定義為一個視頻播放的通用 Pattern，如果我們將它（下圖左）作為該業務下播放器最複雜、最全的解決方案，那麼它也將應該依據場景訴求逐步降級（下圖右），為播放器提供一個整體性的設計解決方案。

下圖是 YouTube 播放器的功能操作區，這裡面隱藏了 YouTube 的很多強大功能，從字幕、外鏈到畫質設置，都可以融入到這一小塊區域中。

如果我們嘗試對這些功能做一些分解，可以大致還原出這個 Pattern 的整個框架。為了讓這個 Pattern 具備設計和工程兩個層面的一致性和復用度，設計師需要將關注點從某個具體業務抽離回來，站在更高的視角去看如何打造一個適用於更多情景的播放器框架，對於框架的構想和定義也能夠方便所有相關人員用同樣的思維方式去思考、判斷問題。

當然，Pattern 並不僅僅以這一總形式存在，它的目的就是解決一類問題。它可以是一組界面，也可以是一個任務流（比如購買流程），甚至也可以是一套手勢操作。

在前面我們提到過，Pattern 與 Components 還有一個很大不同 - 領域的差異性。對於 Material Design 這種系統底層的 System 來說它可以服務於任何領域、業務類型，所以他們的 Pattern 很「中立」，但對於我們絕大多數設計師來說，我們主要關注的是某一個領域的產品，所以我們也更應該關注到 Pattern 的領域差異性。

Firefox 在幾個月前也發布了他們自己的 Design System - Photon。作為一款瀏覽器，Firefox 的關注點顯然與我們大多數人是不一樣的。

瀏覽器（殼）中的內容是由網站所提供的，Photon 更關注的自己所服務的部分。它們會對 Warnings（警示）這類瀏覽器服務做清晰的定義，制定了普通警告和重要警示兩種不同等級，並提供了相應的設計展示。

而對於 MailChimp 它們甚至就不提供 Components ，只給出了一組 Pattern（比如下圖的 Feedback）。因為 MailChimp 自己的自身特性，它們的封裝已經足夠完整而且業務特性也非常的鮮明（且不會過於複雜），直接提供 Patterns 反而更利於整體的一致性和效率。

當然，MailChimp 沒有提供 Components 並不代表它們沒有，只不過將它們收起自行維護，使用者不用關心罷了。

聊了這麼多我們不妨再來想想 Components 與 Patterns 之間的差異，我嘗試將它歸納成以下幾點：

Components 相對穩定，是整個 System 中的基礎物料（磚、瓦、泥），是解決單點問題的基礎元素。大家對它是具備基礎認知的；Patterns 則是解決一類問題的整體解決方案，有多種的可能性；
從工程角度來說 Components 也是相對穩定的，Patterns 是基於這些相對穩定的 Components 組合而成的；
Pattern 具備領域的差異化，不同的領域它所關注的點以及設計的處理形式都存在著差異；
Patterns 更加的複雜，不只是界面，也可以是流程、手勢、甚至是透過視覺、動效、文案傳遞出的一種氣質。