How do you actually get your design system implemented in ALL your organization’s products? It’s easy to picture the end goal, where all the products look consistent, function harmoniously, and are effortless to update. But the journey to get there is often overwhelming, especially for large organizations. Even if you could get one or two engineering teams to use the system, it might not have been easy. Or maybe it was easier because you have an excellent working relationship with them, but you know you don’t have that with every engineering team. So, how in the world will you and your design system team get every engineering team to consume the design system?
While this seems daunting, maybe even anxiety-provoking, this is a common challenge that companies face. But it is possible!
In this article, we’ll walk through how you can take a staggered approach to design system implementation. We’ll cover some caveats to pay attention to as you plan your strategy.
Staggering design system implementation
Rome wasn’t built in a day, nor were design systems or their adoption! Taking a staggered approach to applying the design system across the product portfolio makes the most sense.
A staggered approach means prioritizing which apps and endpoints (e.g., iOS, web, Android, etc.) get to implement the design system first, next, and so on. There are different ways to prioritize, and much of it will depend on your organization’s situation. Regardless, it might take some level setting with stakeholders so they know what to expect realistically.
Often, stakeholders want nearly instant adoption so all apps have a unified look and feel. (Don’t we all, though?) They might ask, "We have a design system. Why do our products still look so different?" Or they could question, “You’ve been working on this design system for a while. Why do our products still look different?”
You could explain why nearly-instant isn’t possible by alluding to the baggage at the organization (e.g., products use different code bases, have other priorities, use teams across the world, etc.), but that will only get you so far. To some, it might seem like you’re complaining, and any stakeholder wants to hear about solutions, not problems.
Instead, meet with the stakeholders with a general plan and ask them to provide their input on how best to stagger the design system implementation. By having them actively help prioritize, they can get a better sense of the scope of the work, build empathy, and understand how design system implementation isn’t as trivial as flipping a switch.
Factors to consider when staggering design system implementation
Developing a plan to share with stakeholders requires looking at a few factors, weighing them together, and evaluating the pros and cons of the options. Organizations are unique, so it’s not as easy as providing a set order or template. (If it were, this article would be much shorter!) When developing a general plan for your design system implementation, there are three main factors to consider: business priority, technology, and technical capabilities and resources.
Business priority
Your organization’s business priorities can influence determining which products or endpoints to prioritize. When you weigh this factor, some questions to consider include:
- Is there a flagship product that should get the newest/latest and greatest UI? If there is a flagship product, does that one get the new design system?
- Or does the design system feel too “experimental” that it’s more important to try implementing it with a smaller product before scaling it to a high-profile product? Doing this might help work out any hiccups before a larger rollout.
- Are there legacy products that are in maintenance mode or will eventually be sunset that they have a lower priority? These might not even need to use the design system!
- Is customer engagement or revenue generation a factor in which products should leverage the design system?
- Are upcoming initiatives (e.g., product or marketing goals or a rebranding effort) happening soon? Is this an opportunity for the design system to assist with them? Or is it a logical opportunity to include design system implementation simultaneously? Sometimes, a design system can be part of the solution for other product or marketing-related initiatives.
Technology
Technology is another factor that can affect how an organization prioritizes implementation. Some technical considerations to familiarize yourself with include:
Is the product using the same codebase as what the design system uses?
It’s easier to implement the design system in products that use the same codebase. But if the priority is a flagship product that isn’t in the same codebase, it could mean the design system will need to create additional coded components for that codebase. Ideally, aligning on codebases came up when planning the design system. However, I’ve seen cases where a smaller product’s design system does so well that stakeholders want to scale it to larger and more prominent products. This is where your codebases might not match.
Is there a codebase that a product or engineering team recently adopted, will be adopted, or will be scaling?
Ideally, the design system uses that same codebase, and it can be an excellent opportunity to implement the design system as the team refactors the product. This might require some discussion with engineering leaders for their thoughts. They might have a roadmap or rough plan somewhere, which will be helpful as you plan. If not, this could be the start of a technology-stack roadmap.
For example, the company might be shifting from Angular to React, and any innovations will use React. For X amount of time, all products will use React. Getting coded components in React would be the priority. However, if X amount of time is 2-3 years, creating the components in Angular might be a higher priority once the React components are done.
It's OK to have DS components in multiple code bases, and it’s prevalent in large companies with established products. Depending on products, resources, etc., numerous code bases can exist for a long time. While not ideal because you’ll have to maintain multiple code libraries, it’s not the end of the world. What matters most in this immediate scenario is that they visually look and function the same across the product portfolio. Customers don't care about the technology; they want a consistent experience. However, everyone should remember that multiple code libraries require more resources (e.g., people, time, budget) to maintain and add complexity.
Technical capabilities and resources
Resources provided for the products could affect priority, too. Some considerations include:
How well-resourced are the engineering teams for the products?
If a team is underresourced and they have to focus on feature implementation, yet it’s a priority for them to adopt the new UI, how might this be negotiated? Does the team bring in extra help? Do priorities shift for a sprint or two? Do they only implement the design system for net-new features if it’ll look and function OK? Having these discussions amongst the PM, Engineering, and Design stakeholders can help come to a good understanding of why things are prioritized the way they are.
What are the technical capabilities of the teams that support the products?
Teams that support older products might need more time to adopt current coding best practices when learning to implement a design system. (Or they might be OK because they’ve worked on newer products and have those skill sets.) Teams working on more recent apps might be in a better position to adopt the design system. Often, much older products can’t easily handle adoption because coding best practices have evolved, and the older product hasn’t kept up with it.
Are there teams that are more adept at implementing new methods without much oversight? There might be a team that can take on new challenges quickly (e.g., if they're all Principal Software Engineers), so they could be the first adopters. They can also become champions of the design system and help shepherd change across other products.
By thinking about some of the answers to these questions, you can draft a priority list for stakeholder feedback. At the very least, you’ll have the right questions to ask when having them provide their input on priorities.
Additional roadblocks for design system implementation
Once you have a rough idea of the priority, there are a few other things to consider that can affect implementation. I’ve collected this based on what other teams and I experienced when it comes to design system implementation into products.
The code isn’t set up for design systems
Sometimes, a product might not be coded to leverage reusable components. This is more common in older products. Sometimes, design systems can be misused, where instead of pulling in components from a library, teams are copying and pasting code snippets of components. While they’re keeping the look and feel of the component, it’s just a copy of the code. It’s essential to work with engineering teams to get a complete understanding of how products are coded, especially older products. Once you understand, work with them to see how they can move toward leveraging a component library.
For example, it doesn't mean leveraging coded components just yet. It might mean changing the colors to the new colors from the design system or changing the font used with their current method of coding. While this is purely a cosmetic approach to adopting the design system, it gets you closer to adopting the design system. Then screens can start getting refactored. For example, a settings page gets updated to use the toggle component and the button component. The product might go through an "awkward teenage phase" where there might be some minor UI inconsistencies (e.g., the old buttons have sharp corners, and the design system buttons have rounded corners), but in time, it'll all be consistent.
Some teams might opt for "any net new screens" to use components from the design system. Some teams will also convert existing screens to use components if that screen is getting worked on (e.g., updates or new features added to it etc.) As a design system person, it can be helpful to offer up some of these suggestions so engineering can figure out what's feasible and what's not. Some stakeholders might be OK with this slow evolution, but some might not, so it's good to get a sense of how they feel about it. If they want more to change quickly, you can request more resources or shift the team's priorities. They might become OK with the slower incremental approach if they can't provide that.
Feature/scrum teams don’t have time
Depending on how the engineering organization is set up and the workload of those teams, it might be impossible to get those to “fit in” implementing design system work. If they do have some capacity, the design system work is prioritized at the bottom, so they can only work on it for a few hours every sprint. This can cause a large bottleneck. If your organization cannot implement the design system within sprint cycles for those teams, there are some alternatives. Sometimes, engineering organizations will create a specialized team that solely focuses on developing the components to get them into the codebases quickly.
For example, this specialized team might sit out from their usual sprint work with their original feature teams for a few sprints or a quarter to complete implementation. If this approach works, this model can scale across numerous engineering organizations. Some engineers might welcome sitting out of a sprint or two as a special benefit, which can improve employee engagement.
Hesitancy to commit
Creating the component in isolation is relatively easy for an engineer to do. However, the reluctance is with implementing it at scale in the product. This is especially true if the concept of a design system is new to the product because of what it could break in the existing code. Similar to the benefit of using a component - we change it once, and it changes everywhere. The same goes for errors. If it breaks in one place, it’s broken everywhere. When it comes to implementation, the testing and troubleshooting could take a lot of time. Most engineers are OK with doing this as long as everyone understands that it's not just about coding the component but that introducing it in the existing ecosystem will require more effort.
Hesitancy to adopt
While design systems bring efficiency for teams in the long term, there's not much of a short-term reward. Sometimes engineers might feel like they're not making a meaningful change - they refactor the code to use components, but the screen still looks the same, and the customer doesn't even notice. Instead, they'd rather spend time creating new features that will be released. Sometimes, engineers might be hesitant to adopt a design system because it changes how they're familiar with coding. They may say, “I've coded buttons this way for years, and it's been fine for me.” This issue isn't the responsibility of the design system team to resolve; this is where engineering leadership needs to get involved and put some top-down pressure. You, your team, and the design system can help foster this transition by making it as frictionless as possible and considering ways to increase adoption.
Asking great questions
To determine which of these challenges and others the design system implementation might face, consider talking to engineering counterparts, engineers with deep product knowledge, or other designers who might work with these teams. Find out how their teams work, what challenges they have, and how their working relationship is with their design counterparts. From there, you might find answers to these questions or people who can point you in the right direction.
Asking with curiosity and authenticity
Asking in the right tone is as important as asking the right questions. Act with curiosity and authenticity when trying to learn how other teams work. Come from a perspective that you’re trying to learn more so you can help figure out the best way to navigate design system implementation across the product portfolio. Your approach is vital in building a good working relationship so teams don’t get defensive. Teams often get defensive if they feel pressured to do something in an impossible timeframe (e.g., stop everything and implement the design system in one sprint).
Depending on their past experiences and level of trust with your team, they could feel your questions may be a little threatening or that you could use their answers against them. For example, if you ask how long it would take to implement the design system, they might be hesitant to provide a timeframe in case you use that against them later.
An example dialog
If you’re unsure of what questions to ask, here’s a sample approach and conversation you can try:
- Provide context: So, you may have heard, I’m working on the design system, and we’ll want to get it into products soon. We’re trying to prioritize which products get the design system first, when, etc. Do you mind if I ask a few questions to get better context about what that could look like if your team/product consumes the design system? (And hopefully, they’ll say, “Sure.”)
- What would the process look like from your perspective? What would you need to know to start?
- Do you foresee any concerns with implementing the design system? From a code perspective, process, resource, skills, etc.?
- What would you need to ensure success for your team? Is there anything my team could be helping with to ensure success for your team and the product?
- Do you have any questions or want to see the design system?
Once you finish asking questions, thank them for their time and inform them of any next steps. Keep them in the loop on how things are going with the design system.
The idea behind this approach is that you’re informing them with enough context that they know you’re not a threat. You’re also asking them for their thoughts and looking to see how you could be helpful to them. This alone demonstrates that you’re trying to understand the landscape and what success looks like for them. If things go well, you could form a great partnership with them and have allies for encouraging further design system adoption.
Facilitating design system implementation
Once you have a rough idea of the plan and talked to a few key people, it’s time to take your plan to stakeholders. Depending on your role and who’s ultimately responsible for the design system (i.e., a Director of Design), run your plan by them first for feedback. In my case, I ran my plan at my old company by the VP of Design. They might have additional context that could change some of your priorities. As they provide feedback, see if they have strategies to approach this with other stakeholders. The VP gave me good insight into what kind of information resonated with the stakeholders better, as well as their concerns about the design system. Typically, your stakeholder is a peer to other stakeholders and can provide this information.
Pitching a plan
You’re essentially pitching to stakeholders what the path design system implementation looks like. We highly recommend you offer a few options with their benefits and risks presented, timeframes, etc., so they can react and choose something. Even if you strongly believe there’s only one way you’d like to see things implemented, pitching only one idea can easily lead them to say no, leaving you with no plan. With multiple options, it helps provide a landscape of possibilities and point out what factors might affect the choice, including the risks. They often have other context to the business that can help steer them toward one option over the other. With that context, they might choose something that isn’t ideal for you. For example, it might take longer to implement than another option. But this also means they know the risk and are OK with it.
If your plan is more amorphous and you need their input for direction, be clear with where you need their input. Try to provide as much information as possible to help them weigh in on the options.
Documenting the decisions
However your conversation shakes out, recap the decisions and any possible risks. For example, “So, it sounds like we’ll prioritize these apps first, but we’re all OK to pause on feature work for two sprints to meet the deadline.” Recap any other essential decisions, for example, the priority order, if some products won’t get the new design system, or if some will mimic the design system but not use components. That understanding is critical so leaders are on the same page and won’t ask, “Why don’t all our products look the same!?” And if they do, you have information to reference. You can even include this as part of your design system’s roadmap.
What’s your experience been like?
If you try any of these tips, let us know on X (@zeroheight) or on zheroes, our Slack community. Let us know what challenges you discovered or what agreements your team and stakeholders settled on. Navigating this can be tricky, so the more information we share with others, the better prepared they can be when implementing their design system!