A giant leap for the design system at Dynatrace

The complexity of our business intelligence platform at Dynatrace led us to adopt a DesignOps mindset early on. The direct result of this is “Barista”, our design system. Barista enables all of us to ship consistent, high-quality design and frontend code to our customers.

The upper landing page of our design system “Barista”

Barista needs to scale to match the rapid growth of Dynatrace, and this means we need to make it as easy as possible to contribute both code and content to the design system. Over the last few months, the DesignOps team has been buckling down to deliver some significant improvements and changes to our beloved design system…

Switching to open source for total transparency

In December 2019 we moved our internal angular components repository to GitHub and made it publicly available. The repository contains the Barista design system as well as our angular components library. One of the main reasons for switching to open source was for the opportunity to live and breathe the open source development workflow. Barista welcomes contributions from everyone willing to help out and by allowing greater opportunities for collaboration we can adopt the workflows that are necessary to scale. Making Barista public was a huge milestone for the DesignOps team, and internally, we referred to this as

Operation Full Barista

This required us to have everything we do — from our entire CI / CD pipeline to issues, to pull requests — publicly available on GitHub. The weeks after the initial move to GitHub were some of the most challenging times in recent memory. On the one hand, we had to support the internal version that was already actively being used in production, and on the other hand, we also had to build an entirely new CI / CD pipeline and adjust our workflows for the open source world.

Screenshot of our build pipeline on CircleCI

We pretty much had to change the way we work, develop, build, and communicate — all at the same time.

Admittedly, we are still in the early stages of open source development and are still learning. Switching to open source development changes the way you work. Not everybody who wants to be involved in the project is sharing an office with you, especially in times where nearly everyone is working remotely. Somebody might want to contribute from the other side of the world, from a completely different timezone. Writing everything down and documenting decisions is essential. A recent quote that resonated with me about going open source is:

If it’s not written down, it does not exist.

When we first started, it felt a bit odd and slow to write everything down, and to painstakingly document every, single decision that was made, but in the long run, it has helped tremendously to have an issue or document that we can refer to when something comes into question weeks after a decision was made. Once we got into our stride with GitHub, we focused on addressing some key pain points and highly requested features.

Improved editor experience with (almost) instant content updates

We try to listen to everybody that uses Barista and are constantly making improvements to deliver better components and better user experience, for both consumers and contributors. One message we heard over and over again was:

It is really hard to update content in Barista.

This was true, no question about it. It is especially critical for our user experience (UX) colleagues to be able to update the content quickly and consistently, to deliver the latest research outcomes and best practices to the Barista audience. Our audience consists predominantly of developers, who are interested in both the UX content and the API definitions that are available on Barista. Since our design system offers both content types, there are a few unique challenges that we had to solve:

Parts of the content in Barista, like the API definitions for components, have to be in sync with the version of the component library.
These parts are treated the same way as code changes. They are versioned together with the code and need pull request reviews to get merged.

UX related content and development information should not be split up
A while ago we had different tabs in Barista showing UX content and the API in separated spaces. This made it very hard to know where to look for information like usage guidelines for a component. It is relevant for UX designers and developers alike. So separation does not make sense.

With these two requirements in mind, and the goal to make it easier to change the content we started building a new version of Barista.

We sliced-up the page by adding placeholder areas inside the versioned content that can be filled with UX defined content. This enables us to combine multiple content sources on the same page.

Part of our checkbox readme containing a ux snippet placeholder

The UX content is served from a content management system (CMS) and can be edited in a markdown editor. Once saved the build combines the versioned content with the UX content and publishes a new version automatically. This enables all our content editors to update their content more frequently and increases overall content quality.

By adding a CMS and placeholders into versioned content we were able to significantly improve the editor experience but still fulfill all requirements.

Easy prototyping & issue reproduction

We wanted to get rid of the local setup step to run the examples locally. Setting up the environment locally before you can start experimenting creates a barrier of entry we wanted to get rid of. We already have around 150 interactive examples for our components available on our design system that we wanted to leverage for prototyping. Another cool benefit of eliminating a manual setup is easier reproduction for bug reports. We, as the DesignOps team, depend on bug reports that we can reproduce in isolation. Providing an isolated example takes time and effort for the developer who reports a bug. Therefore we needed an easy way to start from an example and add the necessary code to reproduce an issue.

To enable everyone using Barista we added a new shiny button to all interactive examples.

A table example and the button to open the isolated stackblitz example

The button above takes you to the example generated in an online IDE. No need to manually install dependencies, manage a local version, or knowing where to find the example in code.

Stackblitz running an isolated Barista example

One-click and you can start prototyping! Everything is automated and always in sync with the latest version of the components library.

Change is our new normal

We are very proud of these accomplishments that increase productivity and reduce pain points for everyone involved. We took a small step as a team, but we feel that this is a giant leap for Barista right now.

Barista will always be a continuous effort for many teams and we could not do it without the help of so many awesome contributors. A big thank you to everyone who helps us out to provide Barista to everyone at Dynatrace. Barista needs your help — any contribution is welcome, no matter how small. Did you find a typo on one of our pages? Create a pull request or an issue and help us improve the design system for everyone.

We try to improve Barista daily and we want to hear your input. If you have ideas about what to improve or things that you are missing — please contact us. We are more than happy to hear your thoughts.

A giant leap for the design system at Dynatrace was originally published in Dynatrace Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.