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