Making Sense of Design Systems

At DataCamp our mission is to democratize data science education for everyone, and with over 2 million students worldwide we’re making rapid progress. Operating at this growth rate requires a lot of effort from everyone within the company and introduces a lot of exciting new challenges.

For the design team it means that we’re shifting from page-by-page design to a more scalable way of designing. Reusing existing components, reducing development time, improving usability, and increasing accessibility are becoming more and more important.

This article covers how we are starting to make sense of a design system.

What’s a design system?

A design system brings together all the components that are needed to distribute and reproduce a design solution. It’s not something new or exclusive to digital product design — a lot of examples can be found throughout history.

For example, the first Chinese empire had the problem that archers couldn’t use arrows from their comrades. Each arrow was specifically designed for a certain bow, so other arrows simply wouldn’t fit. The first Chinese emperor, Ying Zheng, standardized the way arrows were designed and it had a huge impact on their military conquests.

Back in the 50’s, each station of the NYC Transit System had its own signage. It caused a lot of confusion because every single station had their own way of navigating. As a result, a lot of people were hesitant to use the transit system because they didn’t understand how it worked. Massimo Vignelli and Bob Noorda created the NYC Transit Authority — Graphics Standards Manual, which documented how signs should be made and how they are supposed to be placed within stations. Over time this system has remained more or less the same and it’s still actively being used today.

Why should we have a design system?

When every page is designed in isolation, a lot of components have duplicates or similar alternatives. It makes a digital product hard to understand by users and hard to maintain by engineering. At DataCamp, we discovered over 20 different buttons throughout our product, each with their own quirks (different hover states, inconsistent disabled states, etc). It’s hard to keep track of all these components when a product is growing rapidly and it becomes near impossible to maintain. That’s where a design system kicks in.

For a digital product, a design system describes the user interface components that can be used to create an interface that solves a problem and will result in a cohesive experience for the user.

When a design system is executed well it will result in a cascading effect that …

• Decreases miscommunication
• Decreases implementation time
• Decreases maintenance work
• Decreases bugs
• Decreases support tickets
• Increases quality
• Increases efficiency
• Increases longevity
• Increases learnability
• Increases usability
• Increases accessibility
• Increases innovation
• Increases focus
• Increases sales

It’s not easy …

Creating, maintaining and enforcing a design system requires a lot of discipline and a continuous effort for everyone that’s part of the creation process. It’s not just design; engineering and product management are also important stakeholders. They all should be able to ask tough questions like: “Why are we building this?”, “Can we reuse this component somewhere else?”, “Do we already have something similar?”, “Does this custom component add enough benefit opposed to the effort we put in?”.

Design System 101 at DataCamp

1. Create A Component Inventory

Goal: Make sure everyone knows the existence and status of a component.

When I started at DataCamp there was a Sketch file that contained colors, icons, fonts and some basic components. It was far from complete but it was a good starting point. Front-end engineering also had a collection of components they used across projects.

Together we created an inventory in Airtable based on the components that are used in production. This gave the design team an idea of what already existed and prevented us from unknowingly creating new components. It also gave us an insight on how many similar components we had and how bad the situation really was.

2. Use Naming Conventions

Goal: Avoid miscommunication between Design and Engineering.

When we started comparing components we noticed Design and Engineering were not speaking the same language. For example the ‘primary color’ that was defined by design was the ‘secondary color’ in code. Things like this can lead to miscommunication when teams start to scale and causes confusion and frustration. We made sure that the same lingo is being used across the different teams.

3. Optimizing The Design Workflow

Goal: Avoid losing work and have a transparent workflow.

Working together as a design team introduces its own set of challenges. We used to store designs in Dropbox but when our team started to scale, the risks of losing work and the effort to keep track of changes increased dramatically.

Our design team was really open for a workflow change and we started using Abstract. It enabled us to properly version our designs, have a transparent workflow, and have more confidence while designing.

4. Better Documentation + Onboarding

Goal: Faster employee onboarding and prevent communication overhead.

We started documenting our process and design system using Slite. If we have to explain something more than once it should be documented and shared with the team. This avoids a lot of communication overhead and prevents information from getting lost.

5. Design Reviews

Goal: Setting expectations between Design and Engineering.

It’s important that design reviews happen in both directions. Designers should be able to review front-end, but front-end should also be able to review design. Designers have this urge to create something cool and new. Engineers should be able to ask tough questions like: “Why are we building something custom?”, “Can’t we reuse this component?”, “Can we make this component better?”, “Is this component worth the extra development effort?”. It’s about justifying decisions and setting expectations to everyone involved.

Conclusion

We just started putting together our design system and we’re still trying to make sense of all the duplicate components we found throughout our product. There’s still a long road ahead but with every component we touch we’re creating a better, more consistent, and easier to learn product for our customers.

We’re curious how other organizations make sense of a design system. Send me an email if you’d like to share your experience.

At DataCamp we’re always looking for talented people to join our team. Interested? Check our open positions.