In 2012, I started a small side project to standardize the design patterns and user experience of 12 software products at Atlassian. Over the next 3 years, this small side project turned into a very big project that became my full time job that involved creating and shipping several versions of the Atlassian Design System, and established the Design Platform team (that still exists today but with many more people) to maintain and leverage systems work across the Atlassian product suite.
With the uptick in design systems discussions over the last couple of years, I’m occasionally asked for tips or insights from my experience building the design system at Atlassian. If you have considered creating one for your product or company, are in the process of making one, or have tried and given up, hopefully these insights will help you create a better design system for your company.
At Asana, we’re at the start of our journey to build a holistic design system. I’ve found that reflecting on these lessons has helped us set the team, and the company, up for success so that we deliver the true value of a design system.
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.
Without doing something that didn’t scale, we might have taken a lot longer to get started. When you’re working on your system, try not to get too obsessed with over-engineering a seamless, perfect workflow but instead look for scrappy ways to start, and just keep making progress if it’s working.
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.
The goal of a design system is to scale yourself (and your design team) to build product faster and empower everyone to make better design decisions.
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.
There were many attempts at Atlassian to redesign the product suite before the groundwork of documenting our system components was satisfactory. It took a long time to build the architecture of the system that but it made it easier (and faster) for Atlassian to refresh the visual language later on because the foundations were solid.
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.
By getting others to follow what you’re doing, and contribute to making the patterns and guidelines better, you will have the buy-in and support you need to really making a difference and build great products. I can’t over-emphasize how critical this is to the success of your systems.
Back in 2013 the designer to engineer ratio was something in the range of 1 designer to every 15–20 engineers. While I shudder at the thought of that number today, back then I tried to use that imbalance to my advantage. Something that helped me get the engineering org on my side at Atlassian was to create a talk for new starters during their first week of onboarding at the company. About 15 or so people would be there every week and I’d be able to get them to understand what we were trying to do from day 1. For example, I’d go through some history of how we used to have 44 different dropdown menus (not an exaggeration), but we have one now and here is how you should use it.
Over the course of 2013, and with Atlassian doubling in size nearly every year, I had basically onboarded about 500 people about the importance of our design system and how they can use it. I found this to be a really effective way of changing the company culture with regard to design.
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?
These questions are the kinds of things a design system should be solving for, not just documenting the pixel values of your components. A lot of design teams are missing out on this aspect when they’re creating their system and ultimately miss out on a powerful side effect of system work.
As I mentioned above, the Atlassian design team at the start of 2013 was relatively small (~13 people) compared to the engineering team (~300 people). One of the benefits of including written guidelines was that engineers could make a huge amount of progress without a designer there. It meant that we could stop designing screens in Sketch and instead, jump on a whiteboard and brainstorm a flow, or start to work on much bigger product problems that existed upstream.
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.
Having someone oversee the system is very, very important. This person (me at Atlassian) is probably a Designer moonlighting as a Product Manager. They should safeguard the system but be very careful to not create an environment where people reject it and go rogue. Don’t forget, the purpose of the system is to make everyone at the company a better designer.
