介面設計規範（UI Design Guideline）的撰寫方式

關於介面設設計規範（UI Design Guideline；以下通稱 Guideline）的撰寫方式，其實目前並沒有一致的規則與邏輯，每一間公司或產品可能撰寫的方式都會不一樣，而且 Guideline 不應該只是單純的「文件標識」，作為文件，最重要的就是用來紀錄與溝通，而Guideline的溝通對象為何？通常就是工程師、設計師或PM/UX，所以在撰寫這份文件時，要確保閱讀者能夠理解，並持續的運用到產品的維護與開發上。

Guideline的溝通對象

設計師
對於設計師來說，這份文件必需要能夠共同維護與編輯，因此要有一致的撰寫邏輯。
PM / UX
用來與PM溝通組件的使用方式與情境，後續 PM / UX 在規劃產品時也會比較有效率。
工程師
對工程師來說，文件必需能夠清楚的交待組件的使用方式、規格、相關的參數定義及相關資源（Asset）的取得方式。

建立 Guideline 並不是單純只是標識文件，標識這件事情，目前可以由軟體來處理，而文件的內容應該更清楚的說明 UI 組件（UI Compoenent；以下統稱 Component）的使用情境、狀態、規格，並建立一個可以持續迭代的標準，將 Guideline 帶到產品的開發流程，提高開發效率。這邊列舉出 Guideline 以下的幾個用途：

提供一致化的設計
避免組件重覆設計
建立可複用，可擴充、可迭代的 UI Component
作為與工程師交付文件一個標準

因此，這份文件在撰寫時必需要能夠擴充、複用、迭代，而在程式的實作上，也要能夠輔助工程師建立程式端的 Component。完整的文件與好的維護方式，才能夠加速並提高產品的開發效率。

Guideline 的撰寫邏輯

Guideline 的撰寫邏輯，可以參考原子設計（Atomic Design），原子設計的邏輯是由小而大去建立整個 UI系統，但 Guideline 的撰寫邏輯剛好相反，是由大到小，先看使用方式再看整體頁面的佈局，接著再詳細說明Component的細節與狀態，這樣的邏輯比較好讓閱讀者清楚的了解這個Component 的使用方式。

另外 Guideline 的最小單位，從原子設計來看，應該是 Molecules，也就是 Component，在 Figma 裡我們可以說是一組 Variants，其中包含了這個 Component 的不同狀態（State），而更小的Atoms，應該定義在Style裡，其中包含了：Color、Grid、Font、Spacing、Icons … 等等全域型的樣式元素，在寫 Guideline 的時候，建議可以將 Style 獨立管理。（之後會針對 Style 建立的方式寫一篇文章）。

UI Spec 在撰寫的結構，可以參考我所整理的架構，這邊的內容也是參考 Google Material Design，所整理出來的，這邊以建立 Modal（Dialog） Component 來進行說明：

Usage （使用方式）

說明組件使用的一些原則（Principle）、類型（Type）、如何使用（How to Use）、何時使用（When to Use）、在那裡使用（Where to Use）…等資訊。

Layout （佈局）

Component 在畫面的位置（Position）、尺寸（Dimension）。

Anatomy （解構）

組件的組成元素，從原子設計的角度來看，是從 Organizms 去拆解使用到的 Molecules

State & Spec （狀態與規格）

狀態與規格會放在一起的原是，是因為我們需要在不同的狀態下，顯示 Compoenent 的規格，需要包含物件狀態，對應到的詳細參數。從原子設計角度來看，指的就是 Molecules。

Interaction （互動方式）

簡易的描述互動的行為，如果軟體允許，也可以用動畫的方式呈現交互效果。

在 Material Design 的文件裡，會用動畫的方式顯示互動方式。亦可用文字簡單表達預期達成的效果。

Asset（資源）

如果有切圖的話，將切圖整理在該 Component 的文件裡，日後方便維護。

介面設計師最常參考的Guideline

介面設計最常看的參考的 Guideline 應該就是 Google 的 Material Design 或是 Apple 的 iOS Human Interface Guidelines（HIG）；這兩份文件的撰寫方式比較不同，在 Material Design 提供的文件裡，對於Component 的使用及其規格都有做詳細的定義，但 HIG 則都是以大原則的方式來做定義，如果要撰寫公司產品的 Guideline，建議以 Material Design 的撰寫方式來進行參考，列大原則的方式可能比較難在一般產品運行，當然或許 Apple 公司有自己的開發規範，但這個規範可能也只存在於他們公司內部，外界無法取得。

結論

撰寫 Guideline 最大的目的就是「溝通」，如果無法達成溝通的目的，那這份文件基本上就是無效的，許多設計師，喜歡把文件整理的美美的，但內容卻不知所云，好像把所有的狀態列完就沒事了，但事實是，要寫出一份讓工程師看的懂的 Guideline，需要長期的合作經驗與討論，經驗較少的設計師，通常在與工程師溝通的環節是非常簿弱的，經常答非所問，解決方式是多與工程師討論，或是閱讀一些前端框架的規範，像是：bootstrap、ant design …等等，會讓你更快的理解工程端的實作方式。

最後，再次強調 Guideline 不是一次性的文件，需要持續的迭代與維護，它跟產品一樣，需要花時間去了解閱讀者的需求，不管是Material Design 或是 iOS Human Interface Guidelines 至今也都是持續在更新的。

這篇文章先提出一個簡易的撰寫架構，但並非照本宣科，還是要依情況來進行調整；另外，還需衡量自己所處的公司需求，像是接案型公司（乙方），或許就沒有維運產品的需求，只出 UI Spec 就可以完成開發，那就不需要額外再撰寫 Guideline，或者以將 Guideline 做為可以重覆使用的 Template（模版），來降低撰寫 Guideline 的時間成本，一切都以所處的公司與需求來調整做法，沒有一定怎麼做或怎麼寫會是最好的結論。

撰寫 Guideline 很花時間，必須仔細的去思考產品各項功能組件之間的細節，同時還要思考到組件的可實現性，這也是專精於介面設計的價值所在，所以當有人問介面設計師是在做什麼的，絕不是是什麼「出圖」可以說明的，我們的工作除了讓產品變的更好用，很大的價值是透過設計讓產品開發團隊變的更有效率！

有任何問題或更好的想法都歡迎給予意見討論。