1
| 本文作者： 稀土 | 2016-05-07 16:37 |
雷鋒網(wǎng)按：本文由掘金翻譯計劃譯者L9m譯自《Design Systems Ops》校對者：JasinYip, shenxn, Ruixi。本文首發(fā)稀土掘金，未經(jīng)允許，禁止轉載。
Design Systems Ops: 規(guī)?；匮b運（設計）。
偉大的產(chǎn)品離不開開發(fā)和設計的良好溝通。無論你是誰，歸根結底，我們都是在創(chuàng)造軟件產(chǎn)品。有了設計系統(tǒng)之后，溝通將變得更加簡單。
但是誰將建立起設計和開發(fā)之間的溝通橋梁呢？
我把這些推動者稱為Design Systems Ops。
Design Systems Ops是設計團隊的一部分，他需要足夠了解設計，并且要了解他們試圖概念化什么。同時，Design Systems Ops需要理解工程師的需求和定義方法，這將有助于設計系統(tǒng)的裝運和規(guī)模化。在某些程度上，一個Design Systems Ops是兩個世界的翻譯。
在大多數(shù)組織流程結構中，從概念到用戶的過程是相當脫節(jié)的，以致于產(chǎn)品最終完成時和設計師的初衷很不一致。
從概念到用戶的一種典型流程是：越靠近用戶階段，還原度越低。
信號（概念）受到干擾（低效率）而逐漸變?nèi)?，產(chǎn)品在一個非常低的還原度中結束。這種失敗對公司創(chuàng)造高質量產(chǎn)品的能力有著巨大影響，并且造成巨大商業(yè)機會的浪費。
風格指南、模式庫、設計系統(tǒng)等都有助于圍繞一種通用的設計語言去規(guī)范化實踐和設計模式。而語言障礙恰恰是大多數(shù)低效率的誘因。
從顏色命名、對象、慣例、組件等開始，到記錄最好的最細枝末節(jié)的體驗，比如動畫定時或表單元素的圓角度值。
一個好的設計系統(tǒng)能讓設計決策更快。（比如“call-to-action應該是什么顏色”）。從而設計師可以在同樣長的時間里，將更多的時間放在（優(yōu)化）用戶流程和對多種概念的探索上。
一個好的設計系統(tǒng)也是幫助開發(fā)團隊在開發(fā)階段找到獲取設計的唯一來源。這對一致性很有好處，因為所有的call-to-action都將表現(xiàn)一致。
設計系統(tǒng)能在這個過程中減少做無用功：還原度一路上將保持大致穩(wěn)定。
一些設計系統(tǒng)也用代碼來傳達設計模式。這些設計系統(tǒng)從概念開始階段，到原型階段，直到實現(xiàn)階段都能證明其價值。當公司遵循這種方式，這種方式對于生產(chǎn)效率和還原度都是很有幫助的。
一個設計系統(tǒng)不是一個項目，它是一個產(chǎn)品，服務型產(chǎn)品?—?Nathan Curtis
然而，一些設計系統(tǒng)并沒有獲得它們應有的贊許，卻淪為設計模式的光榮榜，而這些模式離真正的產(chǎn)品代碼非常遙遠。這是因為對于幾個設計師和工程師的部分投資是不足夠的：一個設計系統(tǒng)不是簡單一個項目，它是一個產(chǎn)品(或就像Nathan Curtis說的： “一個設計系統(tǒng)不是一個項目，它是一個產(chǎn)品，服務性產(chǎn)品。”)。為了讓設計系統(tǒng)在交付流程的不同階段都顯現(xiàn)出對應的價值，它需要適當規(guī)劃，用戶研究和方法（和很多熱愛）。那些創(chuàng)造出最優(yōu)設計系統(tǒng)的團隊，都將設計系統(tǒng)的目標定位為有生命力的設計系統(tǒng)。
有生命力的設計系統(tǒng)和其他設計系統(tǒng)之間存在的差距是巨大的。這主要是因為開發(fā)團隊和設計團隊缺乏良好的溝通。最終，產(chǎn)品將用代碼的格式呈現(xiàn)，在這過程中影響效率的任何事情都應該被檢查。通過引入一個 Design Systems Ops 的角色（靈感來自DevOps 運動），能夠改善這些低效：
通過在設計和開發(fā)間引入一位中間者，進一步減少低效，增加軟件交付的還原度。
來自于設計系統(tǒng)兩邊的許多問題：
我從哪里可以找到標記、顏色面板、數(shù)值、圖標、模式、斷點？
在制作原型時、在產(chǎn)品中、或者在Web視圖中我應該如何加載CSS？
加載字體圖標的最佳方式是什么？
它們對性能有什么影響？
我應該在哪里發(fā)現(xiàn)文件錯誤，又應該在哪里尋找其他人解決自身問題的辦法（問題追蹤，知識基礎）？
我該如何為設計系統(tǒng)做貢獻（修復bug、增加一個圖標）？
我是一個參與者，我該怎樣在多種環(huán)境中測試我的代碼而不至于出錯呢？
我是一個開發(fā)者，對于設計系統(tǒng)我該知道些什么？
我是一個設計師，我該怎樣迭代瀏覽器中的現(xiàn)有模式？
從v1.0到v2.0的升級路徑是什么？
0.5.0版本的文檔在哪里？
我學習了一些像Bootstrap和Material Design Lite這樣的開源項目。在《衛(wèi)報》, 我開始構建起設計和開發(fā)的橋梁，里面提到主要采用Sass。在金融時報為Origami項目工作時也幫助我發(fā)現(xiàn)規(guī)?；O計的新思路。 我今天工作的地方，Salesforce，有一個團隊的工程師作為Design Systems Ops，熱衷于將更快更好的代碼交付給用戶。
在回顧我過往如何規(guī)?；O計的經(jīng)驗之后，這些都是Design System Ops可以做的工作：
本地開發(fā)環(huán)境（源映射，無刷新重載，速度）
托管（放置設計展示和文檔）
代碼演示（比如 CodePen、JS Bin）
技術文檔（安裝、問題診斷）
前端自動化測試（可訪問性、集成）
跨瀏覽器自動化測試
視覺回歸測試
代碼風格檢查 (我之前寫的)
前面這一系列是以前端為中心的，但是這里有些更接近后端的：
構建系統(tǒng)
資源儲存和分布（CDN、壓縮）
性能測試（資源大小、服務器加載、CDN響應時間等等）
版本流程（比如git、SemVer）
發(fā)布流程 （比如 持續(xù)開發(fā)、持續(xù)集成）
Testing/Staging階段環(huán)境
展現(xiàn)測試和性能結果（比如儀表板、郵件）
或者，更靠近市場營銷這邊的事情（開發(fā)宣傳）：
構建示例
幫助開發(fā)者實現(xiàn)這套設計系統(tǒng)
給開發(fā)社區(qū)布道這套設計系統(tǒng)
就像前面提到的，在這些方面有堅實的解決方案能很大地幫助設計團隊提高交付質量，并提高工作的速度和信心。這是為什么我相信在設計團隊中有個好的參謀將增加項目成功的可能性。
隨著越來越多的公司構建屬于自己的設計系統(tǒng)，他們也開始顯示出增加技術人員去支持設計的工作和工具的興趣。因為它只是這個角色的開始，有些問題也讓我夜不能寐。
Design Systems Ops 能在其他方面做些什么？
什么工具能幫助小型團隊在成本有限的情況下遵循這個路線呢？
除了開發(fā)速度，還有那些方面應該是Design Systems Ops應該評判的？
我非常樂意聽聽你的看法，如果你也在舊金山，來喝杯咖啡聊一聊。
Design Systems Ops并沒有我憑空產(chǎn)生的想法，要理解我想法的由來，你可以閱讀Ian Feather's awesome presentation about Front End Ops。
同樣， 聽Design Details播客，全世界許多優(yōu)秀的設計師都在那里分享他們創(chuàng)造設計系統(tǒng)和風格指南的經(jīng)驗。
雷峰網(wǎng)特約稿件，未經(jīng)授權禁止轉載。詳情見轉載須知。
