Today, it’s hard to find a design team in the tech industry who isn’t working on their design system. Recently, I’ve been talking with a number of designers who work on systems and some themes keep popping up—they’re not getting enough support from engineering to truly make the design system successful and their systems team has struggled to establish trust and buy-in with the rest of the design team.
In 2012, I started a 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 ultimately became my full-time job that involved creating and shipping several versions of the Atlassian Design System. During that time, I learned a lot of lessons trying to make our design system a fully integrated part of the company culture. If you’ve been working on a design system but it’s not getting the traction it needs for adoption, I hope the practical tips in this article will help you and your team create a more consistent, inclusive, and integrated design system.
Hire engineers on the design team
Design systems work should be design-led, but it’s essential to have the support and buy-in of other functions, especially engineering. At Atlassian, there was a critical moment that enabled the system to start gaining traction. The Head of Design successfully added two front-end engineers to the design team from other areas of the company. This was significant because we now had two engineers with strong ties to their functional organization, but who were now accountable to the design team and focused on making the design system successful. But note that once your core team is assembled, Design must be accountable for the success of the initiative and team.
I realize that this might not be possible for most companies but I still believe that it is critical to have engineers working side-by-side with design in whatever fashion is feasible. If you can’t move engineers or hire them directly to your design team with your own headcount, and you’re trying to borrow engineering support, you’ll need to campaign heavily and articulate why a design system is worth the work. It might be clear to you why this work is necessary, but you’ll need cross-functional buy-in not only to build it but also to ensure adoption. To help convince the product and engineering managers to temporarily loan an engineer, it is helpful to frame it in terms of paying taxes: if everyone contributes to the design system by loaning engineers, you’ll get the benefits of every engineer’s contributions over the course of the year.
Create a rotation program
Most success metrics for a design system are centered around its adoption within the company. To ensure that the design system was widely adopted by teams at Atlassian, the Engineering Manager had to get creative. One idea was to borrow engineers for 1-3 months at a time to create a rotation program. (Again, this was a big ask, but we were fortunate to have the support at the highest levels of the company thanks to the Head of Design who helped socialize the early impact the system. If you can get the CEO or VP of Engineering to support you, it makes it a lot easier to get people on board.)
Selecting engineers to rotate onto the team was more art than science and often came down to knowing what teams were planning to build in the coming months. During the rotation, an engineer would work on a component or pattern for their regular product or feature team, but ensure it was built so that it could slot straight into the system. It would typically take about 15-20% longer to make sure the component was rock solid and reusable but the initial investment pays off several times over.
Over the course of a year, about 4 engineers got the opportunity to work on the systems team. When they rejoined their original teams, they shared the good habits and lessons they learned and advocated for the system.
Help designers take ownership of the system
Developing and building trust is essential to a successful system. If the design team thinks “that’s your design system, not mine/ours” then you run the risk of all that work being rejected by the design team and the system failing. While it is tempting to be a gatekeeper, it is critical that the design team contributes to the system in meaningful ways to avoid this pitfall. One way we did this at Atlassian was to run what we called “ADG hack days” every month where we’d book out a big meeting room for the whole day and work on the system as a group.
To help the day run smoothly, I would outline a handful of patterns that needed to be added to the system and share a template doc that outlines how to write up a good guideline or pattern for the design system (very meta). The template and the list of required patterns were shared with the team ahead of time and they’d pair up on the design patterns they were interested in. This is also a great opportunity for the team to work with designers they would not normally have the opportunity to collaborate with closely.
At the end of the hack day, the design team would have design patterns about 80-90% documented and then they’d be translated into the coded system. The patterns would usually take a little bit of editing, or collaborating with engineering to fix bugs, but the work was always firmly created by the rest of the team. When the new components or patterns were published in the system, it was nice for designers to see that they had directly contributed to the design system.
If you are working to create a design system, you want to be sure it gets used and adopted. By bringing in engineering through hiring and a rotation program, you naturally create a cross-functional system. Additionally, by bringing in the whole design team, not just those working on the system, you ensure that the people who will use the system are also contributing to it and taking on a sense of shared ownership for its quality and success. The more champions you have, the more likely your design system is to succeed and become an integral part of your company’s culture.