How to connect DevOps to your design system

Last night, in a moment of inspiration, I developed an application. I started at six o'clock in the evening, and at one o'clock it was already deployed with all the bells and whistles, like unit and acceptance testing, SSL certificates and running in Kubernetes. 

In other words, it only took seven hours from an idea to production. And before being ready, I had already had a number of successful deliveries.

How is this possible, you might ask?

The answer is having the Continuous Delivery pipeline connected to a design system. The fact is, that DevOps has actually started even before the design phase. Therefore, implementing DevOps into the design system enables you to provide a solid starting point for your delivery pipeline and so kickstart new innovations faster.

A design system is the voice of the company 

Design systems have been a hot topic for a while already. They were born from the need of having uniform styles, and are a way for an organization to harmonize the expression of itself in a graphical format.

There are various definitions for the term, but essentially a design system is a set of elements that allow teams to design and develop a product, while following the uniform voice and identity of an organization or a company. Today, it's more and more important to have a harmonious library of styles and components to be used when new services are created, or when changes are made to an existing application. Simply put, a design system is a library of components that are shared, evolving and reusable.

Design systems: open-source and self-constructed

There are roughly two different types of design systems:

1. Open-source, community-driven design systems, that are available for everybody, such as Google Material Design, Carbon, or Polaris.
2. Design systems that have been developed exclusively for an organization or by the organization itself, such as https://unity.com/design-portal or https://www.eficode.com/cases/vaisala 

One of my favorite open design systems is the Australian Government Design System. It includes the design, the HTML and CSS examples, and also the React components (React is one of the most popular JavaScript user interface frameworks, that was created by and is maintained by Facebook).

A good design system should include not only the design, but also the code behind the design. If you have a button, you would have, for example, Javascript / React, HTML, and CSS code pre-made for the developers to represent that button and its behavior.

DevOps starts from the design phase

Traditionally, there has been a gap between the design phase and the development phase. This is due to the fact that design is driven by the UI people, who love working with user interfaces, while DevOps has traditionally been the responsibility of the operations and backend development people.

A proper design system, which includes DevOps, is an efficient way to bridge this gap.

When you do User Experience (UX) design – i.e., the actual graphical design work for an application or a service – you eventually have to transform it into digital format. Various design applications, such as InVision, Figma, or similar, already do some of the work for the designers and developers before the development stage. The connection actually starts when they start implementing the design, which means that DevOps starts already from the design phase.

Do good design systems support development and deployment?

Now, you may wonder what a well-implemented design system looks like when it is seamlessly integrated into DevOps practices and tools. A proper design system that efficiently supports DevOps includes:

• The components written as React components, including the suitable styling and interaction.
• Unit testing, such as the UI component tests written in Jest. 
• Examples of how the user interface is connected to the actual backend or the core of the application.
• Connection to the infrastructure / Infrastructure as Code.
• The delivery pipeline, and the connection of your application into the whole automation framework. 

As you start working on an application in a well-implemented design system, the application will be in the production environment at the exact same moment as you start your work. This is something that we at Eficode call zero-day delivery, and it is precisely what I tried out last night when I developed my application in just a few hours. 

You kickstart the application from a template, which is based on the design system, and after the first commit, it is already connected to your Continuous Delivery pipeline and delivered into the production environment.

Delivery and release are not the same thing

This way of working takes away the tension from situations that have traditionally been considered the scary moments of truth – you know the moment when you hit the button, release your application to your users, cross your fingers and pray that everything goes well.

I recommend separating the words ‘delivery’ and ‘release’ from each other. Delivery should be the uninteresting part as you should be continuously delivering the features being implemented all the time.

With Continuous Delivery (or deployment), you deliver a working application, but unfinished features, into the production environment. Then you either hide the functionalities from your users, or just keep them in the background. Releasing happens when you actually release those features for your users.

When working this way, failing is no big deal, because rolling back or fixing things is fast. And then on the day of the release, you already know that things work, as you have made your mistakes earlier.

Good design systems can change corporate culture

This modern and fluent way of working needs to be supported by a change of culture within the company. People from different areas need to collaborate in order for DevOps and design systems to be integrated. You need to create a feedback loop between the people who develop the design system and those who adopt it.

There is not one single way of doing this, but rather a host of questions to be answered before you decide how to proceed:

• What practices are needed to actually develop, implement and share the design system and the components inside it?

• Do you have a centralized team that is responsible for the design system?

• Do you have your own Continuous Delivery pipeline for the design system, where you can collaborate using, e.g., pull requests from the developers?

You also need to decide whether you make the design system community-driven, such as the Australian Government design system. There, anyone can go ahead and make a pull request, and then you have a few people who decide if it should be approved and merged into the design system or not.

Start with a practice community or a pilot group

Implementing DevOps into the design system does not have to be a big endeavor. Most companies, at least the larger ones, already have a design system in place. It might just be graphical guidelines, or perhaps their HTML and CSS libraries are connected. Probably, there are also applications that have been developed according to the design system already, so you do not have to start from scratch.

One way to develop the design system is to start a practice community that consists of like-minded individuals who find a common cause to do the job.

Another way to do it is to just start with one of your current projects that have people who are interested and capable of trying it out.

Usually, these things are relatively simple to try out and implement. The hard part is changing the corporate culture and practices. That is why we at Eficode prefer piloting. If you have a new application on the way, I would start developing the design system around that application.

When you put your Continuous Delivery pipeline in place, you can reach what we call zero-day delivery. In other words, when you start designing a new service, you are already in production.