想成為高級UI 設計師？先學會構(gòu)建自己的設計體系！

我一直對建構(gòu)Design system、Design guideline 很有興趣，因為在建構(gòu)的過程中，可以深度了解與思考各個元件的操作、適合使用的場景、享受制定屬于自己產(chǎn)品視覺風格的過程。

以往的經(jīng)驗都是為單一專案整理出Design guideline，每個專案都擁有自己的風格。但這樣的做法在團隊運作一段時間后，就面臨到團隊人數(shù)有限，專案無限的狀況。在資源有限的情況下如何達到不重工并加快開發(fā)效率，讓相同元件的設計與程式碼可以在不同專案重復利用，變成我們下一步目標。

于是，我們開始思考如何建構(gòu)自己的Design system，不只是設計，也將程序模組化。

但在團隊資源有限與同時有專案進度的情況下，并無法做到像Airbnb、Google Material Design、Ant Design、Atlassian這么完整。我們能解決的是先抽出共用元件，將其模組化，變成Common UI Library，讓共用元件可以跨專案的使用。

  建立Common UI Library 流程

當提出建置新元件需求后，我們會盤點他的實用性、必要性：

• 是否不同專案都會使用？

• 是否其他元件無法取代其功能？

這部分會直接影響要不要實際制作以及制作的先后順序。接著設計師可以為了這個元件提案，提案包含：

• 元件的名稱

• 視覺呈現(xiàn)

• 功能涵蓋范圍與互動操作

提出后，團隊的每個人都可以表達自己的意見。通常工程師對于「功能涵蓋范圍與互動操作」會跟設計師有比較多的討論，原因是各自還有專案進度要做，所以會討論現(xiàn)階段這個元件要做到多完美、多通用。

實際操作后，工程師會Pull request 給團隊做驗收，驗收項目包含：

• 視覺呈現(xiàn)

• 功能與互動操作是否達到預期

• Code review

驗收完成后才能Push到Common UI Library，這就是我們建立的流程。建立了內(nèi)部開發(fā)使用的Common UI Library: MTKUI 后，除了加快前端的開發(fā)速度外，最重要的是可以讓設計師將重心放在流程規(guī)劃的部分。

但這樣的流程要維持不太容易。除了剛剛提到的各自還有專案進度要做，在這個流程里我們并沒有指定是哪位設計師與工程師要負責什么元件或模組，靠的是自發(fā)性與熱情。

當專案一忙起來，建置的速度就會延宕 ; 再來是前端技術(shù)日新月異，所使用的套件如果升級，免不了要再花時間調(diào)整。其他的缺點還有設計風格會被局限、建置后要花時間替換原本的元件等等。

所以擁有自己的Design system 是條不歸路，組織要有共識并且愿意持續(xù)投入人力才會走得長久。要有Design system 前，還是要先知道自己的需求以及想解決什么樣的問題，才討論需不需要建置自己的Design system。

開源前的準備

• 我的命名方式：
  元件命名→  
  只有元件群組名稱單字字首大寫：對應檔案里分類名稱的呈現(xiàn)
  使用空格：在不需出圖的情況下，覺得空格的顯示方式最干凈清楚
  使用縮寫：節(jié)省顯示空間

• Symbol命名→  
  全小寫并使用空格：個人習慣
  利用斜線做分類：主要順序為元件名稱/類別/大小或狀態(tài)
  組成Symbol的元件用_element做分類
  影響Symbol的視覺、狀態(tài)，用_style做分類

簡化一個例子：組成一個基本類型的Input 包含Label, Input box, Input box 的狀態(tài)以及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 命名調(diào)整

調(diào)整命名后是不是更清楚呢？由于連結(jié)性已經(jīng)建立，即便調(diào)整左邊Symbol layer 的命名，任何修改還是可以同步，也可以讓右邊Overrides 的顯示名稱更精簡，讓使用者一看就知道這個是控制哪個元件。

所以其實在命名這階段，可以依照團隊需求或是個人習慣來制定，沒有一定要遵守的規(guī)范。不過還是有些小提醒或曾經(jīng)踩雷的經(jīng)驗可以跟大家分享：

• 不要用太具體的名稱命名

  
  例如不要用主色命名元件，因為主色會因不同專案而有所改變。
  舉例：如果是主要按鈕的話，取名叫Primary btn會比Blue btn適合。原因是若這份Design guideline使用在不同專案上時，當使用的主色有改變，元件也不需重新調(diào)整命名，修改彈性較大。

   

• 不要用在哪個裝置上使用來命名

  例如Desktop modal/ Tablet modal。因為會有使用在其他地方的可能，可以改用大小來命名，例如Default modal/ Small modal。

• 盡量不要修改Symbol folder名稱
  如果改到Symbol的名稱，也就是左邊Symbol folder的名稱，目前Sketch不會自動同步更新。當你改了Symbol folder名稱后，要檢查這個Symbol是不是其他Symbol的子項目、或是這個Symbol有沒有使用在任何地方，如果有的話要一并修改命名，命名才不會錯亂。

• 善用符號標示從屬關(guān)系

• Overrides中有的Layer是從屬關(guān)系，例如當你關(guān)閉input/_element/input box時，它的子項目：input box text與input/_style/state/normal也會消失，所以命名時可以在子項目名稱前加個符號（按下Control+Command+Space可以叫出Emoji）示意它是某個Symbol的子項目，當使用者要調(diào)整某個Symbol狀態(tài)時也會更加直覺、方便。

  3. 更加彈性化的元件設定

我們還可以利用Sketch的Resizing或Sketch plugin來做到更彈性的元件。

4. UI Demo Page 呈現(xiàn)

目前我們是用React storybook這個套件來呈現(xiàn)MCS Lite UI，它可以邊開發(fā)邊看到即時的UI呈現(xiàn)。如果有時間和人力的話，設計師也可以設計這個頁面。

  初次開源

MCS Lite 是MediaTek Cloud Sandbox (MCS) 的離線版本，適合使用在固定網(wǎng)域范圍的場景，例如學校電腦教室的教學場景等等。您可以安裝MCS Lite 在自己的電腦中，輕松快速地建置自己的私有云，不需再受到網(wǎng)路環(huán)境的限制。除了電腦版之外也支援Mobile Website。

后記

雖然我們解決了跨專案共用元件的使用問題，但由于時程、人力上的因素，在前期我們并沒有辦法針對Design system的理念、視覺特色做完整的發(fā)想與提案，只能依據(jù)現(xiàn)有的風格作延伸，這是我覺得比較可惜的地方。

不過我很享受這個過程，看了許多分享的文章不如自己卷起衣袖實際操作一次，確實從中得到許多寶貴的經(jīng)驗。
 
至于這份設計檔在Symbol與Resizing化后，是否可以順利運用在不同專案上并加快設計的速度，我想，又是下一次可以跟大家分享的題目了:D