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

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

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

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

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

  建立Common UI Library 流程

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

• 是否不同專案都會(huì)使用？

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

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

• 元件的名稱

• 視覺呈現(xiàn)

• 功能涵蓋范圍與互動(dòng)操作

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

實(shí)際操作后，工程師會(huì)Pull request 給團(tuán)隊(duì)做驗(yàn)收，驗(yàn)收項(xiàng)目包含：

• 視覺呈現(xiàn)

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

• Code review

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

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

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

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

開源前的準(zhǔn)備

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

• Symbol命名→  
  全小寫并使用空格：個(gè)人習(xí)慣
  利用斜線做分類：主要順序?yàn)樵Q/類別/大小或狀態(tài)
  組成Symbol的元件用_element做分類
  影響Symbol的視覺、狀態(tài)，用_style做分類

簡(jiǎn)化一個(gè)例子：組成一個(gè)基本類型的Input 包含Label, Input box, Input box 的狀態(tài)以及Input box 里的提示字和輸入文字。所以分類就會(huì)是：

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 的顯示名稱更精簡(jiǎn)，讓使用者一看就知道這個(gè)是控制哪個(gè)元件。

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

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

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

   

• 不要用在哪個(gè)裝置上使用來命名

  例如Desktop modal/ Tablet modal。因?yàn)闀?huì)有使用在其他地方的可能，可以改用大小來命名，例如Default modal/ Small modal。

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

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

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

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

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

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

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

  初次開源

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

后記

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

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