前端開發人員如何幫助彌合設計師和開發人員之間的鴻溝

在過去的九年裡，幾乎每一個與我共事過的設計師都對我表達了他們的沮喪，因為他們經常不得不花費數天時間向開發人員提供反饋，以糾正根本沒有正確實現的間距、字體大小、視覺以及佈局方面. 這往往會導致設計師和開發人員之間的信任減弱，並導致設計師沒有積極性以及兩個學科之間的不良氛圍。

很多時候，在考慮設計團隊提出的細節時，開發人員似乎仍然有過度技術化和無知的壞名聲。 根據 Andy Budd 的一篇文章，“[...] 許多開發人員在設計方面處於相同的位置——他們只是沒有意識到這一點。” 但實際上（正如 Paul Boag 指出的那樣），“開發人員 [需要] 始終做出設計決策。”

在本文中，我將為前端開發人員提供實用的建議，以避免他們在與創意同行合作時感到沮喪並提高生產力。

透過設計師的眼睛看

讓我們暫時假設您是一名設計師，並花了最後幾週（如果不是幾個月的話）為網站制定設計。 您和您的團隊成員經歷了多次內部修訂以及客戶演示，並投入大量精力來微調視覺細節，例如空白、字體樣式和大小。 （在響應式時代——當然是針對多種屏幕尺寸的。）設計已經得到客戶的批准，並交給了開發人員。 你感到如釋重負和快樂。

幾週後，您會收到一封來自開發者的電子郵件，內容是：

“暫存站點已設置完畢。 這是鏈接。 可以請QA嗎？”

在期待的激動中，您打開該臨時鏈接，並在滾動瀏覽某些頁面後，您注意到該站點看起來有點不對勁。 間距甚至不接近您的設計建議，並且您注意到佈局中的一些問題：錯誤的字體和顏色以及不正確的交互和懸停狀態。 你的興奮開始慢慢消退，變成一種沮喪的感覺。 你不禁問自己，“怎麼會這樣？”

尋找原因

也許只是設計師和開發者之間的溝通中出現了很多不幸的誤解。 然而，你繼續問自己：

• 設計的交接是什麼樣的？ 是否只是通過電子郵件共享了一些 PDF、Photoshop 或 Sketch 文件並附有評論，或者是否有實際的交接會議討論了可能的設計系統、排版、響應行為、交互和動畫等各個方面？
• 是否存在有助於可視化某些交互的交互或運動原型？
• 是否創建了具有明確優先級的重要方面列表？
• 進行了多少次對話——設計師和開發人員在同一個房間裡？

由於通信和切換是兩個非常重要的關鍵點，讓我們仔細看看它們。

溝通是關鍵

設計師和開發人員，請互相交談。 多說話。 項目越早進行，越頻繁越好。 如果可能，請在項目早期（並定期）一起審查正在進行的設計工作，以便不斷評估可行性並獲得跨學科的意見。 設計師和開發人員自然會關注同一部分的不同方面，因此從不同的角度和角度看待事物。

儘早簽入可以讓開發人員熟悉項目，以便他們可以開始研究和提前計劃技術術語，並提出他們關於如何優化功能的想法。 經常簽到也可以在個人和社交層面上將團隊凝聚在一起，並且您將學習如何接近彼此以進行有效溝通。

從設計到開發的交接

除非組織遵循真正敏捷的工作流程，否則設計組合和資產（從設計團隊到開發人員）的初始移交可能會在項目的某個時刻發生。 這種移交——如果徹底完成——可以成為雙方之間知識和協議的堅實基礎。 因此，重要的是不要急於完成它併計劃一些額外的時間。

問很多問題，討論每一個需求、頁面、組件、功能、交互、動畫，任何東西——並做筆記。 如果事情不清楚，請要求澄清。 例如，在與外部或基於合同的團隊合作時，設計人員和開發人員都可以簽署作為共同協議文件的筆記，以供將來參考。

平面和靜態設計組合非常適合顯示網站的圖形和佈局方面，但顯然缺乏交互和動畫的正確表示。 索要復雜動畫的原型或工作演示，將更清楚地了解需要為所有相關人員構建的內容。

如今，有各種各樣的原型工具可供設計人員用來模擬不同保真度級別的流程和交互。 Javier Cuello 在他的一篇綜合文章中解釋瞭如何為您的項目選擇正確的原型設計工具。

每個項目都是獨一無二的，其要求也是如此。 由於這些要求，並非所有概念化特徵都可以始終構建。 通常，構建某些東西的可用時間和資源可能是一個限制因素。 此外，限制可能來自技術要求，例如可行性、可訪問性、性能、可用​​性和跨瀏覽器支持，經濟要求（例如預算和許可費用）或個人限制（例如開發人員的技能水平和可用性）。

那麼，如果這些約束導致設計人員和開發人員之間發生衝突怎麼辦？

尋找妥協並建立共享知識

為了按時成功交付項目並滿足所有定義的要求，在這兩個學科之間尋求妥協幾乎是不可避免的。 開發人員在解釋為什麼需要更改或無法在特定情況下構建的原因時，需要學會用非技術術語與設計師交談。

開發人員不應僅僅說“抱歉，我們無法構建這個”，而應嘗試給出設計人員可以理解的解釋，並且——在最好的情況下——為在已知約束範圍內工作的替代解決方案準備建議。 用統計數據、研究或文章支持你的觀點，有助於強調你的論點。 此外，如果時間是一個問題，是否可以將一些耗時的部分的實施移到項目的後期階段？

儘管並非總是可行，但讓設計人員和開發人員坐在一起可以縮短反饋循環並更容易制定妥協的解決方案。 可以通過打開 DevTools 的編碼和優化直接進行適配和原型設計。

向您的設計人員展示如何在瀏覽器中使用 DevTools，以便他們可以在瀏覽器中更改基本信息並預覽微小的變化（例如填充、邊距、字體大小、類名）。

如果項目和團隊結構允許，盡快在瀏覽器中構建和原型設計可以讓參與的每個人更好地了解響應行為，並有助於消除項目早期的錯誤和錯誤。

設計師和開發人員一起工作的時間越長，更好的設計師就越能理解開發人員構建什麼更容易，什麼更難。 隨著時間的推移，他們最終可以參考過去對雙方都有效的解決方案：

“我們已經使用該解決方案在項目 A 中找到折衷方案。我們也可以將它用於這個項目嗎？”

這也有助於開發人員更好地了解設計師非常具體的細節以及哪些視覺方面對他們很重要。

設計師期望前端看起來（和功能）像他們的設計

設計文件與。 瀏覽器比較

防止設計人員受挫的一個有用技術是在您收到的設計文件和您當前的開發狀態之間進行簡單的左右比較。 這聽起來可能微不足道，但作為開發人員，您必須處理許多需要在後台運行的事情，以至於您可能錯過了一些視覺細節。 如果您發現一些明顯的差異，只需更正它們。

可以這樣想：實現中的每一個細節都與設計完全一致，可以為您和設計人員節省寶貴的時間和麻煩，並鼓勵信任。 不是每個人都可能對細節有同等程度的關注，但為了訓練您的眼睛注意視覺差異，快速一輪 Can't Unsee 可能會有所幫助。

這讓我想起了很久以前我們玩過的一個遊戲，叫做“找到它”。 您必須通過比較兩個看似相似的圖像來找到差異才能得分。

不過，你可能會想：

“如果設計中根本沒有明顯的字體大小和間距系統怎麼辦？”

好，好點！ 經驗告訴我，通過要求澄清而不是從根本上開始自己改變事物並在以後為設計師製造不必要的驚喜，這有助於開始與設計師的對話。

學習基本的排版和設計規則

正如 Oliver Reichenstein 在他的一篇文章中所說，網絡上 95% 的信息都是書面語言。 因此，排版不僅在網頁設計中而且在開發中都起著至關重要的作用。 了解排版的基本術語和概念可以幫助您更有效地與設計師溝通，也將使您作為開發人員更加靈活。 我建議閱讀 Oliver 的文章，因為他詳細闡述了網絡排版的重要性，並解釋了諸如微觀和宏觀排版之類的術語。

在“移動網頁設計中的排版參考指南”中，Suzanne Scacca 徹底涵蓋了排版術語，如字體、字體、大小、粗細、字距、前導和跟踪，以及排版在現代網頁設計中的作用。

如果您想進一步擴展您的排版視野，Matthew Butterick 的書“Butterick 的實用排版”可能值得一讀。 它還提供了排版關鍵規則的摘要。

我發現在響應式網頁設計中特別有用的一件事是，應該以45 到 90 個字符的平均行長（每行字符）為目標，因為較短的行比較長的行更易於閱讀。

開發人員應該設計嗎？

設計師是否應該學習編碼已經有很多討論，你可能會反過來問自己同樣的問題。 我相信一個人很難在這兩個學科中都出類拔萃，這完全沒問題。

Rachel Andrew 在她的文章“一起工作：設計師和開發人員如何溝通以創建更好的項目”中很好地概述了為了更有效地協作，我們都需要學習團隊成員的語言、技能和優先事項，以便我們可以創建共享語言和重疊的專業領域。

在設計領域變得更有知識的一種方法是由 Sarah Drasner 提供的名為“為開發人員設計”的在線課程，她在其中談到了基本的佈局原則和色彩理論——網頁設計的兩個基本領域。

“你在自己的學科之外學到的越多，實際上對你 [...] 作為一名開發人員來說就更好了。”

— 莎拉·德拉斯納

視覺中心

通過與設計師合作，我了解了數學中心和視覺中心之間的區別。 當我們想將讀者的注意力吸引到某個元素上時，我們眼睛的自然焦點就位於頁面的數學中心略上方。

例如，我們可以應用這個概念來定位模態或任何類型的疊加層。 這種技術可以幫助我們自然地吸引用戶的注意力，並使設計看起來更加平衡：

我們誰都跑不了

在快節奏且不那麼靈活且截止日期緊迫的代理環境中，開發人員經常被要求實施基於移動和桌面模型的全功能響應式前端。 這不可避免地迫使開發人員在整個過程中做出設計決策。 諸如“我們將在多大程度上減小標題的字體大小？”之類的問題。 或者“我們什麼時候應該將我們的三列佈局切換到單列？” 可能出現。

此外，在當下的熱潮中，可能會發生諸如錯誤狀態、通知、加載狀態、模式或 404 頁面樣式之類的細節完全漏掉的情況。 在這種情況下，很容易開始指責和指責那些早該想到這一點的人。 理想情況下，開發人員不應該被置於這種情況下，但如果是這樣的話怎麼辦？

當我聽上野的創始人兼首席執行官 Haraldur Thorleifsson 在 2018 年舊金山的一次會議上發言時，他提出了他們的兩個核心價值觀：

“這裡沒有什麼是別人的問題。”

“我們撿起沒有放下的垃圾。”

如果更多的開發人員主動開始盡可能好地模擬上述缺失的部分，然後與坐在他們旁邊的設計師一起完善呢？ 網站存在於瀏覽器中，那麼為什麼不利用它來構建和改進呢？

雖然缺少或遺忘的部分可能並不總是理想的，但我從過去的經驗中了解到，它總是幫助我們更快地前進並在飛行中消除錯誤——作為一個團隊。

當然，這並不意味著設計師應該在這個過程中被否決。 這意味著開發人員應該通過表現出解決問題的主動性來嘗試恭敬地與設計師會面。 除此之外，我作為一名開發人員，僅僅因為關心和承擔責任而受到團隊的重視。

在設計師和開發人員之間建立信任

在創意團隊和技術團隊之間建立信任和積極的關係可以極大地提高生產力和工作成果。 那麼，作為開發人員，我們可以做些什麼來增加這兩個學科之間的信任呢？ 這裡有一些建議：

1. 關注細節。
   完全按照設計的方式建造東西會向設計師展示你的關心，並讓他們臉上露出燦爛的笑容。
2. 尊重溝通。
   我們都是在專業環境中努力爭取最好結果的人。 尊重彼此的紀律應該是所有溝通的基礎。
3. 儘早並定期檢查。
   從一開始就讓開發人員參與進來有助於儘早消除錯誤。 通過頻繁的溝通，團隊成員可以形成共同語言，更好地了解彼此的立場。
4. 讓自己可用。
   每天至少有一個可選的 30 分鐘窗口，設計師可以與開發人員討論想法，這可以給設計師一種被支持的感覺。 這也讓開發人員有機會用不太懂技術的人可以更好地理解的語言來解釋複雜的技術事物。

結果：雙贏局面

通過有效的溝通和適當的設計移交，必須在 QA 上花費更少的時間，這讓創意和開發團隊有更多的時間專注於構建實際的東西，減少頭痛。 它最終創造了一種更好的氛圍，並在設計師和開發人員之間建立了信任。 在一些設計相關領域表現出興趣和知識的前端開發人員的聲音將在設計會議中被更多地聽到。

積極主動地幫助在設計師和開發人員之間找到折衷方案並作為開發人員解決問題可以讓您對整個項目有更廣泛的所有權和參與感。 即使在當今蓬勃發展的創意產業中，要找到除了技術技能之外還關心並關注視覺細節的開發人員也並非易事。 這可能是您幫助彌合團隊差距的機會。

相關資源

• “如何選擇正確的原型設計工具，”哈維爾·庫洛
• “移動網頁設計中的排版參考指南”，Suzanne Scacca
• “巴特里克的實用印刷術，”馬修·巴特里克
• “一起工作：設計師和開發人員如何溝通以創建更好的項目，”Rachel Andrew
• “為開發人員設計”，前端大師 Sarah Drasner
• “網頁設計是 95% 的排版，”Oliver Reichenstein
• “Can't Unsee”，一個瀏覽器測驗，用於訓練您識別視覺細節的感覺。