How to Evangelize a Design System?
Adopting and scaling a design system is challenging. You must get buy-in from the entire organization, which means evangelizing your design system to persuade stakeholders, product managers, development teams, and designers of its value.
Building a design system is just the first step; scaling and reaching optimal design system maturity costs a lot of time and money. Evangelizing a design system means you have to prove it will help teams be more efficient, productive, and free to tackle complex challenges.
When ExxonMobile created its design system, Unity, the company built more than 50 web apps in 10 months. Your goal is to demonstrate how your design system will create business value and deliver a return on investment (ROI).
This article explores how to get organizational buy-in, including practical resources to help pitch your design system to stakeholders and investors.
Whether you’re starting from scratch or have an existing design system, UXPin offers solutions to build, scale, and mature your design system using a single platform without plugins and extensions. Sign up for a free trial and see how UXPin’s code-based design tool can enhance your UX workflow to build better product experiences for your customers.
Why Do You Need to Evangelize a Design System?
Many stakeholders see building and managing a design system as a costly distraction from designing and optimizing revenue-generating products. They can’t see how a design system will generate ROI.
Designers also face the challenge of convincing other design teams, product managers, and engineers to adopt a single design system. When Spotify built its design system, Encore, in 2018, they had “22 different design systems floating around.” (And by around, they’re talking about spread across multiple continents!).
So, designers must evangelize a design system for two primary reasons:
- Business value for stakeholders
- Reducing workload and increasing productivity for designers, product teams, and engineers
Who’s Responsible for Getting Design System Buy-In?
Who is responsible for getting design system buy-in depends on the organization and the structure of your design department. The call can come from a product manager, web manager, design lead, DesignOps leader, or a lonely UX designer in a startup.
Eightshapes founder Nathan Curtis identifies three common design team structures and how they are responsible for scaling a design system:
- Solitary Team Model: You typically have a lone UX designer who might work with contractors and freelancers in a startup environment. They might pitch the need for a design system to manage consistency and minimize contractor (and future employee) onboarding.
- Centralized Team Model: A typical team setup in medium to large organizations with a centralized team making design decisions. They often manage the design decisions for multiple products.
- Federated Team Model: An enterprise structure where a committee of designers from across platforms and product lines collaborate to make design decisions collectively for a set period–similar to representatives in the US Senate.
When Do You Pitch a Design System to Stakeholders?
The longer you delay building a design system, the more time and money it takes to implement one. The problem is that most organizations (including multinationals like Airbnb and Spotify) realize this too late, which ends up costing a lot of money.
“Here’s the simple truth: you can’t innovate on products without first innovating the way you build them.” – Alex Schleifer is the VP of Design at Airbnb
When UXPin spoke to Dan Mall of design system specialists Superfriendly, we asked what size company benefits from a design system. Dan replied, “I don’t think that there’s any particular size that I can pinpoint, but I think it’s about how many digital properties they maintain or intend to maintain.”
Without a design system, the software development process gradually slows, and user experience suffers. You cannot hire more designers to scale design. More designers mean more “cooks in the kitchen,” resulting in a chaotic design process, inconsistencies, and design drift.
Here are some questions to ask:
- Are you satisfied with the speed of product development?
- Do our interfaces share the same design patterns, colors, typography, and other styles?
- Do we always have enough time to deliver a quality product to meet KPIs?
- How do departmental silos impact design?
- How much time and money do we spend on redundant design or code tasks?
- How much time and money do we spend cleaning up design or technical debt?
Answering these questions and highlighting design problems will help you build a case that your organization is ready for a design system.
How Do You Evangelize a Design System?
In our free toolkit, Evangelizing a Design System, we provide you with a proven template for getting buy-in from designers. You must conduct internal research to identify the problems your design system will solve and how it will deliver an ROI.
Here are 5 steps to prepare your presentation and evangelize your design system.
Step 1 – Conduct Research
The first step is to conduct research to discover your company’s design pain points. You should look at the facts objectively; perhaps your organization isn’t ready for a design system. Maybe a UI kit or style guide is a more realistic and cost-effective solution?
This approach might sound counter-intuitive, but remember that you’re likely to face resistance and scrutiny from stakeholders and other team members. Your goal is to ensure you have explored every avenue to prepare yourself for difficult questions.
Your research should also include interviews with product managers, design leads, customer support managers, engineers, and other team members to understand the problems and challenges they face.
- What is the rework rate?
- What are the issues with design handoffs?
- How many support tickets relate to usability issues? And what is the effect on users?
- How often does design and development experience drift?
The goal is to identify problems a design system can solve and deliver a positive ROI. Most importantly, how do these internal issues impact your customers?
Step 2 – Prepare a Presentation Based on Your Research
With over 40 slides in four sections, our Evangelizing a Design System template has everything you need to build a strong presentation for implementing a design system.
Our presentation template includes:
- An introduction with facts from use cases and surveys
- An outline of what a design system is and how it works
- A template to calculate and present your ROI
- A section for the next steps and how you plan to implement your design system
You’ll also need a system of governance and a design system team to maintain your design system’s consistency and integrity. Otherwise, you end up like Spotify with 22 design systems spread across the globe.
The size of your design system team will depend on your company and the number of products. Here is an example design system team that Superfriendly usually recommends for a centralized team model (see who is responsible for getting design system buy-in? above):
- Product Owner
- Design Manager
- Tech Director
- Senior Designer
- Senior Engineer
- Senior Analyst
- Content Strategist
- Associate Designer
- Associate Engineer
In smaller companies and startups, you might only fill 2-5 of these roles.
Step 3 – Finding Allies and Educating the Team
It’s essential to educate team members before you approach stakeholders. The more team members you get behind the project, the better your chances of convincing stakeholders.
Jordan Staniscia, a Senior Product Designer at Abstract, recommends finding “allies” from other departments who share your passion and vision for a design system. These ally evangelists can teach you how different departments will use a design system and how best to appeal to these team members. Employees from SurveyMonkey, HubSpot, and WeWork have all used this strategy to educate teammates.
You may gain further insights during this process to strengthen your presentation to stakeholders.
Step 4 – Presenting to Stakeholders
During your presentation to stakeholders, it’s important to present the following:
- How design systems have helped other companies and competitors
- The problems and pain points affecting your company
- The cost of these inefficiencies
- The current effect on customers
- Feedback from team members
- How your design system can reduce or eliminate these inefficiencies and associated ROI
- The benefits specific to your company
- A basic outline of the proposed design system’s structure
- Summary of the design system’s team and governance
Our free template, Evangelizing a Design System, provides space for you to present these points succinctly to stakeholders.
Step 5 – Continuous Evangelism & Outreach
Like the design system itself, your evangelism and education are an ongoing evolution process. The design system team must continue to engage with team members.
- Identify pain points and solutions to fix them
- Encourage input, suggestions, and ownership
- Educate teams about updates, scaling, and best practices
As you scale your design system, you’ll need more funding and resources. So, it’s crucial to evangelize your design system to stakeholders continuously:
- Demonstrate how the design system has improved inefficiencies
- Feedback from team members
- Share feedback from user research related to the design system
- How the design system improves usability and accessibility
- The ROI
- Your design system roadmap and how future changes will deliver business value
Building, Scaling, and Maturing a Design System With UXPin
Start your design system with minimal investment using UXPin’s Design System’s feature. Start your design system from scratch with Colors, Assets, Typography, and Components. You can also manage your design system with documentation and set permissions for your new components to prevent unauthorized changes.
UXPin also offers solutions for scaling and mature design systems with UXPin Merge. Merge allows you to sync a design system to UXPin’s design editor from a repository. Designers can simply drag and drop fully functioning code components to build new products and user interfaces.
With Merge, UX designers, product teams, and engineers all use exactly the same code components, thus creating a single source of truth across the organization.