使用代碼進行設計：一種現代設計方法（開發挑戰）

這篇文章得到了我們在 UXPin 的親愛的朋友的大力支持，他們的使命是通過將設計和工程融合到一個更好、更快的產品開發世界中來實現最佳的用戶體驗。 謝謝！

設計師和開發人員之間的合作摩擦正在推動與行業本身一樣古老的不斷發展的討論。 我們走了很長一段路才走到今天。 我們的工具發生了變化。 我們的流程和方法已經改變。 但潛在的問題往往保持不變。

無論團隊的類型和規模如何，我經常會看到的一個反復出現的問題是保持可靠的事實來源。 即使僱用最優秀的人才並使用經過驗證的行業標準解決方案，也常常讓我們感到厭惡，認為某些事情肯定可以做得更好。 臭名昭著的“最終版本”通常散佈在技術文檔、設計文件、電子表格和其他地方。 使它們保持同步通常是一項乏味而艱鉅的任務。

注意：本文是與 UXPin 團隊合作編寫的。 本文中介紹的示例是在 UXPin 應用程序中創建的。 某些功能僅適用於付費計劃。 可以在此處找到UXPin 定價的完整概述。

設計工具的問題

談到維護事實來源，設計工具的低效率通常被認為是最令人痛苦的痛點之一。 現代設計工具正在不斷發展，並且通過巨大的努力正在快速發展。 但是，當談到在設計和開發之間架起一座橋樑時，人們常常會覺得其中許多努力都是建立在有缺陷的假設之上的。

大多數現代設計工具都基於不同的模型，而不是後來用於實現設計的技術。 它們是作為圖形編輯器構建的，並且行為如此。 在設計工具中構建和處理佈局的方式最終不同於 CSS、JavaScript 和其他編程語言必須提供的任何內容。 使用矢量（甚至光柵）圖形構建用戶界面是對如何以及是否應該稍後將其轉換為代碼的不斷猜測。

設計師最終常常會抱怨他們的創作沒有按預期實現。 即使是最勇敢的像素完美設計也不能解決所有問題。 在設計工具中，幾乎不可能想像並涵蓋所有可能的情況。 支持不同的狀態，改變副本，各種視口大小，屏幕分辨率等等，只是提供了太多的變化變量來覆蓋它們。

除此之外，還有一些技術限制和限制。 作為一個沒有開發經驗的設計師，很難考慮所有的技術因素。 記住所有可能的輸入狀態。 了解瀏覽器支持的限制。 預測您的工作對績效的影響。 設計可訪問性，至少在某種意義上比顏色對比度和字體大小更廣泛。 意識到這些挑戰，我們接受一些猜測作為必要的邪惡。

但開發人員也經常不得不依靠猜測。 用圖形編輯器模擬的用戶界面很少能回答他們所有的問題。 它與我們已經擁有的組件是否相同？ 我應該將其視為不同的州還是單獨的實體？ 當 X、Y 或 Z 時，此設計應如何表現？ 我們可以讓它變得更快更便宜嗎？ 具有諷刺意味的是，詢問最初設計的人並不總是有幫助的。 並不罕見，他們也不知道。

通常，這不是越來越多的挫敗感結束的地方。 因為那時，還有其他人。 經理、利益相關者、團隊領導、銷售人員。 由於他們的注意力和心智能力在產品的各個部分所在的所有工具和地方變得稀薄，他們比任何人都更努力地掌握它。

瀏覽原型，了解設計中缺少某些功能和狀態的原因，以及區分缺少的內容、正在進行的工作以及有意識地排除在範圍之外的內容幾乎是不可能的。 快速迭代已經完成的工作、可視化您的反饋以及展示您自己的想法也幾乎是不可能的。 具有諷刺意味的是，越來越多的複雜工具和流程旨在讓設計人員和開發人員更好地協同工作； 他們設定了更高的標準，並且更難積極參與其他人的流程。

解決方案

我們行業的無數負責人致力於解決這些問題，從而產生了新的範式、工具和概念。 事實上，很多事情都變得更好了。 讓我們快速瀏覽一下應對上述挑戰的一些最常見的方法。

編碼設計師

“設計師應該編碼嗎？” 是一個陳詞濫調的問題，通過文章、會議演講和所有其他媒體進行了無數次討論，討論中的新聲音不時出現穩定的規律性。 有一個普遍的假設是，如果設計師“知道如何編碼”（我們甚至不要一開始就開始糾纏於如何定義“知道如何編碼”），他們將更容易製作出採用技術的設計考慮到約束並且更容易實現。

有些人會走得更遠，說他們應該在實施中發揮積極作用。 在那個階段，很容易得出結論，完全跳過使用設計工具而只是“在代碼中設計”並不是沒有意義的。

這個想法聽起來很誘人，但它很少在現實中證明自己。 我認識的所有最好的編碼設計師仍在使用設計工具。 這絕對不是因為缺乏技術技能。 解釋為什麼重要的是要突出構思、草圖和構建實際事物之間的區別。

只要有許多“代碼設計”的有效用例，例如使用預定義的樣式和組件來快速構建功能齊全的界面，而無需使用設計工具，那麼設計工具就可以提供無限制的視覺自由的承諾仍然具有不可否認的價值。 許多人發現以設計工具提供的格式草繪新想法更容易，更適合創作過程的本質。 這不會很快改變。 設計工具將永遠存在並永遠存在。

設計系統

設計系統的偉大使命，作為過去幾年數字化設計界最偉大的流行語之一，始終是：限制猜測和重複，提高效率和可維護性，統一事實來源。 Fluent 或 Material Design 等公司係統在宣傳這一想法方面做了很多工作，並為大小參與者採用該概念帶來了動力。 確實，設計系統幫助改變了很多，變得更好。 一種更結構化的方法來開發定義的設計原則、模式和組件集合，幫助無數公司構建更好、更易於維護的產品。

然而，一些挑戰並沒有立即得到解決。 使用流行的設計工具設計設計系統阻礙了許多人實現單一事實來源的努力。 取而代之的是，已經創建了過多的系統，儘管它們是統一的，但仍然存在於兩個獨立的、不兼容的源中：設計源和開發源。 保持兩者之間的相互平等通常被證明是一件痛苦的苦差事，重複設計系統最初試圖解決的所有最討厭的痛點。

設計和代碼集成

為了解決設計系統的可維護性難題，另一波解決方案很快到來了。 設計代幣等概念已經開始受到關注。 有些旨在將代碼狀態與設計同步，例如允許直接從設計文件中獲取某些值的開放 API。 其他的旨在將設計與代碼同步，例如通過在設計工具中從代碼生成組件。

這些想法很少被廣泛採用。 這很可能是由於可能的好處相對於仍然高度不完善的解決方案的必要進入成本的可疑優勢。 對於大多數專業用例來說，將設計自動轉換為代碼仍然是巨大的挑戰。 允許您將現有代碼與設計合併的解決方案也受到嚴重限制。

例如，任何允許您將編碼組件導入設計工具的解決方案，即使在視覺上與源代碼相同，也無法完全複製此類組件的行為。 直到現在都沒有。

將設計和代碼與 UXPin 合併

UXPin 作為一個成熟且功能齊全的設計應用程序，在設計工具舞台上並不是一個新玩家。 但它最近的進步，例如合併技術，可以改變我們對設計和開發工具的看法。

使用 Merge 技術的 UXPin 允許我們通過保留其視覺效果和功能，將真實、實時的組件帶入設計中——所有這些都無需編寫任何代碼。 即使嵌入在設計文件中的組件，其行為也應與其真正的對應物完全相同——因為它們是它們真正的對應物。 這使我們不僅可以實現代碼和設計之間的無縫奇偶校驗，還可以使兩者保持不間斷的同步。

UXPin 支持存儲在 git 存儲庫中的 React 組件的設計庫，以及與 Storybook 的強大集成，允許使用來自幾乎任何流行的前端框架的組件。 如果您想自己嘗試一下，可以在 UXPin 網站上請求訪問它：

• 請求使用 Merge 技術訪問 UXPin →

在 UXPin 中將活動組件與設計合併只需要很少的步驟。 找到正確的組件後，您可以通過單擊將其放置在設計畫布上。 它的行為與您設計中的任何其他對像一樣。 它的特別之處在於，即使是設計的一個組成部分，您現在也可以像在代碼中一樣使用和自定義它。

UXPin 使您可以訪問組件的屬性，允許您更改其值和變量，並用您自己的數據填充它。 一旦啟動原型，組件的行為將完全符合預期，並保持所有行為和交互。

在您的設計中，您可以混合和匹配無限數量的庫和設計系統。 除了添加您自己的庫之外，您還可以在各種開箱即用的開源庫中進行選擇，例如 Material Design、Fluent UI 或 Carbon。

“按原樣”使用組件也意味著它應該根據上下文的變化來表現，例如視口的寬度。 換句話說，這些組件是完全響應和適應性強的。

注意：如果您想了解有關使用 UXPin 構建真正響應式設計的更多信息，我強烈建議您查看這篇文章。

上下文也可能意味著主題。 無論誰試圖在設計工具中構建（並維護！）一個主題化的設計系統，或者至少創建一個允許您在淺色和深色主題之間輕鬆切換的系統，都知道這項任務有多麼棘手，以及它有多麼不完美。結果通常是。 沒有一種設計工具針對開箱即用的主題進行了很好的優化，旨在解決該問題的可用插件遠未完全解決。

由於具有 Merge 技術的 UXPin 使用真實的活動組件，您還可以將它們主題化為真實的活動組件。 您不僅可以根據需要創建盡可能多的主題，而且切換它們可以像從下拉列表中選擇正確的主題一樣快。 （您可以在此處閱讀有關使用 UXPin 進行主題切換的更多信息。）

優點

具有 Merge 技術的 UXPin 允許在設計和代碼之間實現前所未有的同等水平。 在設計過程中忠實於源頭為過程的各個方面帶來了無可挑剔的優勢。 設計師可以放心地進行設計，因為他們知道他們所做的不會被誤解或錯誤地開發。 開發人員不必將設計轉換為代碼，也不必糾結於不明確的邊緣情況和未發現的場景。 最重要的是，每個人都可以參與工作並使用實時組件快速原型化他們的想法，而無需了解底層代碼。 實現更民主、更參與的過程更觸手可及。

將您的設計與代碼合併不僅可以改善設計人員與團隊其他成員的合作方式，還可以改進他們的內部流程和實踐。 對於那些專注於大規模優化設計工作（有時稱為 DesignOps）的人來說，採用 Merge 技術的 UXPin 可以改變遊戲規則。

使用正確的事實來源可以莫名其妙地更容易保持團隊中不同人員製作的作品之間的一致性，幫助他們保持一致，並使用一套聯合工具解決正確的問題。 不再有帶有少量不請自來的變體的“分離符號”。

歸根結底，我們得到的是巨大的時間節省。 設計人員可以放心地使用組件及其開箱即用的功能，從而節省時間。 他們不必在組件更改時更新設計文件，也不必記錄他們的工作並“揮手”向團隊其他成員解釋他們的願景。 開發人員通過以一種無需猜測和額外修補的即刻可理解的方式從設計師那裡獲取組件來節省時間。

負責測試和 QA 的人員可以節省時間來尋找設計和代碼之間的不一致並確定植入是否按預期進行。 利益相關者和其他團隊成員通過更有效的管理和更輕鬆的團隊導航來節省時間。 更少的摩擦和無縫的流程限制了團隊成員之間的挫敗感。

缺點

不過，利用這些好處需要付出一些入門成本。 要在您的流程中有效地使用諸如 UXPin 之類的工具，您需要有一個現有的設計系統或組件庫。 或者，您可以將您的工作基於始終提供某種程度限制的開源系統之一。

但是，如果您首先致力於構建一個設計系統，那麼在您的流程中使用帶有 Merge 技術的 UXPin 幾乎不會產生額外成本。 有了一個完善的設計系統，採用 UXPin 應該不會是一件困難的事，而這種轉變的好處可能會被證明是巨大的。

概括

設計系統的廣泛採用解決了媒體開發人員和設計師工作的問題。 目前，我們可以觀察到向更統一的流程轉變，這些流程不僅改變了媒體，還改變了我們創造它的方式。 使用正確的工具對於這種變化至關重要。 採用 Merge 技術的 UXPin 是一種設計工具，它允許將設計與實時代碼組件相結合，並大大縮小了設計和開發操作領域之間的差距。

下一步在哪裡？

• UXPin 合併：故事書集成
  了解 Storybook 集成如何幫助您的產品團隊並嘗試一下！
• UXPin 合併：Git 集成
  請求訪問以查看與 Git 存儲庫的集成如何工作。
• UXPin Merge 短視頻講解
  作為“交互式設計系統：強生網絡研討會”的一部分。
• 代碼設計：UXPin 合併教程
  使用 Merge 技術的 UXPin 介紹性教程。
• 使用 UXPin 合併的響應式設計
  使用合併技術使用 UXPin 製作完全響應式體驗的原型指南。