產品設計現場 EP3：設計師與工程師不應該是敵人，而是戰友！ — — 專訪設計師 Kat、Jill、Hanyu

正向看待彼此差異，聰明合作製造雙贏！

AAPD — As A Product Designer

Published in

AAPD — As A Product Designer

13 min readApr 13, 2023

前言

本文為 AAPD 創辦人 Simon 的 Podcast 節目《No Shortcuts — 沒有快捷鍵》的訪談重點摘要。

在上一季的節目中，《No Shortcuts — 沒有快捷鍵》採訪了許多業界資深的設計師，與大家一同窺探設計工作的真實面貌；而在全新一季的節目中，主軸將會聚焦在「設計師在職場中的真實情境與挑戰」上。我們希望透過邀請不同背景或經驗的來賓們，與我們進行一場深度的交流與對話，並一起探索產品設計職涯的可能性！

這一次，我們邀請到設計師 Kat、Jill、Hanyu 來跟我們聊聊與工程師合作開發產品時的想法與心得分享，包括「設計師與工程師合作注意事項有哪些」、「設計交付的重點與眉角」，以及「提升設計溝通技能的方法」。如果你目前也苦惱於不知道如何與工程師合作的話，千萬別錯過了這集！相信透過這次的分享，能夠帶給你許多意想不到的收穫。

本文架構
1. 來賓的背景來歷
2. 如何看待設計師與工程師之間的差異？
3. 設計交付的重點與眉角有哪些？
4. 如何提升設計溝通技能，讓合作更加順利？
5. Simon 總結
6. 相關連結

本集 Podcast 連結

本篇文章為重點摘要，想知道更多細節歡迎前往 Podcast 聽完整版：《No Shortcuts — 沒有快捷鍵》S2EP3 — 工程師和設計師的愛恨情仇：設計交付與協作上的各種眉角
收聽並訂閱我們的 Podcast 節目：《No Shortcuts — 沒有快捷鍵》

來賓的背景來歷

首先，我們先來介紹這次邀請到的三位來賓 — — Kat、Jill、Hanyu。

非設計本科的 Kat 在五年前開始自學設計，待過三年 Agency 和一年 Inhouse，目前的她在餐飲科技業擔任產品設計師，為幫助餐飲老闆們的營運而努力。對於 Kat 而言，她始終相信著要先能學會感知生活、感知人，才可能做出能夠解決問題且貼近人心的設計；因此隨著接觸設計越久，設計已經不再只是一個職業，反而更像是她的生活哲學。

擁有設計加上程式背景的 Jill，曾於 IBM 設計團隊擔任設計顧問協助客戶數位轉型，同時也有日商前端工程師及 Gogoro 前端實習經驗，現在的她在一間加密貨幣新創 WOO Network 擔任 UX 設計師；同時，她也深信著設計能幫助人們改善生活，因此除了提升金融服務的使用者體驗外，還曾在為臺灣而教（Teach for Taiwan）、無障礙網銀等專案貢獻所長，並舉辦多場設計分享及設計思考工作坊給在學學生。

有著社會學及文學背景的 Hanyu，過去為雜誌編輯、書籍設計師，曾參與使用者經驗研究設計與產品開發；後來跑去拍紀錄片，持續藝術創作與展覽發表。兩年前決定成為網頁設計師，過著設計師與藝術工作者的平行生活。對於 Hanyu 而言，儘管斜槓人生有時看似繞路，但是於不同領域工作的經驗，卻能夠協助她切換至不同視角去理解設計，過去所累積的專長也經常在無形之中幫助她完成設計工作。

如何看待設計師與工程師之間的差異？

在產品開發的過程中，時常會聽到發生在設計師與工程師之間的衝突故事。其實，設計師除了要在有限的資源中盡力了解不同利害關係人關注的點，進而發想解決方案及回應需求之外，也需要與工程師培養合作默契、共同協作，才能讓產品順利落地。

相信很多新手設計師會很好奇，設計師關注使用者的需求是否被解決，而工程師重視的是實作可行性，在創意與邏輯兩種如此不同的思維之間，要如何理解彼此，以及長期合作呢？關於這點，三位有經驗的設計師皆分享了自身的經驗與看法，接下來就來聽聽他們怎麼說的吧！

設計師和工程師不是對立面的關係，我們都是站在同一艘船上的人。— Kat

Kat 認為，大多時候設計師跟工程師的目標是一致的，兩者都是希望能做出好的產品，而溝通過程中會發生衝突，主要是因為雙方立場不同；因此，讓雙方了解彼此在工作執行上的考量點、避免情緒性的溝通，對 Kat 而言是非常重要的事。

說到這裡，Kat 分享到自己平時與工程師合作的流程，她說：「通常在專案正式啟動之前，工程師會先發起一個 Kickoff 會議，等到 RD 閱讀完設計文件、估時完畢、準備進入開發階段時，RD 會再發起 Design Review 會議，讓相關成員了解程式的設計架構，例如要開哪些欄位、什麼時候 Call 哪支 API、前後端以及 iOS 各需要處理哪些資料？同時也能讓設計師更了解程式邏輯。」

衝突的產生，是來自於對彼此工作的不理解。 — Jill

對於 Jill 而言，設計師與工程師之間會發生衝突，是來自於對彼此工作的不理解，而如果要避免衝突，最直接的方式就是了解彼此的工作流程。她提到，如果不花時間進行溝通的話，工程師可能不會知道改動設計背後的代價，不會知道設計不僅是調整畫面而已，還需要跟所有的利害關係人重新提案、討論，甚至是進行易用性測試。

同樣地，如果沒有溝通，設計師也不會知道工程師在面臨需求的改動時，除了調整網頁上的程式碼之外，在將新需求上線之前還需要經過一連串的繁瑣測試，確保開發品質。

我認為，提早跟工程師合作是很重要的。 — Hanyu

對於 Hanyu 而言，設計師跟工程師提早合作是必要而且重要的，因為如果工程師能夠在開發前期就參與設計團隊的討論，除了可以儘早理解商業目標，也可以做出更符合需求的成果。

Hanyu 分享了自身的例子。她提到公司是以開發 CMS 系統為主，裡頭有很多和「資料邏輯」相關的問題與需求，因此會需要在開發前期就交由工程師評估架構的合理性；但是合作模式的改變，也讓她與同事發現到，不同角色間如果能夠提早合作，不僅能透過前期會議更了解彼此的工作思維，還能降低後續的溝通成本，大幅提升整體開發的效率。

設計交付的重點與眉角有哪些？

設計交付是一件非常重要的事情，因為無論你的設計細節做得多麼完整，當你在設計交付時做得不夠完善，工程師便很難做出符合設計師心中的成果；因此，業界有著這麼一句玩笑話：「設計一時爽，開發火葬場」，那麼到底要如何避免這樣的狀況呢？設計交付又有哪些眉眉角角需要注意的呢？

設計文件是一個手段，目的是不管是誰，都能透過這份文件了解我們在做什麼，有這樣的心態後，我們才能去設計文件的結構和內容。 — Kat

對 Kat 而言，易讀的文件應該是由設計師、工程師雙方共同建立而成的。Kat分享到，自己平時在撰寫設計文件時，除了會標註基本的工程規格與邏輯，還會在關鍵的設計決策寫上脈絡及原因，讓工程師能更全面地了解為什麼要做出這樣的設計，避免在進行規格討論時，只以時間或工程成本為考量出發點，而忽視了使用價值和商業目標。

另外，她也會清楚標註「待確認」以及「已更新」的項目並整併到更新日誌（Changelog），讓工程師可以快速掌握設計的最新動態，避免以錯誤的規格下去開發。

當設計稿完成的時候，其實工作只完成了 50%。 — Jill

Jill 認為，當設計稿完成時，僅代表工作完成了一半，接下來才是全新的挑戰；因此，設計師必須將心力放在設計交付上，並盡可能將完整的設計細節傳遞給工程師，開發出符合設計稿需求的成品。

當聊到設計交付方式時，Jill 提到自己常使用原型（Prototype）進行設計交付，另外，她也發現到很多設計師在交付設計時會忽略「反向流程設計」的操作細節，像是在相同的頁面上，對於會員及非會員用戶而言，看到的畫面會有什麼樣的差異？關於這點，Jill 認為設計師應該要在設計文件上詳列不同的判斷條件，讓工程師清楚知道在不同條件下的流程有哪些差別。

盡量去設想每一種狀況，並將這些可能出現的情形清楚註記在設計稿當中，並提早跟工程師溝通。 — Hanyu

Hanyu 的日常工作以設計 CMS 系統的介面為主，但是因為每位客戶對於網站的使用需求、方法都不盡相同，因此在進行設計交付時需要考量的點也會有些不同，像是網站上線後的資料量是否足夠？若資料量不足的話應該要如何呈現？會不會有破版問題？當資料量不足時，要如何請工程師分別寫出不同的抓取邏輯的方式⋯⋯等。

最後，Hanyu 提到，她認為設計師的任務是盡量去設想每個可能發生的情形，並將這些可能出現的狀況清楚註記在設計稿中，以及儘早取得真實資料和工程討論合作細節。

如何提升設計溝通技能，讓合作更加順利？

在產品開發過程中，設計師跟工程師都是團隊中的重要角色，因此彼此是否能互相合作就成了一大關鍵，而這也是為什麼許多設計師在實際踏入職場後，就更積極培養良好的溝通能力。那麼，到底設計師與工程師合作上要注意哪些重點呢？以及有沒有哪些合作方式、溝通流程可以讓專案進行地更加順利呢？

多問、多了解工程師的語言、在意的點，確保之間的溝通順暢。— Kat

對 Kat 而言，要達成有效溝通的主要路徑是去了解對方熟悉的語言，像是設計師可以試著去觀察工程師在會議中時常提到的詞彙有哪些、從中找出他在意的點是什麼。

以 iCHEF 的雲端餐廳為例，因為它背後有非常多複雜的邏輯處理，例如在哪些時間點要串接哪一支 API、在什麼時間點要檢查哪些資料⋯⋯等細節；這時，如果設計師對工程實作稍微有概念的話，當前期設計進行時就可以特別留意這些地方，減少後續開發時來回的溝通成本。

在合作的過程中，不只要把需要改善的地方講出來，做得好的地方也要提出來，如同做設計般持續不斷地迭代！— Jill

Jill 建議，設計師平時可以多去了解工程師的工作內容及開發流程，包括了解產品目前使用到的套件有哪些、HTML 與 CSS 如何在網頁上運作等，因為加強對工程思維與技能的了解，除了能跟工程師溝通更順利之外，也能幫助設計師在進行設計時更快上手。

最後，Jill 提到「雙向互動跟反饋」對兩者的合作很重要，像是 Sprint 即將結束時就是很好的時機點；說到這裡，Jill 也特別強調這個階段不只要把需要改善的地方講出來，做得好的地方也要提出來，如同做設計般持續不斷地迭代！

創造「工程與設計的共學時間」，熟悉彼此的工作思維很重要。 — Hanyu

最後，Hanyu 也分享了兩個可以快速提升兩者之間合作效率的方式，包括：

回顧會議（Retrospective）
這是一種針對交付文件、任務排程和溝通的復盤。Hanyu 提到，在專案告一段落時，可以花一點時間回想過去在跟工程團隊合作的過程中有沒有可以進行優化的部分，透過這樣的方式可以更有意識地培養合作默契。
Hanyu 舉例自己常常會透過以下三個問題，來優化下一次的目標設定：
- 有什麼是對工程來說是多餘的資訊可以省略不做？
- 有什麼事做了對工程來說比較好，但這次沒做到的？
- 未來應該怎麼做會更好？
定期的共學時間
Hanyu 分享到，有時在負責一頁式網站的設計時，她會遇到一些實作上的問題，後來，她意識到如果自己能夠掌握 HTML 和 CSS 的部分，就能讓她與工程師之間的合作更加順利。
因此，Hanyu 後來找來工程師同事進行每週一次的「共學時間」，在這段時間裡，她會教工程師使用 Figma 設計工具，以及與設計師合作的方法；工程師則會帶著她看別人的設計稿，學習簡單的切版和 CSS、Bootstrap、Javascripts ⋯⋯等。透過「定期的共學時間」，讓原先有著不同邏輯思維的兩人，開始能夠站在不同角度重新審視產品。

如果有快捷鍵可以讓你快速達到某個目標，那會是什麼？

我想要「多重宇宙鍵」，因為我想知道在另一個宇宙中，設計師的可能性。 — Kat

Kat 表示：「因為最近我剛看了《媽的多重宇宙》這部電影（笑）。讓我想到了，現在很多的設計會很強調實作可行性，因為當產品落地之後，才能帶來商業價值；但是『推測設計』就是鼓勵設計師可以多運用想像力、幫助我們跳脫那些習以為常的現實框架。所以我想要有『多重宇宙鍵』，它可以把我傳送到另一個宇宙，我想知道在那個宇宙中，我會是誰？設計師可以扮演什麼樣的角色？說不定那裡的人也是用熱狗手指來做設計也不一定。」

我想要「了解動機和需求鍵」，讓我可以更快地了解大家的根本動機跟需求是什麼。— Jill

Jill 表示：「無論是設計或是研究上面，我們都會用『Find why? 』這個方法，去挖掘使用者跟老闆的根本動機與需求；所以我會想要這個過程可以更快一點，可以快速找到大家在意的點！」

我想要「通靈鍵」，這樣我就不用一定要跟同事面對面才知道他們在想什麼，可以更快地完成設計！— Hanyu

Hanyu 表示：「這個其實有點像《攻殼機動隊》這部漫畫裡面的概念，你可以把自己的思想都上傳到網路上，而大家都是在那樣的資訊流下進行互動；因為我覺得設計工作最主要的是溝通，所以如果我有一個『通靈鍵』可以馬上知道大家在想什麼，應該會變得非常強大！」

Simon 總結：

今天三位來賓跟我們分享了許多關於「跨部門合作」的心態建立與方法，也讓我們深刻了解到合作的本質在於「信任」，任何好的合作關係都是需要長時間累積的，而信任的基礎來自於合作過程中的耐心溝通與細心觀察。

身為設計師的我們，如果願意多花一點心思去了解工程師的思考方式與工作風格，並且在設計的交付文件中，盡可能地使用工程師熟悉的語言、了解他們的需求以及持續地尋求回饋，相信雙方合作的過程會順暢許多，開發成果也會更接近產品團隊心中理想的樣貌。祝福所有為打造好產品而努力的你，能夠早日摸索一套跨部門的合作方法！

延伸閱讀：產品設計現場 EP4：成功進入新公司了，然後呢？聊聊到職後設計師所做的準備 — — 專訪設計師 Zoe、Jarvis、Stephanie