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

Guideline的溝通對象

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

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

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

因此,這份文件在撰寫時必需要能夠擴充、複用、迭代,而在程式的實作上,也要能夠輔助工程師建立程式端的 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)…等資訊。

這邊參考 Material Design 的 Dialog 使用方式

Layout (佈局)

Component 在畫面的位置(Position)、尺寸(Dimension)。

說明 Component 在畫面的位置、尺寸。

Anatomy (解構)

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

列出 Component 的結構,並做好命名

State & Spec (狀態與規格)

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

詳細說明Compoenent的規格,與相關參數。

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,需要長期的合作經驗與討論,經驗較少的設計師,通常在與工程師溝通的環節是非常簿弱的,經常答非所問,解決方式是多與工程師討論,或是閱讀一些前端框架的規範,像是:bootstrapant design …等等,會讓你更快的理解工程端的實作方式。

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

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

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

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

Posted by:Rei

介面設計師

留言

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s