彌合設計師和開發人員之間的鴻溝

本文由我們在 UXPin 的朋友提供支持，這是一個UI 設計和原型製作工具，可為您的原型提供應有的超能力：狀態、JS 表達式、變量、條件交互、Git 同步。 但本文不受UXPin的任何影響，僅代表作者的獨立意見。 謝謝！

在過去的幾年裡，我們的設計工具呈指數級發展已經不是什麼秘密了。 許多人擁有出色的組件管理和原型設計，您可能想知道下一步可能會發生什麼重大飛躍？

讓我們看一個典型的困境：

假設您是設計系統團隊的設計師，您正在創建組件、變體並花費大量時間來記錄所有可能會或可能不會更改的用例和屬性。 您最終完成了一個大型複雜組件並將其交付給開發人員。

我們怎麼知道代碼是同一個 UI？ 我們真的需要審核每一個組件嗎？ 我們如何在沒有不斷進行審查的開銷的情況下彌合設計與開發之間的差距？

所有這一切，你必須幫助教人們使用組件的不同方法、適當的間距和響應式 Web 的設計，當然，組件需要針對未來的用例進行更新。

有很多接觸點，涉及的人很多。 幾乎感覺我們越深入設計系統，每個人的開銷就越大！ 現在，隧道盡頭的一盞燈似乎在閃閃發光，下一件大事即將來臨。

所有混亂中的隱藏寶石

我最近有機會重溫了一個很久沒用過的工具——一個旨在彌合這一差距並最大限度地減少所有開銷的工具：UXPin。 一項名為“合​​併”的新功能已經推出，以幫助突破設計和開發的鴻溝，同時提高我們團隊所期望的敏捷性和質量。 這項新技術可能會讓一些人重新思考整個設計和工程團隊如何通過用例和構建組件進行協作和工作。

淘汰舊流程

如果我們看看當今大多數公司採用的當前流程，它可能會非常乏味，並存在一些明顯的缺陷。 當我們從頭開始創建新組件時，我們將設計組件的基礎級別、添加變體、編寫文檔、發佈到庫並將其交付給開發人員。 列出這個過程是冗長的，但幸運的是它只需要完成一次（我們希望）：

現在，當我們需要更新組件時會發生什麼？ 一個新的用例出現了，或者我們決定將我們的邊界從圓形更改為銳利？ 我們現在需要將變體添加到庫中，（可能）再次更新文檔，發布並交付給我們的開發人員。 呸！ 讓我們希望我們的設計師在組件重組的過程中沒有任何問題。

我差點忘了，我們還需要將更新發佈到開發庫！ 讓我們希望他們能夠在產品團隊按照自己的方式按時完成之前完成。

加入新流程

因此，您可能想知道，UXPin Merge 的技術如何幫助我們今天都採用的這種頂級流程？ 好吧，看看下面的圖表。 您可能會注意到不需要創建組件和變體（在大多數情況下）。 這個新流程減少了對自動佈局工具的擺弄，因為我們現在與開發人員建立了協同關係：

我們只需要設計文檔和實現所需的詳細程度。 可能不需要設計簡單的組件，例如按鈕或其他原子級組件。 當開發可以立即開始而幾乎沒有開銷時，為什麼還要浪費時間做雙倍的工作呢？ 在某種程度上，我們繞了一圈； 當靜態組件在文檔中只顯示一些交互時，我們正在回到舊的方式。

請注意，發佈到庫現在處於流程的末尾。 這是因為，一旦開發人員完成了組件，它現在可以利用 Merge 將其提供給 UXPin 中的設計人員，當然，您所有的產品開發人員都可以同時擁有它！

更新組件時，它與新組件基本相同，除了根據場景甚至可以跳過第一步。 例如，假設您要添加一個選項以將圖標添加到按鈕； 這不是需要設計的東西，而是需要與開發中的新朋友進行溝通。

雖然與您的開發人員形成了這種新的關係，但正式向設計人員發布組件的新方式可能只有在開發人員發佈時才會發布。 產品設計師詢問他們的產品開發人員是否可以使用某個組件的日子已經一去不復返了。 如果它在庫中，那麼它就可以在開發中使用，並且可供設計人員立即使用。

但是關於這個過程就足夠了。 讓我們來看看 UXPin Merge 是如何工作的。

管理圖書館

最好的部分是庫可以直接從您的代碼存儲庫中導入，例如 GitHub、Bitbucket、GitLab（僅適用於 React 組件），甚至可以從 Storybook 中導入。 創建庫後，您可以選擇命名庫。

使用 Storybook 導入時，過程非常簡單。 只需獲取庫 URL，UXPin 將為您完成剩下的工作。 使用 React 組件，使用 CLI，您可以通過指定 UXPin 庫的唯一令牌來控制發布的組件。

版本控制和測試

設計師和設計系統團隊最關心的問題之一是版本控制。 大多數問題都可以通過這個 UXPin 的合併功能來解決。 讓我們快速繪製一張圖片：

今天，當我們著手升級組件時，總是擔心會破壞可能被重命名和清理的組件或層。 組件的整體結構甚至可能發生，這通常會導致（在設計師方面）他們是否應該升級組件或堅持使用舊組件的焦慮。

但是，在開發組件時，只要屬性保持不變，組件佈局如何更改或組件的實際標記都無關緊要。 這反過來又使設計人員可以放心地將其組件升級到最新版本。

當然，在組件完全搞砸的極少數情況下，就像任何編碼項目一樣，它可以很容易地回滾並重新發布組件的舊版本。

測試更新

在測試新組件或更新時，今天並不是那麼容易。 我們顯然不能編輯現有的設計庫進行測試，因為這可能會意外發布，並阻止任何其他準備就緒的更新。 在新文件中創建組件，對其進行測試，然後嘗試在不破壞層的情況下處理合併回當前庫，這也是非常麻煩的。

對我們來說幸運的是，開發人員很久以前就發現了這個問題，並且它正好適合 UXPin 的 Merge 技術。 在測試新組件時，最好的做法是 fork 或分支代碼，並且這個新分支可能會發佈到 UXPin 內的測試環境中。 您的團隊可以對其進行測試，或者您可以授予您公司中的一小部分 Beta 測試人員的訪問權限。 一旦組件經過測試和試用，就可以快速引入組件並將其發佈到主設計庫，無需縫合。

用代碼設計

那麼，我們的地麵團隊成員是如何設計的，這項技術對他們意味著什麼？ 好吧，我很高興你問！ 從產品設計師的角度來看——沒有太大區別。 當設計人員使用 Merge 開發庫中的組件時，每個組件都會用橙色六邊形標記。 任何新的東西都將保持與開發人員庫完全相同的行為。

開發人員的組件可以定義限制，但方式很好。 一個常見問題通常是將圖標用作鏈接，而不是將圖標包裝在按鈕組件中。 如果我們只使用庫中的一個圖標，它會被鎖定，用戶可能無法添加交互：

或者，下面的圖標按鈕允許交互。 這使我們能夠真正細化和控制哪些組件應該與哪些組件交互，哪些不應該； 從標準和可訪問性的角度來看。

有了這些類型的限制，設計系統團隊就可以輕鬆地以正確的方式使用組件，如果它被覆蓋，從圖層面板中可以明顯看出某些東西是定制的。

不可觸摸

當您準備好移交給開發人員時，完成的原型可以顯示每個組件及其配置，以便複製並粘貼到開發人員的工具中并快速構建項目。 如果您的團隊還沒有組件庫，則 UXPin 帶有一個默認庫，或者您可以輕鬆地導入一些直接在 UXPin 中可用的公共庫。

可訪問性

說到可訪問性，它經常被忽略或者沒有足夠的時間來創建關於所有meta標籤、 aria標籤等的文檔。 設計人員不知道他們需要輸入什麼標籤，開發人員也不想經歷這些麻煩。

使用 UXPin，我們可以公開多個屬性，甚至是界面可能永遠不可見的元級數據，例如 ARIA 標籤。 然後設計師可以輸入所有需要的信息（或者如果你有幸在你的團隊中有一個文案），產品開發人員實施的開銷很少甚至沒有。

佈局、模板和網格

只需閱讀標題，您就知道接下來會發生什麼，而且我敢肯定您現在正在椅子上彈跳——我知道我是。 網格、佈局甚至頁面模板都可以作為“組件”拉入庫中，它允許用戶將組件帶入頁面的活動區域，並允許開發庫處理所有間距。

通用模板（例如登錄屏幕、完成頁面、表單、個人資料頁面等）也都可以用作拖放組件。 談論加快流程並減少設計中的人為錯誤！

結束時

如果您準備好邁出這一步，那麼嘗試新軟件和新流程來改善您的工作流程永遠不會太晚。 畢竟，我們都希望變得敏捷並儘可能地採用。 讓我們在團隊之間建立更牢固的關係，減少工作量並提高工作效率。 使用像 UXPin Merge 這樣的工具，我們更接近於一個更加無縫的工作環境。