偉大的產品離不開開發和設計的良好溝通。無論你是誰，歸根結底，我們都是在創造軟件產品。有了設計系統之后，溝通將變得更加簡單。

但是誰將建立起設計和開發之間的溝通橋梁呢？

我把這些推動者稱為 Design Systems Ops。Design Systems Ops: 規?；匮b運（設計）。

Design Systems Ops 是設計團隊的一部分，他需要足夠了解設計，并且要了解他們試圖概念化什么。同時，Design Systems Ops 需要理解工程師的需求和定義方法，這將有助于設計系統的裝運和規?；?。在某些程度上，一個 Design Systems Ops 是兩個世界的翻譯。

大多數公司存在的問題

在大多數組織流程結構中，從概念到用戶的過程是相當脫節的，以致于產品最終完成時和設計師的初衷很不一致。

從概念到用戶的一種典型流程是：越靠近用戶階段，還原度越低。

信號（概念）受到干擾（低效率）而逐漸變弱，產品在一個非常低的還原度中結束。這種失敗對公司創造高質量產品的能力有著巨大影響，并且造成巨大商業機會的浪費。

設計系統能干什么

風格指南、模式庫、設計系統等都有助于圍繞一種通用的設計語言去規范化實踐和設計模式。而語言障礙恰恰是大多數低效率的誘因。

從顏色命名、對象、慣例、組件等開始，到記錄最好的最細枝末節的體驗，比如動畫定時或表單元素的圓角度值。

一個好的設計系統能讓設計決策更快。（比如“ call to action 應該是什么顏色”）。從而設計師可以在同樣長的時間里，將更多的時間放在（優化）用戶流程和對多種概念的探索上。

一個好的設計系統也是幫助開發團隊在開發階段找到獲取設計的唯一來源。這對一致性很有好處，因為所有的 call-to-action 都將表現一致。

設計系統能在這個過程中減少做無用功：還原度一路上將保持大致穩定。
一些設計系統也用代碼來傳達設計模式。這些設計系統從概念開始階段，到原型階段，直到實現階段都能證明其價值。當公司遵循這種方式，這種方式對于生產效率和還原度都是很有幫助的。

一個設計系統不是一個項目，它是一個產品，服務型產品?－－?Nathan Curtis

然而，一些設計系統并沒有獲得它們應有的贊許，卻淪為設計模式的光榮榜，而這些模式離真正的產品代碼非常遙遠。這是因為對于幾個設計師和工程師的部分投資 是不足夠的：一個設計系統不是簡單一個項目，它是一個產品(或就像 Nathan Curtis說的： “一個設計系統不是一個項目，它是一個產品，服務性產品?！?。為了讓設計系統在交付流程的不同階段都顯現出對應的價值，它需要適當規劃，用戶研究和方法（和很多熱愛）。那些創造出最優設計系統的團隊，都將設計系統的目標定位為有生命力的設計系統。

引入 Design Systems Ops

有生命力的設計系統和其他設計系統之間存在的差距是巨大的。這主要是因為開發團隊和設計團隊缺乏良好的溝通。最終，產品將用代碼的格式呈現，在這過程中影響效率的任何事情都應該被檢查。通過引入一個 Design Systems Ops 的角色（靈感來自DevOps 運動），能夠改善這些低效：

通過在設計和開發間引入一位中間者，進一步減少低效，增加軟件交付的還原度。

來自于設計系統兩邊的許多問題：

• 我從哪里可以找到標記、顏色面板、數值、圖標、模式、斷點？
• 在制作原型時、在產品中、或者在 Web 視圖中我應該如何加載 CSS？
• 加載字體圖標的最佳方式是什么？
• 它們對性能有什么影響？
• 我應該在哪里發現文件錯誤，又應該在哪里尋找其他人解決自身問題的辦法（問題追蹤，知識基礎）？
• 我該如何為設計系統做貢獻（修復 bug 、增加一個圖標）？
• 我是一個參與者，我該怎樣在多種環境中測試我的代碼而不至于出錯呢？
• 我是一個開發者，對于設計系統我該知道些什么？
• 我是一個設計師，我該怎樣迭代瀏覽器中的現有模式？
• 從 v1.0 到 v2.0 的升級路徑是什么？
• 0.5.0 版本的文檔在哪里？

我學習了一些像 Bootstrap 和 Material Design Lite 這樣的開源項目。在《衛報》, 我開始構建起設計和開發的橋梁，里面提到主要采用 Sass 。在金融時報為 Origami 項目工作時也幫助我發現規?；O計的新思路。 我今天工作的地方：Salesforce，有一個團隊的工程師作為 Design Systems Ops，熱衷于將更快更好的代碼交付給用戶。

在回顧我過往如何規?；O計的經驗之后，這些都是 Design System Ops 可以做的工作：

• 本地開發環境（源映射，無刷新重載，速度）
• 托管（放置設計展示和文檔）
• 代碼演示（比如 CodePen、JS Bin）
• 技術文檔（安裝、問題診斷）
• 前端自動化測試（可訪問性、集成）
• 跨瀏覽器自動化測試
• 視覺回歸測試
• 代碼風格檢查 (我之前寫的)

前面這一系列是以前端為中心的，但是這里有些更接近后端的：

• 構建系統
• 資源儲存和分布（CDN、壓縮）
• 性能測試（資源大小、服務器加載、CDN 響應時間等等）
• 版本流程（比如 git、SemVer）
• 發布流程 （比如 持續開發、持續集成）
• Testing/Staging階段環境
• 展現測試和性能結果（比如 儀表板、郵件）

或者，更靠近市場營銷這邊的事情（開發宣傳）：

• 構建示例
• 幫助開發者實現這套設計系統
• 給開發社區布道這套設計系統

就像前面提到的，在這些方面有堅實的解決方案能很大地幫助設計團隊提高交付質量，并提高工作的速度和信心。這是為什么我相信在設計團隊中有個好的參謀將增加項目成功的可能性。

總結

隨著越來越多的公司構建屬于自己的設計系統，他們也開始顯示出增加技術人員去支持設計的工作和工具的興趣。因為它只是這個角色的開始，有些問題也讓我夜不能寐。

• Design Systems Ops 能在其他方面做些什么？
• 什么工具能幫助小型團隊在成本有限的情況下遵循這個路線呢？
• 除了開發速度，還有那些方面應該是Design Systems Ops應該評判的？

我非常樂意聽聽你的看法，如果你也在舊金山，來喝杯咖啡聊一聊。

Design Systems Ops 并沒有我憑空產生的想法，要理解我想法的由來，你可以閱讀Ian Feather’s awesome presentation about Front End Ops.

同樣， 聽 Design Details 播客，全世界許多優秀的設計師都在那里分享他們創造設計系統和風格指南的經驗。

原文鏈接 : Design Systems Ops

原文作者 : Kaelig

譯文出自 : 掘金翻譯計劃

譯者 : L9m

校對者: JasinYip, shenxn, Ruixi

本文由 @掘金翻譯計劃 原創發布于人人都是產品經理。未經許可，禁止轉載。