前端開發人員如何賦能設計師的工作

親愛的前端開發人員，這篇文章主要針對您，他們喜歡實現用戶界面，但在與您合作的設計師保持期望方面遇到困難。 也許您被稱為“UI 開發人員”或“UX 工程師”。 不管你的頭銜是什麼，你的工作（以及我的工作）不僅僅是為設計文件注入活力。 我們還負責填補設計和開發工作流程之間的空白。 然而，在跨過那座橋時，我們面臨著多重挑戰。

今天，我想和大家分享一些實用技巧，這些技巧幫助我在過去幾年中更有效地與設計師合作。

我相信，作為 UI 開發人員，我們的工作不僅是幫助設計師了解 Web 的工作原理，而且還要了解他們的現實並學習他們的語言。

了解 UX 設計師的背景

大多數用戶體驗設計師（也稱為網頁設計師或產品設計師）通過 Photoshop 和 Illustrator 等工具在設計界邁出了第一步。 也許他們是平面設計師：他們的主要目標是創建徽標和品牌標識，並為雜誌設計版面。 他們也可能是營銷設計師：打印廣告牌、設計橫幅和創建信息圖表。

這意味著大多數 UX 設計師在早期都在為印刷設計，這與他們當前的媒介——屏幕完全不同。 那是他們的第一個大挑戰。 在處理打印時，設計師關心像素對齊，但在固定區域（紙張）上。 他們不必與動態佈局（屏幕）抗衡。 考慮文本中斷或交互狀態也根本不是他們工作的一部分。 設計師在顏色、圖像和排版方面也有完全的自由，沒有性能限制。

幸運的是，自學成才的 UX 設計師社區做出了許多努力，教授開發基礎知識，討論設計師是否應該學習編碼，以及了解如何最好地向開發人員移交。 開發方面也是如此（稍後會詳細介紹）。 然而，這兩個領域之間仍然存在摩擦。

一方面，每次實現與他們的設計不匹配時，設計人員都會抱怨，或者當開發人員在沒有明確解釋的情況下拒絕這些實現時，他們會感到被誤解。 另一方面，開發人員可能會理所當然地認為設計師知道一些技術知識，而這可能不是真的。 我相信我們都可以做得更好。

擁抱新的思維方式

我們正在構建的網站和應用程序將顯示在各種屏幕尺寸上。 每個人都會在多個設備上使用它們。 我們的共同目標是在他們的旅程中創造一種熟悉的體驗。

當我們作為開發人員認為設計師對像素對齊很挑剔時，我們需要了解為什麼會這樣。 我們需要認識到它超出了保真度和一致性。 這是關於所有部分一起工作的總和。 是凝聚力。 我們必須接受它並儘最大努力實現它。 學習設計原則的基礎是一個很好的起點。 了解選擇正確顏色的重要性、層次結構的工作原理以及留白的重要性。

注意：有一個名為“面向開發人員的設計”的在線課程和一本名為“重構 UI”的書——兩者都非常適合幫助您入門。 有了這些，您將能夠以敏銳的眼光來實現用戶界面，並在與設計師交流時獲得顯著的優勢。

放大設計師的意識

您可能想當然地認為設計師和您一樣了解網絡。 好吧，他們可能不會。 其實，他們不必！ 作為開發人員，我們有責任讓他們了解網絡的當前狀態。

我曾與這個範圍的兩個方面合作過：認為可以構建任何東西（例如復雜的過濾器、新的滾動行為或自定義表單輸入）而不考慮瀏覽器兼容性的設計師。 然後，有些設計師假設“網絡的低限制”，只是自己假設某些東西是不可能實現的。 我們需要向他們展示網頁設計的真正可能性，而不是讓限制阻礙他們的技能。

教他們編碼，而不是如何編碼

這似乎是矛盾的，但請容忍我：知道如何編碼是開發人員工作的核心。 我們在一個快節奏的行業工作，每天都會出現新的東西。 如果我們要求設計師學習如何編碼，那將是一個虛偽的要求。 但是，我們可以幫助他們理解代碼。

坐在與你一起工作的設計師旁邊15 分鐘，教他們如何自己查看元素的規格是否正確以及如何更改它們。 我發現 Firefox Page Inspector 對此非常友好。

如今，可視化佈局、調試 CSS 動畫和調整排版是一種樂趣。 向他們展示一個像 Codepen 這樣的即用型代碼遊樂場供他們探索。 他們不需要知道所有的 CSS 規範來理解佈局範式是如何工作的。 但是，他們需要知道元素是如何創建和表現的，以便為他們的日常工作提供支持。

在開發過程中包括設計師

邀請設計師加入您的站立會議，成為 QA 流程的一部分，並在您完善實施中的視覺細節時與您坐下來。 這將使他們了解網絡的限制，並且很快他們就會認識到為什麼一個功能需要時間來實現。

要求設計師將您包括在他們的設計過程中

你會意識到他們做的不僅僅是“讓事情變得漂亮”。 您將了解有關研究過程以及如何完成用戶測試的更多信息。 您會發現，對於他們向您展示的每個設計建議，之前都放棄了其他幾項研究。 當設計師要求更改時，請詢問其背後的原因，這樣您就可以了解更多有關所做決定的信息。 最終，您將開始理解為什麼他們對空白和對齊方式很挑剔，希望很快您也會如此！

我發現將前端開發視為設計過程的核心部分，並將設計視為開發過程的核心部分至關重要。 提倡每個人都有機會參與設計和開發週期的思維方式，這將有助於我們所有人更好地了解彼此的挑戰並創造出色的體驗。

我們可能使用不同的工具，但我們必須說同一種語言

現在我們開始更好地了解彼此的工作流程，是時候進行下一步了：說同一種語言。

超越代碼編輯器

一旦你開始關注周圍的環境，你就會更有能力解決問題。 更好地了解業務並願意傾聽設計師的意見。 這將使您成為對項目有更豐富貢獻的團隊成員。 在我們專業之外的領域進行合作是建立有意義的對話和相互信任的關鍵。

使用 UI 系統作為合同

要求設計師與您分享他們的設計系統（如果他們不使用，那麼開始永遠不會太晚）。 這將使您免去挑選所用顏色、計算邊距或猜測文本樣式的麻煩。 確保您與他們一樣熟悉 UI 系統。

您可能已經熟悉基於組件的概念。 然而，一些設計師可能不會像你那樣看待它。 向他們展示組件如何幫助您更有效地構建用戶界面。 傳播這種心態，並與相似但不相等的名稱說再見：標題與英雄，定價信息與價格選擇器。 當構建用戶界面的一部分（又名“組件”）時，請大步使用相同的名稱，以便它們可以反映在設計和代碼文件中。 然後，當有人說“我們需要調整提案邀請小部件”時，每個人都清楚地知道在談論什麼。

承認真相的真正來源

儘管用戶界面首先是在設計文件中創建的，但真正的事實來源是在開發方面。 歸根結底，這是人們實際看到的，對吧？ 更新設計時，最好在旁註一下其開發狀態，尤其是在涉及大量人員的項目中。 這個技巧有助於保持溝通順暢，所以沒有人（包括你）想知道：“這與現場版本不同。 它是一個錯誤還是尚未實現某某？ ”

控制債務

所以，你對技術債務瞭如指掌——它發生在實施新事物的成本很高時，因為我們過去為了趕上最後期限而採取的捷徑。 同樣的情況也可能發生在設計方面，我們稱之為設計債務。

你可以這樣想：UX 和 UI 不一致的程度越高，債務（技術和設計）就越高。 最常見的不一致之一是使用不同的元素來表示相同的動作。 這就是為什麼糟糕的設計通常會反映在糟糕的代碼中。 作為設計師和開發人員，我們所有人都應該認真對待我們的設計債務。

易於訪問並不意味著它必須是醜陋的

我非常高興地看到，作為開發人員和設計師，我們終於開始將可訪問性引入我們的工作。 然而，我們中的很多人仍然認為設計無障礙產品很難或限制了我們的技能和創造力。

讓我提醒您，我們並不是只為自己創造產品。 我們正在創造一種供所有人使用的產品，包括那些以與您不同的方式使用該產品的人。 考慮如何在保持當前用戶流清晰和連貫的同時更容易訪問各個元素。

例如，如果設計師真的認為創建增強的選擇輸入是必要的，那麼站在他們的一邊，共同努力，以一種可訪問的方式設計和實現它，以供具有不同能力的廣泛人群使用。

向設計師提供有價值的反饋

在進行設計時不可避免地會出現問題。 然而，這並不是你開始抱怨設計師的錯誤或他們雄心勃勃的想法的理由。 設計師不是為了讓你動腦筋，他們只是並不總是直覺地知道你需要什麼來完成你的工作。 事實是，在過去，你也不知道這些東西，所以要有耐心，把協作作為一種學習方式。

反饋越早越好

反饋的時機至關重要。 反饋工作流程很大程度上取決於項目結構，因此沒有一種萬能的解決方案。 但是，如果可能的話，我相信我們應該以定期反饋的工作流程為目標——從早期階段開始。 擁有這種開放式協作的心態是減少以後出現意外大重複的可能性的方法。 請記住，您向設計師提供第一個反饋的時間越晚，他們在需要時探索新方法的成本就越高。

用簡單的術語解釋抽象的想法

還記得我說過性能與設計師以前的工作無關嗎？ 當他們不知道如何為 Web 創建優化的 SVG 時，不要驚慌。 當面對需要加載大量不同字體的設計時，向他們解釋為什麼我們應該盡量減少請求的數量，甚至可以利用可變字體。 除了加載速度更快之外，它還提供了更一致的用戶體驗。 除非設計師熱衷於學習，否則在解釋某事時避免使用過多的技術術語。 您可以將此視為提高您的溝通技巧和澄清您的想法的機會。

不要讓假設變成決定

一些關於設計規範的問題只有在我們弄髒代碼時才會出現。 為了加快速度，我們可能會很想根據我們的假設做出決定。 請不要。 每次將假設轉化為決定時，您都在冒著設計團隊對您實施 UI 的信任的風險。 如有疑問，請聯繫並澄清您的疑慮。 這將向他們表明您和他們一樣關心最終結果。

不要自己做變通方法

當你被要求實現一個太難的設計時，不要說“這不可能”或開始自己實現一個廉價的替代版本。 當設計團隊發現他們的設計沒有按預期實施時，這會立即引起與設計團隊的摩擦。 他們可能會做出憤怒的反應，或者什麼都不說，但感到挫敗或沮喪。 如果我們用簡單的術語向他們解釋為什麼某些事情是不可能的並提出替代方法，那麼這一切都可以避免。 避免教條主義的行為，並願意就新的解決方案進行合作。

讓他們了解 Graceful Degradation 和 Progressive Enhancement 技術，並一起構建一個理想的解決方案和一個備用解決方案。 例如，我們可以將佈局從 flexbox 增強為 CSS Grid。 這使我們能夠尊重功能的核心目的，同時充分利用 Web 技術。

談到動畫，讓我們變得真實：在內心深處，您對實現下一個令人驚嘆的動畫就像設計師要創造它一樣激動。 我們和他們的區別在於我們更清楚網絡的限制。 但是，不要讓這限制了你自己的技能！ 網絡發展迅速，因此我們必須利用它對我們有利。

下次您被要求將原型變為現實時，請盡量不要提前拒絕它或自己做所有事情。 將其視為推動自己的機會。 動畫是 Web 開發中最挑剔的部分之一，因此請確保與您的設計師親自或通過共享私人同步鏈接來優化每個關鍵幀。

超越理想狀態思考 — 齊心協力

事情是這樣的：這不是關於你的全部。 設計師面臨的挑戰之一是真正了解他們的用戶，並以最有吸引力的方式向產品經理展示設計。 有時他們忘記了超出理想狀態的內容，開發人員也忘記了它。

為了幫助避免這些差距的發生，請與設計人員保持一致的場景要求：

• 最壞的情況
  最壞的可能性正在發生的場景。 這有助於設計師對固定內容說不，讓它變得流暢。 如果標題超過 60 個字符或列表太長會怎樣？ 這同樣適用於相反的空場景。 當列表為空時，用戶應該怎麼做？
• 交互狀態
  瀏覽器不僅僅是懸停和點擊。 有很多狀態：默認、懸停、焦點、活動、禁用、錯誤……其中一些可以同時發生。 讓我們給予他們適當的關注。
• 加載狀態
  在本地構建東西時，我們可能會使用模擬並忘記加載實際上需要時間。 讓設計師也了解這種可能性，並向他們展示讓人們感知到加載時間不會那麼長的方法。

考慮到所有這些場景將在開發階段為您節省大量時間。

注意： Scott Hurff 有一篇很棒的文章，介紹瞭如何修復不良的用戶界面，這將使我們更接近可訪問的產品。

接受變更請求

眾所周知，開發人員不會因為有人在他們的代碼中發現錯誤而感到高興——尤其是當它是由設計師報告的設計錯誤時。 它周圍有很多模因，但你有沒有想過，當這些設計錯誤被隨意忽略時，這些錯誤如何復合地破壞體驗質量以及你們的關係？ 它發生得很慢，就像睡著了一樣。 一點一點，然後一次。 設計師可能會開始說，“這只是一個很小的細節”，直到冷漠和怨恨積聚起來，什麼也沒說。 損害已經造成。

這種情況是雙重的：對你的同齡人和你的工作。 不要讓這種情況發生。 研究影響你反應的因素。 設計師“挑剔”可能會帶來不便，但也可能是工程師對專注和熱情的膚淺詮釋。 當有人告訴你你的實現並不完美時（還），把你的自尊放在一邊，向他們展示你如何認識到他們在完善最終結果方面的辛勤工作。

偶爾去記錄一次

我們都有要交付的任務和要完成的路線圖。 然而，一些最好的工作是在記錄之外發生的。 它不會登錄到TO DO板，這沒關係。 如果你找到了與你有默契的設計師，就潛入他們的工作區，一起探索新的實驗。 你永遠不知道那裡會發生什麼！

結論

當你願意向設計團隊學習時，你也在學習不同的思維方式。 您將從您的經驗中發展您與其他領域合作的心態，同時完善您創造新體驗的眼光。 隨時提供幫助並樂於學習，因為分享讓我們變得更好。

沒有很多偉人的反饋，這篇文章是不可能完成的。 我要感謝設計師 Jasmine Meijer 和 Margarida Botelho 幫助我就設計師和開發人員之間的誤解分享了一個平衡的觀點。

SmashingMag 的相關閱讀：

• Mason Gentry的“為開發者設計”
• “一起工作：設計師和開發人員如何溝通以創建更好的項目”，作者： Rachel Andrew
• “前端開發人員如何幫助彌合設計師和開發人員之間的差距”，作者Stefan Kaltenegger
• “網頁設計師和開發人員應該聽哪些播客？” 通過瑞奇昂斯曼