The key lessons I learned creating a popular Design System

Matt Bond
Aug 15, 2018 · 6 min read
Illustration by the super talented Maya Ealey

1. Start by doing things that don’t scale

The very first version of the Atlassian Design System was about 20 static HTML files that I was hosting on a Mac Pro under my desk. There was no templating in these files, no version control, I had imported the CSS from our products, and I wrote the markup myself for each component. This version was nasty to update and wasn’t scalable, but enough people found value in it that it I was inspired to invest more time and effort that put us on the path to creating the Atlassian Design System.

2. Don’t weaponize your guidelines

If you’re creating a design system so that others don’t make mistakes that you (and only you!) will need to fix up later, you might not be approaching this with the right mindset.

A design system is a tool for empowerment, not a weapon to control design.

It’s really important to not throw the rule book at people and police it to death. Instead, try to approach the system with the philosophy that a design system is a tool to democratize design across your company. This approach really opens up the doors so that people want to contribute and be part of it. Remember, a design system is a tool for empowerment, not a weapon to control design.

3. “Let’s just redesign it all”

Resist the urge to take this as an opportunity to redesign your product. Creating a system and redesigning your app at the same time is going to slow you down significantly. It is much easier to document what you have today, both the good and the bad patterns, and then fix the bad patterns with a redesign of the visual language afterwards.

4. Get cross functional support for your design system

I believe that creating a design system is not an academic exercise. If no one uses the system, or it didn’t help your team move faster and make better decisions, you may be wasting your time.

5. Move beyond a style guide

A design system (or guideline) is different from a style guide. Having all the components in a Sketch file is relatively easy to do — all the primary buttons are the same color, or you’re using an 8px grid. But when do I use a primary button instead of a secondary button? What kind of labels should the buttons have? When a primary and a secondary button are together, which one is on the left?

6. Have someone oversee the system, but ensure everyone contributes

We utilized a centralized model which allowed for every designer in the company to contribute. We also had a ~3 month rotation program where designers and engineers were taken from their respective products and would work on the Design Platform team to push the system forward. They would contribute heavily while they were on our team, and then return to their original product teams being staunch advocates for the system.


Interested in finding out more about Asana? We have a neat site up at with a little about who we are and what we do. We’re also hiring Design Managers and Product Designers in our San Francisco office, one of the 2018 best places to work in the US! (We can relocate you if you’re not currently based in the Bay Area.)

Asana Design

Stories and lessons learned from the Asana Design team

Matt Bond

Written by

Matt Bond

Product Design Manager at Asana. Previously led teams at Dropbox and Atlassian.

Asana Design

Stories and lessons learned from the Asana Design team