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

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

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

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

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

  建立Common UI Library 流程

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

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

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

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

• 元件的名稱

• 視覺呈現(xiàn)

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

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

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

• 視覺呈現(xiàn)

• 功能與互動操作是否達(dá)到預(yù)期

• Code review

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

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

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

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

開源前的準(zhǔn)備

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

• Symbol命名→  
  全小寫并使用空格：個人習(xí)慣
  利用斜線做分類：主要順序為元件名稱/類別/大小或狀態(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 的顯示名稱更精簡，讓使用者一看就知道這個是控制哪個元件。

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

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

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

   

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

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

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

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

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

  3. 更加彈性化的元件設(shè)定

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

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

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

  初次開源

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

后記

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

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