這是產品團隊工作秘籍的最后一篇。本篇講述作為設計師，該如何與開發工程師一起更好的合作。之前兩篇秘籍如下查看：

點擊查看產品團隊工作秘籍一：如何與設計師一起工作？

點擊查看產品團隊工作秘籍二：如何與產品經理一起工作？

——————我是分割線——————

如何與工程師一起工作——給設計師的秘籍

在很久以前，我曾經做過產品經理，之后也做過開發工程師，在過去的7年里，我從事設計的工作。每一天我都和擔任這些角色的人一起工作，而每一天，在產品開發中，我對這三種角色相互合作背后的責任，挑戰以及藝術都有新的體會。工程師是團隊中的魔術師，他們只需要動動手指，執行計劃和繪制像素，你瞧！一款鮮活的產品就誕生了。作為設計師，如何才能跟得上他們精明縝密，自我否定又熱衷腳本的工作方式呢？往下看吧。

工程師是將創意變為現實的人

是工程師將每個好點子變成現實的，這是個大家需要永遠銘記的事實。不管你的公司里有5個，500個或是5000個工程師，都不要把他們當做是一種“資源”。他們是產品基石的建筑師，也是讓產品正常運行的守護者，是他們，讓產品快速運作起來，變得穩定，可靠，從而擁有數百萬記的用戶。通常，也是他們在創新，用新的算法在推動技術，將產品團隊無數投入變得有意義。

這一切的一切我就是想表明：工程師超牛掰！這意味著…

想要創造點神奇？你需要做的就是說服一兩個工程師

真的，就這么簡單。許多傳奇般的產品是這樣誕生的：幾個好友在某個周末，一邊喝著啤酒一邊敲著代碼。產品經理和管理什么的那都是后來的事情，一切都從最基礎開始——創意，設計然后實現。這也就是為什么我們需要與工程師保持緊密的關系。

或者，試想一下這樣的場景：產品中某個細節部分讓你感到十分煩惱，就像瘙癢在你根本撓不到的地方的那種，你覺得這個設計很有問題，你該怎么做？

1. 在下次團隊討論會中提出來，加入到產品改進列表，然后大家一起來排定優先級，之后等待新的工程師加入團隊，在他熟悉了產品之后再把它做出來。

2. 和某個工程師保持良好關系然后徑直走向他的工位，請他幫個忙，花個三五分鐘處理，然后再看著他提交這個改進。（也許你需要幫他做一件印著80年代知名樂團圖案的T-shirt或是其他點什么作為交換，反正你對插畫也很在行。）

你說哪種辦法更快？也就是說…

如果工程師明白設計的價值，事情會變得容易得多

試想一下，工程師不需要來詢問你每個設計細節就知道如何處理頁面的空白處，即使你忘了詳細標注邊距的尺寸，他也會打開PS自己丈量——這是件多么美妙的事情。特別是他還能給你提出改進意見讓你的設計變得更好，這簡直不可思議。更有甚者，他細致精準到實現出的界面與你的設計完全無二致，這是件多么驚人的壯舉??！

你如何才能與這樣的工程師一起工作？如果能招到這樣的工程師，那將會是很幸運的事情，因為界面設計導向的工程師是炙手可熱的。

或者幫助工程師提高一些設計鑒賞力。如何做到呢？不要只是把你的設計丟給他們——和他們闡述你的設計，告訴他們設計的價值，以及為什么你的設計是值得實現的。幫助他們學會如何鑒別實現是否符合設計的要求。對于那些看起來很糟的東西告訴他們你是怎么想的。

建立良好的關系也很重要。人們總是根據和其他人的談話轉移自己的價值取向和優先級。這聽起來很老套但總是屢試不爽。（New Yoker站點上一篇名為“Slow Ideas”的文章就很完美的闡述了這個策略）

工程師大多不會關注到設計細節，但是他們大部分都很關心用戶體驗而且希望產品有更好的體驗。這并不是說每個工程師都會熱衷于設計細節的實現工作，但是這樣的態度有助于他們理解設計背后的意義。

因為，工程師越是對設計喜歡，他就越能理解這樣設計的原理并且看到它的價值，也就能越快越好地將它實現。

盡早搞清技術限制，為自己節省時間

身為設計師，你很容易就會沉浸在各種設計假想的世界中難以自拔。如果我們能讀懂用戶的心思并且知道他具體想要什么然后再呈現給他？又或是點擊這個按鈕會產生火焰以及爆炸成顆粒隨風飄散的特效？

在沒搞清技術或是時間限制前，別沉迷中那種根本不可能實現的設計。（就算是值得你去爭取一下的設計方案，提前了解限制也會讓你更有底氣。）最壞的情況就是你傾注大量的時間試圖將某個設計提案做到完美，最后卻發現它卻根本不可行。好的設計師本來就夠少的，而要解決的大問題又有很多，這種毫無效率的事情應該盡量避免。

所以下次當你有個絕妙的主意在你腦海中閃過，而你卻對實現難度上感到疑惑時，別猜，直接去問工程師！另一邊也是一樣…

任何時候都讓工程師了解最終設計會是如何，幫他節省時間

如果你對自己交給工程師實現的設計方案并不那么自信，在看到成品前都無法確定它是否能夠運作得好，請確保讓他們知道設計有可能會有變化。對于工程師來說，沒有什么比“通宵完成實現卻在第二天早上得知整個設計已經改了”來得更困擾的事情了，因為這樣他們要把那些傾注了無數心血、成品級別的代碼統統丟掉了。

當然，工程師都有寫出廢代碼的經歷。這是他們工作的一部分，設計也是一樣。好的工程師理解產品研發的流程是復雜的，東西做出來之前都不知道是否能行得通，需求常常變化，設計也是。但是溝通清楚哪些部分仍然還在探索，哪些部分基本已經敲定，可以幫助工程師想出如何更好的構筑代碼，是更快速的編程，還是寫得足夠靈活為將來的修改做好準備。

確保設計得到完美實現的最好方法就是極其密切地與工程師合作

像是坐在他們的邊上看著他們把東西做出來。大家都坐在同一個空間里工作，對于確保大家是否進度一致這件事，則顯得異常容易。問題更快浮出水面，也能更快得到解決。

最終產品如果不是每個人都引以為豪的成品，各種指責將輕易出現?！拔覀兊脑O計很贊的，但是工程師根本就實現得不對?！边@種思想要不得。作為設計師，你需要對面向用戶的產品負責，而不是那些PS的設計稿。對于實現不對的地方為什么不拿出些該有的行動？為什么你不讓工程師給你演示一下他們實現好的東西這樣你們就可以一起摳摳細節？為什么不在開發階段問問工程師們是否對你的設計有任何疑問？為什么不在發現后給工程師提交一個任務讓他去修復？

沒錯，拿出你的擔當來！

最快俘獲工程師的心的方法，就是提供完整的設計

說起來也可笑，人們總是用“細節導向”來形容設計師，然而事實上許多設計文檔遺漏了大量的場景，最終卻由執行這些分支開發的工程師找出來。

想成為工程師心目中的設計英雄么？請確保你的設計方案是完整的，考慮到各種邊緣場景例如：

1. 國際化： 設計在換了另一種語言后看起來如何？尤其是德語下長文字對排版的影響如何？

2. 出錯狀態：網絡連接丟失時會發生什么？或是數據崩潰？等等。

3. 極端用戶： 當用戶完全沒有任何信息或是活動時，頁面是如何的？那當用戶有著超級多的信息或活動時呢？

4. 頁面轉換：A屏到B屏的跳轉具體是怎么完成的？好的工具在將給你幫大忙，具體可以參考我的另一篇文章《如何在設計（以及僵尸啟示錄）中生存》

設計上述的這些場景不僅可以幫你全局的考慮產品從而增加對設計的信心，更可以幫助工程師去計劃如何構建系統，并給出時間上給出合適的評估。更不用說完整的設計可以避免臨時抱佛腳出來的粗制濫造，因為之前沒人發現直到想做得更好卻為時已晚。

請做一個合格的團隊貢獻者，確保你的設計是完整的，別只為理想的情景去做設計，從設計效果圖的幻境中走出來。因為每一個工程師都知道，唯一有價值的就是最后發布的那個產品。

——————我是分割線——————

原文出處：How to Work with Engineers?早讀課編譯

產品團隊工作秘籍一：如何與設計師一起工作？

產品團隊工作秘籍二：如何與產品經理一起工作？

產品團隊工作秘籍三：如何與工程師一起工作？