[譯] 設計師與工程師協做的 5 項準則

• 原文地址：5-rules-for-designer-engineer-collaboration: Tips to Improve Quality and Productivity
• 原文做者：Andrew Yang
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Starrier
• 校對者：PokerF、NoName4Me

設計師與工程師協做的 5 項準則

提升質量與生產率的小貼士

設計師 vs 工程師，源於 society6。

設計師和工程師被看做是徹底相反的。設計師被描繪成敏感的創造者，工程師被描繪成冷酷的後勤人員。然而，做爲一名前軟件工程師出身的產品設計師，我認爲這些對立面能夠在工做場所中有效地協同工做。只要多瞭解一下對方的角色，設計師和工程師之間的關係就會大大改善。如下是設計師在與工程師一塊兒工做時應遵循的五條通常準則，其次是從工程師的角度來看的另外五條準則。

給設計師的 5 項準則

圖片來自 Upslash，做者 William Iven。

1）避免自定義樣式

實際上，全部前端工程團隊都使用某種類型的庫或 CSS 框架來實現跨應用程序使用的樣式。這些庫一般包含一些通用樣式，如預約義的邊距、顏色和其餘類，這些工具是工程師用來使開發更快速、更一致的。這意味着，若是您決定添加自定義頁邊距、字體大小或組件，工程師必須從頭開始編寫自定義 CSS 以覆蓋基本樣式。偶爾這樣也不錯，但很快就會變得單調乏味了。僅在特殊場合或絕對必要時保存這些自定義樣式。畢竟，在一個框架內設計能夠簡化咱們的許多決策，這每每是好事。

2）儘早與工程師溝通

讓咱們現實一點，除非您正在爲一個初創公司工做，或者您是工程副總裁，不然工程師們不會獲得多少產品的發言權。設定產品願景在必定程度上一般取決於高管、產品經理和產品設計人員。然而，即便工程師在設計方面沒有太多投入,他們仍然感受正如他們本身在設計同樣。當您和產品經理開會時，請一位工程主管參加。此外，與您的工程團隊一塊兒設置一些設計評審來檢查您的設計。向他們解釋您作出設計決定的緣由，並徵求他們的反饋。若是工程師以爲他們對設計過程作出了貢獻，他們在實現設計時天然會更加用心。

3）聽取工程反饋

信不信由你，工程師一般都是至關不錯的設計師。特別是在 UX（譯者注：用戶體驗） 方面，我曾和許多有很強設計意識的工程師一塊兒工做過。這些工程師想要被傾聽，他們的反饋是很是有價值的，並且每每是準確的。當你信任的工程師針對你的設計給你反饋時，傾聽。更好的方法是，拿出筆記本並記下他們的想法，讓他們知道你在聽。你沒必要使用全部的想法，但要給予他們應有的尊重，有些建議是必定要堅持的。

固然，並不是全部來自工程師的設計反饋都是好的。以懷疑又開放的心態來對待它，你總會有所得，並且又有誰不喜歡被聆聽呢。

4）瞭解基礎的 HTML/CSS/JS

當我仍是 SalesforceIQ 的軟件工程師時，和我一塊兒工做過的最好的設計師之一能夠和我一塊兒直接進入 Web 檢查器，並在控制檯中直接使用 HTML/CSS 快速原型。做爲一名工程師，知道與你一塊兒工做的設計師理解你正在使用的技術，而且在設計時考慮到這些限制，這是使人難以置信的安心。要成爲一名優秀的產品設計師，徹底沒有必要擁有完整的前端開發技能，但一些基本的前端知識會發揮很大做用。得到您最親密的同伴的尊重 -- 學習一些代碼。

5）批量小修正

心流是工程師最有生產力的一種狀態 -- 它在很大程度上意味着『在區域內』。工程師須要大量不間斷的時間才能實現流程。這就是爲何會議最好安排在一天的開始或結束，而不斷的干擾是工程師生存的禍根。是的，這意味着你今天早上洗澡時想要用更深的藍色來作按鈕的想法能夠暫時擱置。設計是一個迭代的過程，產品無疑會不斷的變化。然而，在向工程師詢問以前，先讓這些小的變化積累起來。例如，在接近工程師進行修復以前，設置五個小的更改的基線。沒有什麼比打破他們的流程更讓工程師煩惱的了（僅僅改變按鈕的顏色七次）。

---

給工程師的 5 項準則

William Iven 經過 Upslash 拍攝。

1）理解用例

做爲一名工程師，您有大量權力能夠用指尖進行創造，並且它真的很容易用代碼實現。然而，巨大的權力帶來了巨大的責任。退一步說，瞭解您正在構建的產品或特性的『緣由』。去和您的產品經理和產品設計師談談。理解爲何要構建這個特性，以及爲何它是按照這樣的方式設計的。沒有這種洞察力，你的工做只是做用在產品邊緣。另外，經過對產品的理解，您將可以在實現中考慮全部不一樣的用例和邊緣案例，並將您的代碼水平提高到下一個層次。

2）先實現 UX

在敏捷環境中，設計是基於用戶測試和反饋不斷迭代的。您昨天刻意實現的一個具備5個像素的 border-radius 和 box-shadow 藍色按鈕而如今倒是一個有着平面設計和尖銳邊緣的綠色按鈕。搞砸了。可是，不要氣餒：接受這是產品開發過程的一部分。首先實現 UX - 設計的流程、功能和整體佈局。得到總體效果，但不要瘋狂於像素的完美實現。一旦設計經歷了更多的迭代測試而且版本穩定下來後，栩栩如生的元素會逐漸融入其中。。

3）回退

還記得上次設計師要求您實現一個改變顏色並每隔一分鐘翻轉一次的自定義組件嗎？是的，別那麼作。設計是雙向的行爲。不要懼怕回退，給出技術約束和限制的反饋。在大多數狀況下，即便是最好的設計人員也不會擁有您的技術能力或對系統的理解。然而，與其一味地說「這是不可能作到的」，不如提供一個替代的解決方案。試試看，「這個解決方案的實現成本很高，我能夠建議您使用…嗎？」。請記住，大多數事情都能夠用咱們現有的工具來完成，但這並不意味着全部的事情都應該完成。做爲工程師，你的工做就是幫助設計師找到最好、最經濟有效的解決方案。

4）與設計師保持聯繫

溝通確實是本文的主題。 在您實現設計時，務必始終向設計師展現您的進度。 設計師喜歡看到他們的做品變得栩栩如生，因此對每一個人來講這真是一件有趣的事情。 讓設計師及時瞭解您的進展狀況將有助於確保您的實現符合預期，而且不會出現任何意外狀況。 這也是一個很好的機會向設計師詢問任何關於設計或將來任務的問題。

5）填補空白

在實現設計時，總會有一些地方須要您用本身的最佳判斷來填補空白。您實現的設計不會徹底相似於交給您的設計 --  這只是底線。您確定有遇到過這樣的狀況：您以爲在某些屏幕上須要更大的外邊距，或者在實際應用程序中某個特定的顏色看起來不太合適。不要每次都帶着問題去找設計師。把你的設計師帽子戴上，告訴本身你有解決它們的能力。你有這個本事。

但也不要太過瘋狂，作重大決定的時候記得要和你的設計師溝通。用您最好的判斷力 :)

---

如今你明白了吧！這是我爲設計師和工程師改善他們工做時的協做而編寫的 5 項準則。這些準則都是徹底主觀的，來自之前我做爲軟件工程師時的經驗，以及如今我做爲產品設計師的經驗。請告訴我，您是否贊成個人觀點，這樣咱們好在下面繼續討論！

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。