UI 設計師與前端工程師的協作

本篇文章著重分享過去與網頁前端工程師協作的經驗,從經驗中延伸出比較心法的概念。

協作,就是理解對方在做些什麼,然後互相幫助以發揮最大的效用。
當客人走進早餐店跟老闆點了一份黑胡椒鐵板麵外加一杯大杯冰的黑咖啡,老闆回頭跟你說道:「黑麵、大冰咖。」
第一次聽到這些詞彙時你一定充滿問號,還好你是老練的店員,這點難不倒你;你開始沖泡咖啡,其他人將麵放上鐵板,擠上黑胡椒醬。

協作的基礎:共同的符號語言

剛剛看到的是早餐店的協作過程,你可以看到早餐店員會不斷的溝通,用簡易的詞彙代表較長的商品名稱並加強記憶。
透過簡短的詞彙傳遞訊息,早餐店得以快速地出餐。

我認為協作的基礎就是共同的符號語言,這裡的符號語言除了是講話、話語上的詞彙,更強調地是一個有規劃的、視覺上、文字上,建構在團隊成員共同認知上的語言系統。早餐店的老闆下達製作餐點的訊息,如果店員不知道黑麵是什麼、冰咖是什麼,那麼餐點就不會順利完成。

因此店員一定要知道黑麵的意義、冰咖的意義,當雙方都知道「黑麵」這個(名詞)符號所代表的是黑胡椒鐵板麵時,真正的協作才會開始。

與工程師協作也是如此,最基本,設計師需要知道一些特定的名詞,與工程師溝通起來才不會像第一次聽到「黑麵」的早餐店員充滿問號。

舉例來說,在開發網站時…

設計師:「我覺得這個彈跳出來的文字需要更搶眼更大一點。」
工程師:「你是說這個方框嗎?還是上方的提示訊息?」

當頁面上有其他類似彈跳出來行爲的元件時,這段對話完全沒有任何效用,因為溝通被阻斷了。

換個情境,

設計師:「我覺得這個 Modal 上的大標題需要更搶眼更大一點。」
工程師:「你說送出按鈕點擊後出現的 Modal 嗎?」
設計師:「對!就是這個。」
工程師:「好,我改一下。」

工程師成功地知道要調整哪一部分的文字,著手修改囉。


協作的進階:相同的知識基礎

擁有共同的符號語言還不夠,因為那些只是協作的表層。
協作用意在於緊密配合,互相補足發揮比單獨作業更大產能的力量,這就要仰賴團隊中成員的共同知識基礎。

協作的過程,討論是無可避免的:

  • 如何將這個介面實作地更好。
  • 如何調整按鈕位置,套用在不同的螢幕尺寸上。
  • 如何實作按鈕點擊後的轉場動畫。

這些討論都仰賴雙方有一定程度的知識基礎。

再舉例來說,
如果設計師不知道基礎的網頁排版邏輯與網頁上 positioning,設計出來的東西可能就會讓前端工程師非常頭痛。


實戰:UI 設計師如何做好準備協作

學習 HTML/ CSS

HTML/ CSS 不是程式語言,他們算是一種標籤,告訴電腦該如何渲染、排列出視覺與元件,但因為是給電腦看的標籤,所以還是保有部份的程式語言邏輯,設計師當作程式語言的入門。

但網頁 UI 設計師為何要學 HTML/CSS 呢?
如果平面設計師的畫布是紙張,那麼網頁設計師的畫布就是瀏覽器了。平面設計師除了設計外,更要知道紙張的特性、限制與墨水的特性,才能設計出完美的作品。
網頁設計師要熟知瀏覽器的特性與限制,才能做出好的網頁設計。

要了解印刷的最快方法,跑印刷廠與師傅一起討論,一起弄髒雙手。
HTML/CSS 最快的方法,在電腦上寫寫看,弄髒你的雙手吧。

和平面設計最大的不同,寫網頁你可以:

  • 重複修改、反覆地寫,畫布會快速反應結果
  • 成本低廉(不需要紙張與印刷費用),只需要一台電腦
  • 老師眾多,網路上資源龐大

熟知 Human Interface Guideline, Google Material Design

前面說到,協作的基礎是共同的符號語言。

Human Interface Guideline 就像是蘋果創造的語言系統,將 iOS 的元件都定義的非常清楚,了解名稱與使用情境後更能與工程師溝通。
而 Material Design 則是 Google 創造的語言系統,對於樣式、Component 也有明確的命名與定義。

了解這兩大 Guideline 就好像會了強勢的語言,和工程師至少在溝通上不會有詞彙上的模糊地帶,造成協作上的困難。

學習開發上會使用到的工具

在比較小的團隊的實戰上設計師也會參與開發,所以設計師也需要知道一些基本的開發工具:

  • 版本控管工具: Git / Github
    一開始是學習 Git,但我還是比較習慣使用有介面的 Github app,畢竟 Git 需要使用終端機操作。
    版本控管在開發上非常重要,有好的版本控管機制就可以避免掉「無法挽回」的錯誤。
  • 建立開發環境,學會使用開發模式
    在前一個團隊中使用的是 Ruby On Rails 框架開發,因此開發時會使用開發模式修改網站上的視覺。

學習程式語言

相信這個主題已經被討論很多次,究竟設計師要不要學習寫程式呢?
我認為要看目的是什麼,是想自己寫個程式玩玩,還是純粹為了配合開發方便呢?

工作的跨領域性質:(無可避免的會遇到)
站在設計師的角度,設計師面對來自不同領域的客戶與人,不同的業主不同的需求,每一次為客戶做設計都是學習;學程式語言也不例外,了解程式語言幫助設計師從另一個面向切入問題,給設計師更多觀點看事情。

目的導向:(為了加速開發)
因為使用到 React.js,所以為了修改畫面而要習慣 React 的 view 結構,雖然我的 JavaScripts 完全不行,但學習了解程式語言的結構是我能在短時間內做到的。
就好像為了製造印章風格的 logo,設計師會在設計之前瘋狂地蒐集瀏覽各式各樣的印章樣式:從印章怎麼刻、分成陰刻與陽刻等等,為的就是要了解印章背後的原理。

我認為設計師有價值的地方在於觀察、理解、重組與整合,最後調配各種要素以達到設計的目的。
套用在我在開發團隊的行為上,從觀察與理解開始(當然一定有工程師先帶一遍!),先了解這個 function 包著什麼,看懂了,知道怎麼修改或應用以達到「修改畫面」的目的。

習得技能導向:(增加自己技能樹上的技能)
學習程式語言,因為覺得多一個能力就會多一份保障,每個人都有這個想法。唯一要考量的就是你願意投資多少時間進去一個新的領域?

相信大家都玩過線上遊戲,舉個例子來說時間就是遊戲裡面的屬性點數,你分配多一點在智力(INT),就相對的會少一些在體質(VIT)、力量(STR)等其他屬性上;要怎麼分配就看你要成為什麼樣的角色。
每個人的時間不盡相同,有的人睡得少時間多,有的人天資聰穎一點就通所以花的時間少,但時間這個點數都是一定有限的資源,就看你要如何分配時間在精進能力上。

設計師要學習程式語言嗎?
沒有必須要學習,但切記學習程式語言的目的為何。


總結協作

如果說 UI 設計師與前端工程師的能力值是一個長軸,那麼 UI 設計師與前端工程師必定是有部份重疊的。

這個重疊不是互相搶工作,而是互相補足;前端工程師了解設計師設計背後的原因、設計上每一個 pixel 的細節,設計師了解網頁或應用程式元件的名稱、網頁結構的原理,減少兩個領域之間資訊的模糊地帶就可以讓協作的過程更順利。

Like what you read? Give Sheng Pan a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.