寫給設計師:如何與工程師一起工作

評論
評論

large_1236029063
Julie Zhuo 與 Facebook 平台團隊成員(照片來源:Niall Kennedy

本文譯自 Facebook 產品設計總監 Julie Zhuo 發表於 Medium 的 〈 How to Work with Engineers 〉,是接續 〈 寫給產品經理與工程師:如何與設計師一起工作 〉 與 〈 寫給設計師:如何與產品經理一起工作 〉 的系列文章第三篇,也是最後一篇,談的是設計師該如何與工程師合作。(如果您不是設計師,而是負責往網站或 app 的內容,可參考這篇 〈 負責產品內容的人該怎麼與開發者合作? 〉)

多年前,我曾當過產品經理,然後是工程師,過去七年從事的是設計工作。每天我都跟擔任這些角色的人一起工作,每一天,我對產品開發背後的責任、挑戰和藝術都有新的體會。工程師是團隊的魔術師,他們拿到開發計畫、圖像素材後,只需輕輕舞動手指,Voila(看哪)!產品就動起來了。身為一個設計師,妳要如何跟上他們精明、喜好自嘲卻又按部就班的做事節奏呢?請繼續讀下去。

工程師就是那個將點子化為現實的人

工程師可以讓好的提案變成真的,永遠、永遠不要忘記這件事。不管妳的公司有 5 個、500 個還是 5000 個工程師,工程師都不是一種「資源」。他們是打下基礎、讓產品動起來的守護者。他們使產品得以運作,而且運作起來速度飛快;他們使產品堅固、耐用、可靠,還能讓產品規模化,使數以億計的人受益。

我說這些的意思是:工程師超厲害!

這表示……

想讓神奇的事發生?妳只需要說服一、兩個工程師

這是真的。許多傳奇性的產品故事都是這樣開始的:幾個朋友、一個週末、幾罐啤酒、一起「駭」一下,產品經理和主管加入都是之後的事。他們會從基本的東西開始——一個想法、一個設計、一個實作。這就是為什麼公司要付錢來換取與工程師之間的緊密聯繫。

或是,想像一下這個情境:妳發現產品有一個小小的部分令人很不舒服,真的很受不了的那種。妳覺得那個設計根本就不對。妳該怎麼辦?

  1. 下次團隊開會時提出來,讓負責安排任務優先順序的人放入清單,留給之後某個新進工程師「練習一下」以適應環境。
  2. 緊盯著某個工程師,走到她的桌邊,問她是不是可以花個五分鐘處理這個問題。看著她交出成果(也許必須用 80 年代知名樂團設計一件 T-shirt 之類的作為交換,反正妳對 Illustrator 很在行)。

猜猜看哪個選項可以最快解決問題?

這樣說吧……

如果合作的工程師也欣賞設計的價值,那麼事情就容易多了

當妳所合作的工程師,不必問妳每一項細節也知道該如何填補模擬畫面的不足之處,即便妳忘了在模擬畫面標出網頁邊界距離是幾個像素,她自己也會打開 Photoshop 測量——這是多麼美妙的事。特別是她還能給出一些讓設計變得更好的意見,這簡直不可思議。更驚人的是,這樣的工程師完成第一個版本後,妳會幾乎分辨不出她做的東西跟妳給的模擬畫面有何區別,一切的細節是那麼的精準到位。

要怎麼樣才能跟這種等級的工程合作呢?Well,妳可以雇用他們。如果可以的話那妳真的很幸運,因為 UI 設計導向的工程師可是大家搶著要。

編按:我們曾經在 〈進化或是被淘汰——iOS app 設計師的暑假作業〉簡單介紹過的 Loren Brichter 就是這樣的一位工程師,幾個月前他也加入了 Facebook 的團隊。

或是妳可以協助合作的每一位工程師學會欣賞好設計。該怎麼做?別只是把模擬畫面丟給工程師——好好地跟他們解釋妳的設計。與他們分享妳的價值,告訴他們為什麼妳的設計提案值得被開發出來。協助他們學習如何判斷實作出來的成品與妳的設計是否相符。當妳說某個東西看起來不好的時候,告訴工程師妳是怎麼想的。

建立關係很重要。人們價值觀與優先順序的移轉都建立在與他人的對話之上。這很老派,但用來做事非常有效。(關於這點,推薦大家閱讀紐約客 〈Slow Ideas〉 一文)

很多工程師或許不注重設計上的細節,但是他們大部分都很在乎使用者體驗,而且會想要把它變得更好。我不是說每一個設計師都很享受設計細節的工作,但工程師那份為了讓產品變得更好的心,有助於我們對他們解釋設計背後的理念。

因為工程師越是喜歡設計,他們越能夠理解背後的思維,看見設計的價值,進而讓設計越快完成實作,而且還會做得更好。

儘早了解工程上的限制,也為自己節省時間

身為設計師,很容易栽進「如果」的世界。如果我們可以讀懂妳的心思,明白妳想要、想看的是什麼,並且呈現給妳呢?如果你點了這個按鈕之後畫面就爆出一陣火光的特效呢?

如果你沒有及早搞懂技術或時間上的限制,那就別為了根本不可能實現的設計費心。(就算這是個值得一試的設計也一樣,如果你真的明白它的限制,就會知道這有多困難。)最糟的情況是妳投注大量時間和心血去完善設計,倒頭來卻發現根本不可行。好的設計師已經夠少了,要解決的大問題又那麼多,我們最不需要的就是這類沒效率的事。

所以下次如果有什麼好點子冒出來,但妳心中對於是否可行卻感到疑慮重重時,別猜,直接問工程師。

另一邊也一樣……

省下工程師的時間;隨時讓他們知道最終設計長什麼樣子

如果妳要工程師去實作一項設計,但是在看見成品之前自己也不太確定設計可以運作得多好,那麼請妳一定要讓工程師知道很有可能東西還會再修改。對他們而言沒什麼比熬夜趕工後卻拿到一張寫著「哎呀,整個設計已經改囉」的便條更困擾,這下子他們只得把自己全心投入、幾乎已是產品水準的程式碼給丟掉。

當然,沒有哪個工程師不曾把程式碼砍掉重練的。這就是工作的一部分,設計也是。好的工程師知道產品開發過程會是一團亂,東西做出來之前我們不會知道是否行得通。事情會變來變去,設計會改來改去。但是決定出哪些部分仍須繼續探索、哪些部分必須就此定下來,可以幫工程師理出程式碼的架構——到底要趕快寫出來呢,還是寫得彈性一點,之後再行修改。

確保工程師可以把東西做出來的最佳辦法,就是極度密切地合作

要像「東西完成的時候妳就坐在他們旁邊」那樣密切。我不知道該怎麼說才不會顯得過度強調:確保大家進度一致最容易的辦法,就是大家在同一個空間工作。如此一來,問題浮現、被解決的速度會快很多。

最終產品完成後要是得不到大家的愛,批評、責難便很容易紛沓而至。「喔,我的模擬畫面好極了,但工程師做得不對。」這是有害的想法。妳,設計師,擁有的是要對使用者發表的產品,不是妳電腦裡的 Photoshop 模擬畫面。如果有什麼地方做得不對,妳怎不有所行動?妳怎麼不請工程師完工後為妳展示一下,好讓你們審視細節?為什麼在實作的過程中妳不問工程師對設計有沒有疑問?為什麼妳看到 bug 後沒有立即開票請工程師處理?

對,去擁有它。

工程師最在乎的,是設計要完整

很有趣,人們形容設計師是「細節導向」,但事實上大部分他們給的設計規格會遺漏很多使用上可能遭遇的狀況,最後靠著必須將所有情形都實作的工程師去把他們找出來。

想成為工程師心中的設計英雄嗎?請確定妳的設計解決方案是完整的、已考量所有極端情形,像是:

1. 國際化:妳的設計在其他語言下看起來如何?有注意到德文那些很長的字對排版所造成的威脅嗎?
2. 錯誤狀態:網路突然中斷的話會發生什麼事?如果資料庫當掉了呢?或是其他類似的情況。
3. 極端的使用者:使用者如果沒有活動或資訊,讓這一頁空白的話怎麼辦?或是他有太多活動記錄或資訊怎麼辦?
4. 轉換:到底 A 畫面轉換到 B 畫面的具體方式是?好的工具或許能幫上忙,請看 〈 How to Survive in Design (and in a Zombie Apocalypse). 〉。

設計上述這些狀況不僅能在全面檢視過妳的設計後建立起信心,還有助於工程師規劃整個系統的架構,對於開發時程給予適當的評估。更不用說完整的設計還可以避免最後一分鐘才倉徨拼湊出一堆空白的爛東西——只因沒人發覺,此時再來補救也為時已晚。

請當個乖寶寶。確定妳的設計是完整的。別只為理想的使用情形做設計,踏出那個滿是模擬畫面的太虛幻境。就像每個工程師都知道的,只有把產品做出來才算數。

這是系列文章的第三篇,有興趣的讀者可以參考 〈寫給產品經理與工程師:如何與設計師一起工作〉 和 〈寫給設計師:如何與產品經理一起工作〉 。

相關文章

【硬塞科技字典】什麼是 5G?

第五代移動通信系統(5th generation mobile networks)就是5G,是一個研發中的通訊方式,跟4G 比起來,除了會大幅網速的提升外,也會與物聯網互相配合,能夠使物聯網更加快速的運行,資料能夠更快、方便的傳送。

預設如何統治世界?改變習慣,從設計自己的「預設值」開始

我們對太多的東西感到習以為常,並沒有意識到預設值對我們行為的影響。這篇文章告訴我們設計的力量,也提醒我們,改變行為和習慣要從調整預設值開始。

專訪 104 楊基寬董事長:我們正掀起一場「不需履歷表」的人資革命

「任何經營者都應該對人才隨時感到焦慮,如果不夠焦慮,那很難期望經營者有更好的未來。」

評論