如何著手開始Design Guideline?(二)

WenChien Lee
Feb 23, 2021

--

距離第一篇 Design guideline 文章,一轉眼就快要三年…(真是歲月不饒人)在這三年裡,新的經驗也讓我累積不少新想法,現在回頭看上一篇分享,總覺得還不夠明確,雖然每天都有新的追蹤、新的拍手(流淚感謝)...但總一直希望能夠分享更深一些,讓孤立無援(?)的設計師能有更明確的方向。也因此,誕生了這篇文章!
Guideline 顧名思義,需要一定的可遵從性 — created by rawpixel.com

原子設計

原子設計在業界早已不是新聞,為什麼製作一套 Design guideline 之前我們要先來聊聊他呢?

既然他已不是新聞,相信你能在網路上輕易找到相關文章,我就不在這邊用大篇幅來闡述!

同一個基礎元件,很可能拼湊出各種不同的新元件,一旦基礎元件更動,全站都會一起更新。

使用原子設計的好處,在於後續便利且快速的維運,以及更能被系統化的設計規範。並且,這也非常符合在 Sketch 中廣為人知的巢狀式結構設計方式!

著手第一步

|如何選擇工具?

除了 Sketch,市面上的相似軟體還有非常多,也各自有自己的優勢與特點,我持相同建議 — 你可以選擇你熟悉順手的工具來使用!

不過在我們進入細部設計之前,我想還是需要先放下設計的執念…如果你希望讓你的設計在後續執行中更順遂的話~

我自己目前是使用 Axure 來整理元件,主要目的並不是「元件的外貌」,例如顏色、框線、陰影…;而是「元件的功能」,例如按鈕、表單元件、選單…

相較於 Sketch,Axure 的好處是快速產生一個網址供團隊討論,並且在 Axure 中已經有許多經常被使用的元件供參考與選擇,要記得在這個階段裡重點是溝通而不是著手開始美化

|往同一個目標邁進吧!

當團隊有共同的目標,就能分工合作一起完成專案,朝同一個方向邁進,無論等在終點的是什麼結果。 — created by vectorjuice

與前篇相同的是,我現在仍認為制定規範不會是一個人的事,除非…所有成敗都由你一人扛下,你團隊也沒其他人、你就是校長兼撞鐘,那麼我相信你做什麼都會順順的,完全不用擔心任何溝通問題!(這樣你制定規範是要給自己看的嗎 XD?)

出社會一段時間後大概會發現,其實沒有誰能改變世界(不要跟我說Jobs,沒有團隊,他自己也無法生出「產品」),所以那不會是現階段的使命。

在職場中,你的Users在專案上線前都會是你團隊裡的其他人、你主管或你老闆。

你可能會說「不!我們可是有做使用者研究的呢!」恩…要做這件事情前的資源也是來自你老闆的首肯對吧?

廢話說了一堆,我想告訴你的是,「能夠好好溝通」才是重點,只要能夠達成這樣的重點,即便是白紙加鉛筆,也是非常好的媒介!

鉛筆與白紙也是促成溝通的好工具!- created by terdpongvector

那麼我們為什麼要讓團隊達成共識呢?

因為在執行前,你手上的專案至少是必須獲得團隊認同的,若團隊裡的每個人對產品的想像與期待都有落差,那麼就會像多頭馬車一樣,怎樣也無法抵達短程目標。

因此制定規範前的元件討論是非常重要的!若能取得團隊共識,後續在執行的時候,就能拿這套規範出來討論,大家一起決定產品的下一步該怎麼走,這也是促進團隊向心力的一種方式!

|工程可行性

在我的經驗裡,很多時候工程都到很晚期才加入,甚至PM都已經排好上線時程,產品都已經要進入開發,才匆匆忙忙遞出一套讓工程師一頭霧水的Guideline,這實在很可惜!

不只可惜,還容易造成紛爭,前面說過了吧?團隊要「有共識」才能好好前進,若你的元件應用實在有違開發邏輯,或是太多跳脫原子設計的「客製化零件」,那又怎麼能讓工程師們信服呢?

所以我會建議,在討論元件功能時就找前端工程師一起加入,工程師畢竟是開發者,他們會有更多維運考量,在企劃與設計的盲點中給出一條新的指引!

|別急著美化

我明白,看著那些看起來可能有點歪、有點醜、有點傷眼睛的框線元件,設計師手會很癢,好想加個圓角、降個明度…

請忍住!!

這個時期請盡可能把心力都放在元件功能著墨上,且難得召集了團隊的所有人一起來討論,應該不希望大家在不理解脈絡及設計思維的情況下對設計稿品頭論足吧?盡可能列出可能需要的元件,讓後續工作更順暢,才是這個階段的目標!

好不容易召集了大家,沒有把時間花在刀口上是很可惜的!- created by pch.vector

那麼,開始制定讓產品變美的規範吧!

一份好的規範會有足夠的說明與清楚的應用方式,想像你有一個路痴朋友要到某個你非常熟悉的地點自由行,但你不能陪同的情況下…你會怎麼引導他呢?

你可能會幫他註記好,在第幾個紅綠燈右轉、轉角處有一間誠品書局、沿著學校外牆直走的右手邊有最好吃的古早味料理、如果想到某個景點可以從哪裡搭幾號公車,在哪一站下車…

想像這是一份交接文件,即使你並沒有真的要離職。

如何指引其他夥伴能夠依據你的資訊做出相去不遠的畫面,是這個階段的首要目標,不要預想「其他人會協助說明」、「有問題再來問我」…你很有可能在他緊急需要你的時候正好不在位子上,或者當他每過三分鐘就打斷你工作思緒,你會不會想一整天都不在辦公室裡?(笑)

好好撰寫這份文件,有助於讓你有更多時間去完成其他重要的事!

|規範應該包含什麼資訊呢?

除了「樣式」之外,Design guideline也應該定義出使用情境,小到每條框線的顏色應用、大到整個版面的佈局間距,能夠寫得越細,其他夥伴就越不會做出有落差的畫面。

間距

若你的工程師有使用到SCSS,他很可能使用變數來統一控制間距!例如在 Material UI 中擬定最小的基本單位。

這樣的好處是,當工程師在執行時可以設定間距的基本單位,後續單位就以這個基數去乘上倍數,當設計師制定好一套模式時,未來若要縮小或放大間距,工程師就能夠以非常短的時間完成這個任務(只要改基數就可以)。

即便工程師並未使用這個方式,良好的間距系統對設計也會較易於維護,而不會發生當兩個元件放在一起,卻一高一低,完全無法對齊的窘境。(尤其設計師們很在乎那1px對嗎?)

字級表

⚠ A覺得那樣字太大、B覺得那樣字太小,兩人做出來的設計稿總是無法對焦?⚠ 兩份設計稿送到工程師手上,一樣都標明<h1>,font-size卻不一樣大?⚠ 有時候寫rem、有時候寫em、有些又用px,什麼才是應該遵守的規律呢?

…如果你的字級表定義得夠明確,以上這些問題就很難產生!

一份好的字級表,幫助設計者在製作設計稿時,明確知道當下情境應該使用哪一種字級,而不僅僅是把所有現有用到的字級都排上去,卻沒有說明該在什麼時候使用!

各種元件的變化型

如果你的網站是RWD,在電腦上和手機上需求往往不全然相同,因為在不同裝置上的使用經驗和體驗需求是不可能一樣的,因此你的元件會怎麼變化,這點也必須詳細清楚的寫在文件裡!

即便你的網站不是RWD,應該也會有不同寬高和大小,甚至根據頁面需求有不同色彩的應用,來保持彈性,基本上遵循「只要有可能長得不一樣,就全部列清楚」的核心宗旨,盡可能將元件應用情境補齊。

狀態外觀

只要是可以互動的元件,一定都會需要有適當的反饋機制,讓使用者能正確掌握現況。

因此諸如按鈕、表單、頁籤、控制器、選單…等,都必須呈現及說明在不同狀態下的外觀,包含:一般狀態、錯誤狀態、不可點擊狀態、點擊狀態(focus)…,這部分在剛開始著手規劃時,有可能會不小心遺漏,建議可以直接找工程師一起討論,就能讓文件更完備!

版型

除了細節的小元件之外,設計規範也需要訂製出幾種保有彈性的版型,才不會導致大家做出來的版型都不同,無法被共用,那就失去了design guideline的意義了。(如果遇到企劃書還不是很明確的狀況,也有可能暫時無法執行這塊,不過都已經要開始制定規範了,合理狀況下應該是有一定的文件量才是。)

色票應用表

除了網站的主輔色之外,色票表應該包含整個網站所使用的每一種顏色及他們被應用的情境!如果是無彩色的應用,也應該明確指出該在什麼時候用上什麼樣的灰階。

📍灰色應用小技巧

部分設計師為了讓灰色系列能夠被應用得更有彈性,並不會直接使用無彩色票,而會以純黑(#000000)加上不透明度來做調整,這樣的好處是,當主體色系改變時,就能讓畫面上的灰即時配合調整,不會死守某一種灰階。

以不透明度來作為灰色應用的彈性

參考資源

如果還是不知道該如何下手比較好,除了可以參考別人的 guideline 之外,也可以看看更多廣被使用的元件庫/框架,當你看過越來越多的元件庫,心裡就會有個底,畫面上經常出現和被使用的元件不會差得太多,掌握這些基本元件之後,再依照產品的屬性和需求,拼出一些讓你的產品更好用的元件吧!

Semantic UI

Bootstrap

Ant Design

Material UI

後記

相比三年前的文章,我想我應該有給出更多具體建議,但隨著經驗慢慢增加,或許未來還是有機會分享更多我現在還沒接觸到的面向!

而規範也是一樣的,不太可能一蹴可及,只能夠過各種方式,例如:團隊討論、技術更新與修正、產品迭代…等,來做逐步優化,規範變動是正常的,只要不是翻盤大改,都還在合理範圍內!

但也不是說三天一小改、五天一大改…這樣可能會搞死設計師和工程師團隊(汗),規範的制定是彈性但嚴謹的,充分的討論之後,大家一起遵守這套邏輯,只在必要時做修改更動,才是一個比較好的維護方式!

終於寫完這篇分享文!不知不覺又不小心熬夜了...
如果這篇文章有幫到你,歡迎幫我拍拍手獎勵一下~給我一些鼓勵和動力!
如果還有任何問題,都很歡迎留言提出討論,畢竟我也是在學習的路上,大家一起交流才會一起成長進步!

--

--

WenChien Lee
WenChien Lee

Written by WenChien Lee

一個喜歡分享的 UIUX 設計師!這裡分享各種講座與工作坊心得、工具教學、推薦書單、職涯觀點和生活體驗!