by 2017.9.18 原文翻譯遠舟阿里濱江
by 2019.3.21 格式化為外刊評論版遠舟阿里西溪

設計系統Ops(協同)

作者： Kaelig翻譯：周源

Design Systems Ops:規模化的（設計）輸出。

建設最優秀的產品需要一個有良好溝通方式的設計師和工程師團隊。不論你是設計師還是工程師，目標都是為了生產和交付軟件產品、當一個Design System被用在設計與開發中的時候，溝通會得到改善。

但是誰來做Design System 團隊（通常在UX團隊中）和工程師團隊之間的橋樑，來抹平兩者之間的間隙呢？ <譯者： Fusion 的模式不同，Fusion 是設計師和工程師完全對等的合作產出的Design System>

我將其稱為Design Systems Ops。

Design System Ops 是設計系統團隊的一份子，他不僅要能理解設計師傳達的理念，同時，Design System Ops 需要理解工程師的需求，並且能夠制定一種機制來幫助Design System 的輸出和規模化。所以在某種程度上，Design System Ops 是兩個世界（設計師和工程師）之間的翻譯器。 <譯者：我認為DesignSystem 本身就應該是設計師和工程師之間的翻譯器，通過各種方式（下面又有講）來實現設計師和工程師對於UI 的統一認知。 >

大多數公司遇到的問題

在很多公司裡，產品從設計到交付的過程脫節非常嚴重，以至於最終產品看起來和設計師一開始的設想完全不同。 <譯者：脫節的因素有很多，脫節導致的問題也有很多；還原度問題只是其中一種，而影響還原度的問題也很多，脫節也只是其中一種。例如：產品與體驗的衝突，技術門檻，投入產出比等等。 >

一個典型的設計到用戶之間不斷產生差距的流程：產品交付越到後期，還原度越差。

設計目標（理念）在產品開發過程中（由於低效協作）不斷損耗，最終以很低的還原度完成。這種“低效協作”對開發高品質產品有巨大的負面影響，同時存在巨大的商業機會成本。

Design System有什麼用

例如風格指南，模式庫，設計系統：所有能夠幫助規範化的實踐或類似設計模式的通用語言。

設計系統可以以這種方式開始，例如：定義顏色，對象，約定，組件...來記錄最佳的體驗細節，例如動畫時長、表單元素的圓角弧度等。

一個好的設計系統有助於更快的做出設計決策（例如，行動點的顏色應該是什麼）。設計師可以花更多的時間在用戶流程上，並且花同樣的時間嘗試多種設計理念。

一個好的設計系統也可以為工程師在實現（產品）時提供統一參考。這樣全站各種屏幕下的所有的行動點都看起來是相同的，這對一致性很有好處。

Design Systems能夠幫助減少“損耗”：還原度能夠在整個過程中保持穩定

有些設計系統也使用代碼來保證設計模式的落地。這些設計系統的內容從設計理念階段，到原型，到實現階段都是有價值的。當公司使用這種方式時，產品的生產效率和還原度都會有所提升。

Design System不是一個項目。它是一個產品，服務於眾多業務- Nathan Curtis

然而，一些設計系統並未得到應有的重視，最終這些模式被作為一種“榮譽”束之高閣，離真實生產環境的代碼越來越遠。其原因是設計師和前端對這部分的關注是不夠的：設計系統並不是一個簡單的項目，它是一個產品（就像Nathan Curtis 所說：“A Design System isn't a Project. It's a Product , Serving Products.”）。對於一個設計系統而言，如果要在產品交付的各個環節體現它的價值，那麼需要做適當的規劃、用戶研究以及一些方法（更多的關注）。我們把這件事稱之為設計系統優化，由一個團隊提供支持，他們有明確的目標：可持續的設計系統。

Design Systems Ops介紹

在可持續的設計系統與現實世界之間是存在很多低效的，這些低效率大部分原因是設計團隊和工程團隊之間缺乏溝通。在產品完成開發準備上線之前，整個產品研發過程中任何導致低效的部分都應該拿出來review。我介紹一個Design System Ops的角色（靈感來自於DevOps ），可以幫助減少這種低效：

進一步減少低效，通過引入一種媒介（方式）促進設計與工程之間的溝通，以此增加軟件交付時的還原度

許多問題來自設計系統的雙方：

• 我到哪裡找到標註，色板，色值，圖標，模式，斷點相關的訊息？
• 當我在原型、線下開發、線上web中怎麼加載CSS？
• 最優的加載字體，顯示Icon 的方式是什麼？
• 他們對性能的影響是什麼？
• 我應該在哪裡提交bug，去哪裡找其他人的問題和解決方案（issue 跟踪，知識庫）？
• 我該通過哪種方式為Design System 貢獻自己的力量（修復Bug, 增加Icon）？
• 作為一個貢獻者，我該如何在多種環境下測試我的代碼，來保證不會產生非兼容性改動？
• 作為一個開發者，我應該知道設計系統的哪些內容？
• 作為一個設計師，我該如何在已有的設計模式的基礎上進行迭代？
• 從v1.0 到v2.0 的升級方案是什麼？
• 在哪裡能找到0.5 版的文檔？

我學習並關注了大量的開源項目，例如： Bootstrap ， Material Design Lite 。在衛報，我主要通過Sass的方式來縮小設計師和工程師之間的差距。在金融時報研發Origami時，幫助我發現了擴展性設計的的新思路。現在，我在Salesforce工作，這裡有一個工程師團隊承擔了Design System Ops的職責，他們都熱衷於給用戶提供更快，更好的代碼。 （這是在打廣告麼？）

通過之前的工作經歷，我知道瞭如何實現擴展性設計，這裡是一些Design System Ops 職責內的事情：

• 本地開發環境（sourcemaps，live reload, 效率）
• host 綁定（設計showcase，文檔）
• 代碼場景，片段編輯器（例如，CodePen, JS Bin）
• 技術文檔（如何安裝，常見問題）
• 前端自動化測試（無障礙，集成測試）
• 多瀏覽器自動化測試
• UI 回歸測試
• 代碼格式化鉤子（ 我之前寫過相關的文章）

上面的內容是以前端為中心的，但下面這些更貼近運維：

• 系統建設
• 靜態資源存儲，分發（CDN，壓縮）
• 性能測量（靜態資源大小，服務器加載，CDN 相應時長）
• 語義化開發流程（例如，git, SemVer）
• 發布流程（例如， 持續交付， 持續集成）
• 測試/預發環境
• 測試數據、性能數據透出（例如，報表，郵件）

或者，更貼近運營方面的事情（更提倡開發者）：

• Demo 開發
• 幫助開發者實現Design System
• 在開發者社區佈道Design System

如上所述，通過這些領域強有力的方案能夠幫助設計系統提高他們的交付質量，速度以及他們持續運營的信心。這也是為什麼我堅信Design System 中有一個好的Ops 可以強有力的幫助項目獲得成功。

結語

隨著越來越多的公司開始建立自己的設計系統，他們漸漸有興趣增加一個技術團隊來支持設計工作以及工具化。現在還是Design System Ops 的早期階段，我們的社區中也存在很多問題。但讓我每晚持續思考的幾個問題是：

• Design System Ops是否還有其他方面的幫助？
• 什麼樣的工具能夠幫助小團隊用盡量低的成本去實現Design System Ops?
• 除了開發速度之外，Design System Ops還能在哪些方面提供評估（標準/能力）？
  我很想在Twitter( @kaelig )上看到你的想法，如果你在舊金山，為啥不來杯咖啡聊一聊？更新：到目前為止，反饋之多讓我驚訝，導致我們不得不建了一個網站，我們在網站上列出了相關（Design System Ops）的資源
  這些Design Systems Ops 的東西並不是我憑空想出來的，如果想更深入的了解我想法來源，可以閱讀一下Ian Feather有關前端-Ops的幻燈片，很贊。
  此外，一定要聽Design Details播客，這裡有一些世界上最好的設計師分享他們創建設計系統和設計指南的經驗。
  最後，如果你想討論設計系統或想了解更多關於設計系統的訊息，不要錯過16年3月31號至4月1號在舊金山的Clarity Conference（由設計系統女王（jina）組織）。更新：會議現在已經結束了（會議非常棒，明年你應該來！），不要錯過視頻（今年晚些時候在大會的網站上可以看到）。
  更新：Clarity Conference會在2017年11月28號開始，會場見！
  配圖： Bernard Gagnon (CC BY-SA 3.0).

原文

Design Systems Ops

Design Systems Ops: shipping (design) at scale.

The best products are built by teams with great communication bridges between designers and engineers. Whether you're one or the other, at the end of the day… we're all shipping software. When a Design System is invited to the party, communication is even better.

But who will bridge the gap between the design systems team (often part of the UX team) and the engineering team?

I call these enablers Design Systems Ops.

A Design Systems Ops is a person who is part of a design systems team, who needs to get into the designers' shoes, and have a feel for what they are trying to conceptualize. At the same time, Design Systems Ops need to understand the engineering requirements and define methods that will help shipping and scaling the Design System. In a way, a Design Systems Ops is the translator between these two worlds.

The problem with most companies

In most companies, the delivery process from the concept to the user is so disjointed that the products feel nothing like what the designers first intended.

A typical flow of the distance between a concept and the user: fidelity fades away as it gets closer to the user.

The signal (the concept) fades as it goes through perturbations (inefficiencies), and ends up into the product in a much lower fidelity. Such inefficiencies have a massive impact on the company's ability to ship high quality products, which has a huge business opportunity cost.

Where Design Systems help

Style guides, pattern libraries, design systems: all help normalize practices and design patterns around a common language.

Design systems can start with: naming colors, objects, conventions, components… down to documenting the finest details of the experience, such as animation timings or the roundness of corners on form elements.

A good design system helps make design decisions much faster (eg “what color should a call-to-action be”). Designers can then spend more time on user flows, and exploring multiple concepts in the same amount of time.

A good design system also helps engineering teams refer to a single source of truth at the implementation phase. This is good for consistency, as all call-to-actions, for example, will look the same across screens.

Design Systems reduce inefficiencies along the way: fidelity keeps a lot steadier along the way.

Some design systems also ship patterns using code. These design systems can prove to be valuable from the beginning of the concepting phase, to the prototyping phase, down to the implementation phase. It's a good sign for both productivity and fidelity when a company follows that path.

A Design System isn't a Project. It's a Product, Serving Products — Nathan Curtis

Yet, some design systems don't get the love they deserve and end up being glorified lists of patterns, afar from production code. That's because a partial investment from a few designers and developers is not enough : a design system isn't simply a project, it is a product (or as Nathan Curtis puts it : “A Design System isn't a Project. It's a Product, Serving Products.”). For a design system to show sustainable value at scale and at all phases of the delivery process, it needs proper planning, user research, and methods (and lots of love!). We'll call these optimal design systems, powered by a team that is given clear goals: living design systems.

Introducing Design Systems Ops

The remaining inefficiencies between the living design system and the rest of the world are numerous (as seen in the questions below), mostly because of a lack of good communication between design and engineering teams. At the end of the day, the product is shipping in the form of code, and anything that makes that process less efficient should be reviewed. Introducing a role of Design Systems Ops (freely inspired by the DevOps movement), can help mitigate these inefficiencies:

Reducing inefficiencies further, by introducing an intermediary to help communication between both Design and Engineering, increasing fidelity of software delivery.

Many questions arise from both sides of the design system:

• Where do I find markup, colors swatches, values, icons, patterns, breakpoints?
• How do I load the CSS if I'm prototyping, in production, in a web view?
• What's the best way to load fonts, to display icons?
• What is their impact on performance?
• Where should I file bugs and find where other people found a solution to their problems (issue tracking, knowledge base)?
• How do I contribute to the Design System (fix a bug, add an icon)?
• I'm a contributor, how do I test my code in multiple environments and make sure I didn't break something?
• I'm a developer, what should I know about the design system?
• I'm a designer, how can I iterate in the browser on an existing pattern?
• What is the upgrade path from v1.0 to v2.0?
• Where is the documentation of version 0.5.0?

I've learned a lot watching open source projects such as Bootstrap and Material Design Lite . At the Guardian, I started bridging the gap between designers and developers , mostly using Sass. Working on Origami at the Financial Times then helped me discover new ways of thinking about scaling design. Where I work today, at Salesforce , there is a team of engineers filling the roles of Design Systems Ops, who are all passionate about shipping faster and better code to the users.

After looking at how the scaling design worked in my previous experiences, here are some responsibilities that could fall under Design System Ops's umbrella:

• Local development environment (sourcemaps, live reload, speed)
• Hosting (for design showcases and documentation)
• Coding playgrounds (eg CodePen, JS Bin)
• Technical documentation (installation, troubleshooting)
• Front-end automated testing (accessibility, integration)
• Cross-browser tests automation
• Visual regression testing
• Code style linting ( I wrote about it before )

The above set of responsibilities is pretty front-end centric, but here are a few more that are closer to the metal:

• Build systems
• Asset storage and distribution (CDN, minification)
• Measuring performance (assets sizes, server load, CDN response times…)
• Versioning flow (eg git, SemVer)
• Release process (eg continuous deployment , continuous integration )
• Testing/staging environments
• Surfacing test results and performance results (eg dashboards, emails)

Or, closer to the marketing side of things (developer advocacy):

• Building demos
• Helping developers implement the Design System
• Evangelizing the Design System to the developer community

As mentioned previously, having solid solutions in these areas can massively help design systems teams improve the quality of their deliverables, the speed, and the confidence with which they operate. That's why I believe having good Ops as part of a Design Systems team will strongly set the project up for success.

Epilogue

As more and more companies build their own design systems, they are showing interest in adding technical people to support design efforts and tooling. It is early days for the Design Systems Ops role, and our community will have many questions. The ones that keep me up at night are:

• What other areas should Design Systems Ops help with?
• What tools can help smaller teams follow that path at a small cost?
• Aside from development speed, what other metrics should a Design Systems Ops be judged on?
  I'd love to read your thoughts on Twitter (@kaelig), and if you're in San Francisco, why nothave a coffeeand talk about it. Edit: the feedback has been amazing so far, and this even led toa websitewhere we'll list Design (Systems) Ops resources.
  I did not come up with all of this Design Systems Ops thing from nothing, and to understand better where I come from, you can readIan Feather's awesome presentation about Front End Ops.
  Also, definitely listen to theDesign Detailspodcast, where some of the very best designers in the world are bringing up their experience creating design systems and style guides.
  Finally, if you like talking design systems in general or want to learn more about them, don't missClarity Conference, March 31st–April 1st, 2016 in San Francisco (organized by the design systems queen herself:jina). Edit: the conference is now over (and it was great, you should come next year!), don't miss the videos (available on the conference's website later this year).
  Edit: TheClarity conferenceis back on November 28th, 2017. See you there!
  Picture: Bernard Gagnon (CC BY-SA 3.0).