My title has recently evolved to Principal Design Architect for Atlassian Design System. I'm part of the craft leadership squad, where we oversee the end-to-end vision and strategy for the team. This cross-functional squad comprises our architects and most senior ICs — a design architect, an engineering architect, a content design lead, a product manager, and a program manager.

We call ourselves the “crafties” and help oversee all the streams of work at a big-picture level. We partner with another leadership squad, which consists of people leaders who oversee the business and operations for the team.

We're embedded in a larger UI Platform organization, which consists of 3 main teams: developer experience, front-end platform, and design system.

Our design system is called Atlassian Design System and it is turning ten years old this year!

When our Chief Experience Officer, Jurgen Spangl, joined in 2012, he advocated the need for a design system for establishing a shared language. The first version of our design guidelines was called Atlassian Design Guidelines (ADG), and the code implementation was called Atlassian UI (AUI) — an HTML, CSS, and JS framework.

Two years later, ADG 2 was released. That is when Atlassian brought the brand and product closer together as a brand personality began to form. In 2016, ADG 3 revealed a huge rebrand, and that's the look and feel you see in all the Atlassian products today. We released Atlaskit with ADG 3 and moved from the HTML, CSS, and JS framework to React.

Over the years, Atlaskit and ADG became very inconsistent and hard to maintain. So when I joined the team in 2019 as a Lead Designer, my first project was redesigning the experience and combining all the content guidelines and components into a new home, which is what you see on atlassian.design today. This is the beginning of transforming our entity more formally into a design system.

Over the years, Atlaskit evolved into a monorepo that shared infrastructure for all developers. More and more developers started putting their front-end components in there. What you see on Atlaskit now is a shared library of various components created and maintained by many teams, not just ours.

A key thing to note is that Atlaskit is NOT the Atlassian Design System. It’s just a UI component library. There are design system components and other components from product teams like Confluence and Jira, all co-located there.

We moved the design system components out of the Atlaskit website specifically to harden that boundary and clarify which parts belong to the design system. That way, users know which ones our team owns and maintains.

There are the typical outputs that we have — we have Figma and React libraries and our documentation site. Along with that, we are creating tooling and always thinking about the user's experience of using our design system. How do we continuously evolve and take the system forward easily and harmoniously? What's the next big thing for it?

For example, we've been putting a lot of thought into our new color system, design token, and theming infrastructure. With these new systems, how do we onboard our users? How do we assist them in easily refactoring their code bases or updating their design files?

For developers, we are investing in tools, such as IDE plugins and codemods to help automate migrations. For designers, we want them to migrate seamlessly from our old color palettes to the new palette, so we're building a Figma plugin to assist with that. Along with tooling, we have to think about creating methods and systems to support onboarding as well.

We have a pretty big team right now. It fluctuates around 30 people, but we're doubling the team because we got funding with our new vision. Securing the funding helps a lot because we're setting our team up for success by helping us operate like product teams — finally, we're treating our system like a product!

For each team, we’re setting them up with a product manager, an engineering manager, and a design manager. Then we have about three designers per team, one content designer, and up to ten engineers. We have two teams now, and we’re adding two more teams over the next year.

A little bit of everything. Tooling is just one part. Our new vision and strategy are about reimagining how all the parts in our system can work better at scale. For example, if you look at our components, they're really not atomic nor composable. Everything is superglued together. So you'll see that we are reinvesting in hardening our foundations to redefine our sub-systems such as color, space, typography, and layout.

Atlassian is going through hypergrowth. We used to have five products, and now we have over 18. We started with six designers back in the day, and we have over 450 designers now. So we definitely have to make the system more flexible and composable to meet our needs.

There are different layers and types of work. There is a book called "Org Design for Design Orgs" by Peter Merholz and Kristin Skinner, where they talk about the layers of scope and scale — the surface layer, structure, strategy, and the big picture. So speaking in these terms, I'm covering strategy and the big picture, and then I have other teammates at each layer working from surface to structure to strategy.

Starting out in design systems, we enter the surface layer. In their day to day, they're receiving focused and specific tasks. They're looking at research, visual design, and things like typography, color, layout, etc. They're developing their craft and learning about design systems.

The next layer up, we have those with mid-level to senior experience. They're working on the overall strategy of how to lay our foundation, setting infrastructure, and creating new tooling. They are establishing standards and best practices, helping shape that language.

For leads and principals, we start working more with leadership, working together to get buy-in and funding, hiring and scaling our team, and big-picture things like our new vision and strategy. We’re connecting the design system to more of the business value. Every layer leads and coaches others.

I've been learning a lot as I've grown in my role over the past few years. What are we working on, and why? Why do we exist? What direction are we heading in? What makes a vision and strategy concrete? How do we get buy-in and funding to reinvest in the system to evolve it? My day-to-day is very much less in surface and structure layers these days.

A big part of my role is leading the creation and evangelization of our vision and strategy. It’s about looking into the future, leading strategic initiatives, and engaging with stakeholders to define how our systems of systems will become.

I've learned how to let go of all the day-to-day in-the-weeds things. The more I let go, the more others have room to grow in their roles. So I'm staying high level, and if they get stuck or need some coaching – I'm always there to help.

You know how I said that the third version was released, and there was no formal team governing it? So you can imagine how almost everything automatically went into the system through all sorts of varying contributions, which created API and designs that were quite inconsistent. All these factors are invisible, all very messy.

All the pains the team faced also stayed invisible, and it felt like this for a good two and a half years. It got me to a point when I wrote up an extensive diagnosis of "The State of Atlassian Design System" — I articulated our deepest systemic problems: why the system was not modern, why it couldn't scale, and what patterns we faced repeatedly.

This analysis drew the attention of the CXO, who was shocked at the state it was in, since the design system was near and dear to him. So he started getting closer to the problem to understand why we needed to invest in the design system again.

The team hit a point where we just couldn't scale or evolve the system further. Instead, we were drowning in KTLO, support, and maintenance. The diagnosis was the catalyst of a months-long effort — the creation of a strong business case with our leadership team — where we crafted a story to share our vision and strategy, backed up by ROI numbers to secure funding, trust, and a shared understanding.

When you're creating a vision, not only do you need to establish a story and strategy for where you want to go, you want to take others along the journey. You want to inspire them to help make the vision come true because they want to live in the future where the vision is a reality.

In Atlassian, we've called our approach to governance — local design systems, which empower systems of systems. Teams are already organically forming local systems. There are tons of them created by product teams, and there is a brand design system created by marketing. They all inherit the design guidance and foundations from Atlassian Design System.

There is a lot for us to structure and document to create methods and systems for scale. We need to answer questions like "What are local systems" or "What belongs in this system or that system" or "How do we help them govern or manage their local systems"?

We're also thinking of the concept of "pervasive API". As a developer or designer using components from different local systems, I wouldn't care much about which team is maintaining them. I just want all the components I'm using to work cohesively together — the API should be consistent, intuitive, and easy to use. It should be "pervasive" across our entire ecosystem.

As a team, we consider this to be our responsibility to provide the best practices for a "pervasive API" that powers the best experience of using our tools and systems of systems. We will guide other teams to seamlessly design their components' API for their local systems.

Our vision is: Atlassian Design System is the cornerstone of crafting quality user interfaces at scale. Our values talk about moving from an enforcing model to an empowering one.

Our foundations have to be easy to understand and consume, and we'll support this through tooling. We want to guide teams to make the right decision, not police them. We've done the research and would like you to trust our guidance to empower you to make confident design decisions. If they decide to stray from it – that's up to them.

As a team, this is our responsibility to provide API design guidance for other teams. For example, create guidance to avoid rethinking how we work with interaction states of the components. If we call it an "error" in one place, we don't want a component from a local system to call it "danger".

I think many people implement design tokens and theming to support multibrand. When it comes to us, Atlassian is a branded house, not a house of brands. We have many different products, and we want them all to look harmonious and look Atlassian. Whereas many other teams doing theming apply the same theme but for different brands, right? Those are the house of brands. Often when you meet or see systems doing that, you see that the output is all the same templates and flows. Our system was originally built for our Flagship products like Jira and Confluence. But now we're maturing and growing, and we need to get additional products on board, to serve a variety of needs.

We're launching new products. They need to spin up as fast as possible. They need to have more flexibility, they have more personality. Then we also acquire other companies. They could be on different tech stacks and already have a design system.

Our design system now needs to serve this whole spectrum of different brands and different products. So it's a little bit harder to rebuild these foundations to be extensible but adaptable for that spectrum.

Great question. We cannot just do whatever we want; the brand strategy always informs us. So we split our products into three layers with a spectrum of flexibility.

First, we have our flagship products: Jira, Confluence, and Trello. They have a little more flexibility to bring more personality and signature experiences.

Then we have another layer of platform products. We want them to be consistent enough. Teams can use primitive components to compose custom UI for those products.

Finally, we have another layer of products, which are all the rest of the Atlassian products, like Bitbucket and Statuspage. They should be the least flexible on this spectrum and look very consistent across. For example, they use the system as it is and shouldn't be applying random colors via themes. They all should look very uniformly Atlassian.

We are building for internal Atlassians but also for external developers and designers using the system to build integrations to our products. One of the biggest challenges is communicating clearly and transparently to create trust. It’s like working with an open-source community, but sometimes we can't tell them everything related to the business side of things. We need a better change management strategy. So that's one of the hardest things. External users can't see what you're working on to see the bigger picture.

When I joined three years ago, we developed a strategy for the team. We got all the leads together and said: "Here are ALL the topics we need to work on". I learned from that experience that we've created that poor strategy without thinking of ways to put them in a framework for sequencing and prioritizing them better. I used to joke that it was our 10-year wishlist. We tried to stack them in priority, but it really was a long list that we chipped away at. Not strategic.

I've learned a lot about what a good strategy and a bad strategy are. It was a big difference for us when we refreshed the strategy the past year. We created frameworks to chunk topics down into sequences. For example, we've used the Horizons of Growth and Innovation framework.

The first horizon concerns laying the foundations, building the infrastructure, fixing existing parts, and meeting compliance to modernize the system. The second horizon is about building on top of the first one. It's taking those parts to extend and mature them. And the third horizon is focused on innovation. It's about projecting the future, thinking about how we evolve at scale, and building a community around it. The key, though, is working on all of the horizons concurrently. And through all of it, we are focusing on the best designer/developer experience.

That's something that happens all the time. And that's something that makes using the new vision and strategy really helpful for us. We can use it to tell them which direction we're heading and why and work together with everyone to shape this future.

We've also learned over the past few years to avoid trying to solve all the problems simultaneously and then feel overwhelmed. Our vision and strategy artifacts helped us have a strong stance, united voice, and mature as a system.

I love our team. We've gone through a lot over the past couple of years, but together we've made it through. Now we have new leadership along with vision and strategy, which helps us stay aligned and motivated. Going through all these ups and downs has brought the team closer because we are very open and vulnerable. That has also generated more trust within the team.

I'm also really happy that we now have a lot of hybrids on the team. More designers are interested in engineering, and more engineers are interested in design. Years ago, our team was pretty siloed between design and engineering. Hybrids are helping bridge the gaps between siloes. We've been actively working on changing the culture and getting everyone working on initiatives together from the beginning, and this part has really evolved in the past years. It puts us in a great spot as we prepare to scale up our team.

When design systems start out, they immediately look to all these "world-class" design systems as a reference. I experienced this myself. A lot is happening behind the scenes. I always remind myself and others not to compare what they're building to these massive design systems because, most of the time, they are building for a different scale and spectrum of complexity. Products are different. Needs are different. The size of the team is different.

Instead, go and meet and greet with the people you're building the system for. Learn what they need from the system, and establish relationships with them. Build what they need, meet them where they are, and then just start. We can synthesize learnings from the big design systems, but what you should be aiming for is to start small. Start small and strategically implement your system as a living thing so it can continuously evolve. Stay humble, friends!

If you think that you have to build 60 components to cover the whole product from the start, it's usually better to ship just a small part of that and see how it works in the product instead of building everything immediately just to find out people don't need all of it.

Start small and strategically implement your system as a living thing so it can continuously evolve.