Design System Practice
初次設計系統經驗分享
前言
我一直對建構 Design system、Design guideline 很有興趣，因為在建構的過程中，可以深度了解與思考各個元件的操作、適合使用的場景、享受制定屬於自己產品視覺風格的過程。
以往的經驗都是為單一專案整理出 Design guideline，每個專案都擁有自己的風格。但這樣的做法在團隊運作一段時間後，就面臨到團隊人數有限，專案無限的狀況。在資源有限的情況下如何達到不重工並加快開發效率，讓相同元件的設計與程式碼可以在不同專案重複利用，變成我們下一步目標。
於是，我們開始思考如何建構自己的 Design system，不只是設計，也將程式模組化。但在團隊資源有限與同時有專案進度的情況下，並無法做到像 Airbnb、Google Material Design、Ant Design、Atlassian 這麼完整。我們能解決的是先抽出共用元件，將其模組化，變成 Common UI Library，讓共用元件可以跨專案的使用。
建立 Common UI Library 流程
當提出建置新元件需求後，我們會盤點他的實用性、必要性：
- 是否不同專案都會使用？
- 是否其他元件無法取代其功能？
這部分會直接影響要不要實作以及實作的先後順序。接著設計師可以為了這個元件提案，提案包含：
- 元件的名稱
- 視覺呈現
- 功能涵蓋範圍與互動操作
提出後，團隊的每個人都可以表達自己的意見，採多數投票決。通常工程師對於「功能涵蓋範圍與互動操作」會跟設計師有比較多的討論，原因是各自還有專案進度要做，所以會討論現階段這個元件要做到多完美、多通用。
實作後，工程師會 Pull request 給團隊做驗收，驗收項目包含：
- 視覺呈現
- 功能與互動操作是否達到預期
- Code review
驗收完成後才能 Push 到 Common UI Library，這就是我們建置的流程。建立了內部開發使用的 Common UI Library: MTKUI 後，除了加快前端的開發速度外，最重要的是可以讓設計師將重心放在流程規劃的部分。
但這樣的流程要維持不太容易。除了剛剛提到的各自還有專案進度要做，在這個流程裡我們並沒有指定是哪位設計師與工程師要負責什麼元件或模組，靠的是自發性與熱情。當專案一忙起來，建置的速度就會延宕 ; 再來是前端技術日新月異，所使用的套件如果升級，免不了要再花時間調整。其他的缺點還有設計風格會被侷限、建置後要花時間替換原本的元件等等。
所以擁有自己的 Design system 是條不歸路，組織要有共識並且願意持續投入人力才會走得長久。要有 Design system 前，還是要先知道自己的需求以及想解決什麼樣的問題，才討論需不需要建置自己的 Design system。
開源前的準備
時間拉回到今年初，在知道了 MCS Lite 有開源計畫後，我便開始收集與 Design system 相關的資料（文末有連結），例如什麼是一套好的 Design system、需要具備什麼思維來設計 Design system 等等，用來檢視目前設計得 MTKUI 在開源前還有哪些地方可以調整或可以做得更好。特別提一下，我並不是從零開始，而是從現有的 MTKUI 抽出 Lite 所用的元件，做開源的準備，我們就稱它為『MCS Lite UI』吧。
以下是我在開源前做的一些準備：
1. 命名的規劃與整理
從 Common UI Library 抽出 Lite 所用的元件並做開源準備的第一步就是整理命名。除了了解各元件正確的名稱外，如何讓整體命名邏輯一致，使用起來一目了然？這時腦中會突然湧現很多想法，例如需不需要加上底線呢？使用分隔線呢？還是用空格？要用大寫還是小寫呢？
決定命名邏輯的同時，也要想一下元件的最小單位是什麼？要怎麼劃分？例如元件切割得越小、Symbol 化越多，可以調整的彈性越大，但整份 Guideline 也會變得複雜，特別是當使用者要更改狀態時。
以下是幾個範例的觀察：
- 以 Facebook iOS 10 Sketch 來說
元件命名 → 單字的字首都是大寫、使用空格和 Dash、不使用縮寫 - 以 iOS-10.0-Sketch 來說
元件命名 → 單字的字首都是大寫、使用空格和 Dash、不使用縮寫
Symbol 命名 → 與元件命名方式相同，但少部分使用縮寫 - 以 Material Design (stickersheet_components_20170314)來說
這部分先不討論新加上的 BOTTOM NAVIGATION 部分，這部分感覺是另一位設計師整理的，與之前的命名風格不太一致。
元件命名 → 除了元件群組名稱外，其餘都是小寫、使用空格、使用縮寫
Symbol 命名 → 單字的字首大寫、使用空格 (此規則 ic 除外)
比較之下，我發現自己的實作習慣比較類似 Google Material Design，所以命名邏輯會比較參考它。
- 我的命名方式：
元件命名 →
只有元件群組名稱單字字首大寫：對應檔案裡分類名稱的呈現
使用空格：在不需出圖的情況下，覺得空格的顯示方式最乾淨清楚
使用縮寫：節省顯示空間 - Symbol 命名 →
全小寫並使用空格：個人習慣
利用斜線做階層分類：主要順序為元件名稱/類別/大小或狀態
組成 Symbol 的元件用 _element 做分類
影響 Symbol 的視覺、狀態，用 _style 做分類
簡化一個例子：組成一個基本類型的 Input 包含 Label, Input box, Input box 的狀態以及 Input box 裡的提示字和輸入文字。所以分類就會是：
input/default
input/_element/input box
input/_element/label
input/_style/state/normal
input/_style/state/focus
input/_style/state/error
input/_style/state/disable
2. Symbol 建制與 Overrides 命名調整
延續剛剛提到的例子，input/default 由 input/_element/input box 與 input/_element/label 組成，組成 Symbol 後你可以在右邊的 Overrides 看到各個 Symbol layer 名稱，名稱太長就會以點點點顯示，識別性低。所以接著要調整 Symbol layer 命名，也就是左邊橘色框框的部分。
調整命名後是不是更清楚呢？由於連結性已經建立，即便調整左邊 Symbol layer 的命名，任何修改還是可以同步，也可以讓右邊 Overrides 的顯示名稱更精簡，讓使用者一看就知道這個是控制哪個元件。
所以其實在命名這階段，可以依照團隊需求或是個人習慣來制定，沒有一定要遵守的規範。不過還是有些小提醒或曾經踩雷的經驗可以跟大家分享：
- 不要用太具體的名稱命名
例如不要用主色命名元件，因為主色會因不同專案而有所改變。
舉例：如果是主要按鈕的話，取名叫 Primary btn 會比 Blue btn 適合。原因是若這份 Design guideline 使用在不同專案上時，當使用的主色有改變，元件也不需重新調整命名，修改彈性較大。 - 不要用在哪個裝置上使用來命名
例如 Desktop modal/ Tablet modal。因為會有使用在其他地方的可能，可以改用大小來命名，例如 Default modal/ Small modal。 - 盡量不要修改 Symbol folder 名稱
如果改到 Symbol 的名稱，也就是左邊 Symbol folder 的名稱，目前 Sketch 不會自動同步更新。當你改了 Symbol folder 名稱後，要檢查這個 Symbol 是不是其他 Symbol 的子項目、或是這個 Symbol 有沒有使用在任何地方，如果有的話要一併修改命名，命名才不會錯亂。 - 善用符號標示從屬關係
Overrides 中有的 Layer 是從屬關係，例如當你關閉 input/_element/input box 時，它的子項目：input box text 與 input/_style/state/normal 也會消失，所以命名時可以在子項目名稱前加個符號（按下 Control+Command+Space 可以叫出 Emoji）示意它是某個 Symbol 的子項目，當使用者要調整某個 Symbol 狀態時也會更加直覺、方便。
3. 更加彈性化的元件設定
我們還可以利用 Sketch 的 Resizing 或 Sketch plugin 來做到更彈性的元件。你可以下載 MCS-lite_design_guidelines 試試。
4. UI Demo Page 呈現
目前我們是用 React storybook 這個套件來呈現 MCS Lite UI，它可以邊開發邊看到即時的 UI 呈現。如果有時間和人力的話，設計師也可以設計這個頁面。
初次開源
MCS Lite 是 MediaTek Cloud Sandbox (MCS) 的離線版本，適合使用在固定網域範圍的場景，例如學校電腦教室的教學場景等等。您可以安裝 MCS Lite 在自己的電腦中，輕鬆快速地建置自己的私有雲，不需再受到網路環境的限制。除了電腦版之外也支援 Mobile Website。
如果對 UI 組件化的工程端實作部分有興趣的話，可以看看我們工程師的文章：Build A Web App in MediaTek，不管是程式還是設計都希望跟大家有更多的交流：)
後記
雖然我們解決了跨專案共用元件的使用問題，但由於時程、人力上的因素，在前期我們並沒有辦法針對 Design system 的理念、視覺特色做完整的發想與提案，只能依據現有的風格作延伸，這是我覺得比較可惜的地方。不過我很享受這個過程，看了許多分享的文章不如自己捲起衣袖實際操作一次，確實從中得到許多寶貴的經驗。
至於這份設計檔在 Symbol 與 Resizing 化後，是否可以順利運用在不同專案上並加快設計的速度，我想，又是下一次可以跟大家分享的題目了:D
最後列出我覺得有幫助的文章，提供大家參考：
參考點：了解建置 Design system 的流程
參考點：了解建置 Symbol 過程
參考點：提出利用 8pt 為單位的 Grid system 來設計元件。例如 Material Design 也是使用 4dp 或 8dp 為設計的最小單位 ; 另一個原因是目前大部分的解析度都可以 8 來整除，所以目前蠻提倡用 8pt 為單位來建置整個 Grid system。更多說明看這篇：https://spec.fm/specifics/8-pt-grid
參考點：好的 Design guideline 是容易使用的、是易學的、是清楚的、是合作的、是容易更新的。除了靜態的元件外，可以使用 Sketch 的功能來做到更清楚的 Design guideline ，例如使用 Shared style 功能來規範文字和顏色、使用 Nested symbols 功能可以快速更改元件狀態、使用 Resizing 功能可以展示元件的 RWD 行為。
參考點：如何建置 Design Language System、審查機制及後續維護
