The ABCs of Design Systems
The A-Z guide for operating your design systems team
A is for Adoption
Measure how people are using (or not using) your design system
There are two groups who need to adopt your design system: designers who use UI kits and engineers who use a code library such as React. Design adoption is easy — just swap out the UI kit and voila. However, code that is even one day old comes with technical constraints that make it hard to just flip a switch and expect all engineers to use it overnight.
To measure adoption at SurveyMonkey, we plot every product team on a five-point color scale:
- Red: Team does not know we have a system.
- Orange: Team has not adopted any part of the system.
- Yellow: Team has prioritized adopting the system to their roadmap.
- Green: Team is using the design language but not the code.
- Blue: Team is using both the design language and the code.
Get your engineers involved up front to foster healthy adoption. Design systems solve a design problem, but with an engineering solution.
B is for Beta
Pilot new releases to a small group of beta testers
A small change to any component could break the kits that your adopters are using and require them to make a change on their end to support it. This can get really taxing over time and can get expensive as things scale. To avoid this, we always ship big releases to a small group of early adopters first. Then we learn from them before releasing to everyone.
Some things we’ve learned early on was that our naming conventions were not clear and that some components needed more robust variants. If we had not caught those kinds of small but crucial things up front we would have run the risk of creating more work for our adopting teams when we asked them to upgrade to a new version.
C is for Canon
Your official criteria for adding new things to the system
We organize by design tokens and UI components, and we carefully curate what gets added so that the wrong parts do not get inducted without meeting every check mark in our induction criteria. Our canon is the truth, and it’s how we distinguish between a sanctioned decision versus a pattern that is being circulated unofficially. Tokens and components must both be available in Sketch and code before they are inducted so that designers and engineers are always working from the same set of tools. We also look at things like if it’s an industry best practice, is it context agnostic, has it been proven in production, etc.
Be strict curators of your canon and communicate how your team decides when and why tokens or components are or are not ready to be inducted.
Design systems solve a design problem, but with an engineering solution.
D is for Distribution
How you communicate and deliver changes to your teams
You can spend months crafting brilliant symbols in Sketch, writing guidelines, and partnering with engineers to build everything in code. But have you stopped to think about what the experience is like for people using the system? How easy is for them to receive updates? Is it a manual process or do changes get synced automatically?
Good distribution starts with great encapsulation.
Most modern design tools have disruption tools built right into them. But how might a Sketch plugin replace your need to use a Sketch library that has to manually download each update? For engineers, how might you improve their need to copy and paste raw values and/or HTML? Instead of 50 lines of HTML, how might you encapsulate it down to one line of code? Most modern tech libraries are built with this philosophy of encapsulation (React and web components, for example).
E is for Ecosystem
The delicate balance of everything that makes up your design system
Just like a rainforest ecosystem, every part of a design system plays an important role, and it all needs to work effectively together to keep everything running smoothly. And the design system ecosystem reaches far beyond UI components. We like to think that our design system ecosystem contains these four systems inside it — all of which need to work together to keep the system healthy:
- Distribution: Automating release and communication of updates (Deploying, npm, change logs, Slack).
- Tooling: Streamline how people use the system (Sketch plugins, VScode plugins, prototyping tools, etc.).
- Education: Helping people use the system better (docs, guidelines, onboard training).
- System: The design language and UI components. (The fun stuff!)
Imagine dropping a polar bear into the middle of a rainforest. It’ll wreak havoc on the wildlife around it, and the polar bear will suffer too. We think of our system just like that. If you introduce things into your design system that don’t make sense in the larger context, the system will slowly deteriorate.
F is for Forever
Each addition to the system is a vow to maintain it
Who doesn’t celebrate when they ship a new component and move onto something else? It’s tempting to never look back, but it’s important to remember that every time you add more features to your design system, your commitments and responsibilities increase. If you’re not careful, you might bite off more than you can chew, and all of a sudden you only have time to maintain the core system — and no time to grow the system further.
Before you add anything new, think about the long-term cost of support. As your system takes on more responsibility, grow your team at a relative speed.
G is for Glue
Be the reason that other teams break out of their silos and work together
Your design system sits central to everyone and gives you a holistic view of the entire product experience. You have the powerful advantage to spot when people are working on similar problems and bring them together to solve them when otherwise they might not have looked up to notice the opportunity. I call these missed opportunities “the seams” and your design system is the glue that holds the seams together.
Your design system is the glue that holds the seams together.
H is for Help
Be clear and specific about how others can contribute
A design system shouldn’t exist in a vacuum, so it’s important to set up a process for accepting help and contributions from the people using it — similar to an open-source model. But not just any help. Be crystal clear about what your team does and doesn’t need help with, and establish guidelines for contributing. Our design systems team wasn’t ready to accept outside contributions until we did a ton of work up front to set a good foundation. Once we were ready, we created a roadmap and a process that made it clear how to be an effective contributor.
I is for Invisible
Disrupt your adopters’ process as little as possible
One of our design system’s guiding principles is to disrupt the workflow of our teams as little as possible. Aim to fit into their workflow instead of asking them to fit into yours. Everyone works differently and every team operates differently. It’s not your role to determine their destiny for them. Instead, it’s your role to listen to how they work and design your system to accommodate so it can be invisible during their process.
J is for Job
All the small tasks you do today can become a full-time job later
It’s no exaggeration to say that there’s a lot of work to do on design systems. Every small responsibility you’re taking on today has the potential to be a full-time job later on. Small tasks today are easy to juggle until they balloon in scope as your system scales. Being blindsided by increasing scope is a shock to the operation of your system. Prioritization becomes your key ally in recovering your operations — decide which tasks you can drop until you have more people on your team.
K is for Knowledge
Document and share the knowledge you gain from being centralized
Being central to the process of so many designers and engineers means you have a wealth of undocumented knowledge brewing in your head. That sounds great if you’re okay being the gatekeeper, but documenting the knowledge in your head is very powerful and can empower your entire organization to do better work.
Find a process to document your knowledge in an informal way and see what your team finds valuable. Share it with your team until your system is ready to formalize it in your documentation and guidelines.
L is for Live
Design files are just a static representation of your design system — they’re not the actual design system
As we’re moving toward modern technology stacks like React, changes can automatically sync across your entire ecosystem (docs, Sketch, and code). Philosophically, that means every UI component in your system exists everywhere, together.
First, make sure your system’s source of truth is the code. Build a doc site that renders that living code right inside its examples. Build tooling, like a Sketch plugin, that automates converting your coded components to Sketch symbols so that your team doesn’t have to manually draw your UI kits by hand. This helps avoid bugs downstream due to human error.
M is for Measure
Prove the value of your design system by measuring its impact
Early-stage design systems teams measure different things than mature ones. Early on, you focus on delivering what you promised: UI components. At this stage, you’re measuring how many tangible things your team is able to produce and deliver — like your UI kit or new components. But once you’ve done that, you need to start measuring the impact and value your design system brings to your organization.
The metrics at this stage should align with the metrics your company already cares about. For example, our engineering teams already measure “time to close a pull request.” Separately, we keep track of which teams use our design system, and which teams don’t. When we map that data together, we can show that engineering teams that use our design system take less time to close a pull request. This is a win-win — it helps us prove the value of our design system, and it gives an incentive to engineering teams to adopt our design system to increase their efficiency.
Find out what your design and engineering departments are measuring and segment the data.
N is for Need
Your system doesn’t get dedicated resourcing because it hasn’t solved a business need
No one is listening if you pitch your system as solving design problems (for example, improving color and typography). Even if you pitch that it will improve the customer experience, leading to more money downstream. While that may be true, it’s usually not how the business thinks about priorities.
Instead, start by identifying a need that the business has and propose that you can solve that need with a design system. What they care about is that you’re going to solve that need, not necessarily that you are going to do it by spinning up a design system.
At SurveyMonkey, our business need was to apply our new brand throughout the entire product as quickly as possible. At another company, the legal team had the business need of ensuring that we were meeting accessibility guidelines across the site — and we promised to solve that need with a design system.
Identify a need that the business has and propose that you can solve that need with a design system
O is for Onboarding
Educate and train teams on how to adopt your design system
One day you’ll get to a point when the foundation is stable and the number of new components being added has slowed down drastically. Add an uptick in adoption to that mix and your design system’s bottleneck will no longer be that a pattern doesn’t exist yet. The new bottlenecks will be the unknowns of how to get started and how to use the system correctly.
To solve that, you need to invest in training at the right time — not too early when shipping new components is more important, but not so late that you’re creating huge barriers for getting more teams to start adopting your design system.
P is for People
Your customers are your co-workers
Early design systems are usually developed as a grassroots effort by product designers, who naturally bring their customer-centric design process with them. As a result, I see design systems teams fall into the trap of building their design system for customers, instead of building it for the designers, engineers, and PMs who are actually using it to craft products for customers downstream.
What ultimately gets shipped to production is not your responsibility. Your responsibility is to build a design system that improves the productivity and relationships of the people using the system — your co-workers — and to help them make great decisions as quickly as possible.
Q is for Quit Policing
Your company’s live app or product is not your priority
The design systems team shouldn’t be the gatekeeper of what ships to production. What ships to customers is your product design team’s responsibility. If you’re straddling the line and policing designs right before they ship, you’re already too late. You’re focused on the wrong part of the process. As more teams use your design system, it becomes too time-intensive to watch every release to make sure everything that gets shipped is using your system correctly and is consistent with how others are using it.
Instead, focus your energy on proactive education and training. Make sure people know their resources before they start designing or building anything. If you educate people on how to effectively use the design system, they’re more likely to make better decisions when they work on future projects.
R is for Relationships
Your design system bridges the gap between disciplines
Your design system’s ability to bridge gaps between disciplines is your greatest superpower. Your design system reaches far beyond one-on-one collaboration between a designer and an engineer. It has the potential to nurture the relationships between every designer and engineer at your company by empowering everyone to speak a shared language.
S is for Scale
Set up repeatable processes and guidelines that scale your team’s capabilities
Relative to the rest of the company, design systems teams are small — yet they’re tasked with supporting an entire company. The math doesn’t add up, and we often see one-person design systems teams supporting 100 people using the system. If even a couple of those people ask you to pair code or design, that could take up an entire week of your team’s time.
To combat this, you have to scale your team’s capabilities so that your team doesn’t have to be in the room for people to make a decision. If done correctly, you can scale a single skillset (such as visual design) from one person to unlimited.
T is for Thinking Systematically
Systems thinking is your team’s superpower
Traditionally, product organizations are made up of three roles: product, engineering, and design. As a result, you often see design systems teams made up of these same roles. But not just any engineer or designer will succeed on a design systems team — your greatest assets are engineers and designers with a knack for improving the productivity of others around them by solving problems systematically, on a holistic level.
U is for Unifying Disciplines
Engineering by design, design by engineering
There’s an interesting opportunity when your design system sits central to everything: Unify everything! Design, code, process — you name it and we’ll unify it.
How might we, as a design systems community, unify disciplines and empower them to work better, together? We have the opportunity to blend the way code and design work together by building tools that unify those processes. We can get designers working more like engineers by introducing version control. Or build a prototyping sandbox that allows designers to prototype in code — without writing code.
Your design system’s ability to bridge gaps between disciplines is a superpower
V is for Vision
Have a clear vision of what you want your design system to be
Since your system builds bridges between disciplines (design, engineering, and product) everyone will have different expectations of the system. That means that right out of the gate, people might assume that your system is everything, for everyone. Lofty expectations like this are dangerous because they’re unrealistic.
Establish a strong vision and evangelize that to the entire product organization. Explain what your system is, and more importantly what it is not.
W is for Wrangler
That moment of realization: “Have I become a PM?”
As the creator of a design system, you end up doing whatever it takes to keep the system alive. As your system scales, you may notice you’re acting more like a program manager than before. Your day-to-day shifts from hands-on work to managing operations and coordinating. Project plans, roadmaps, timelines, synthesizing feedback — oh my, did I just become a PM?
X is for “X”
Get really good at x’ing things out and saying no.
Everyone will come to you with the next big idea for your system. They’ll ask you to take on a collection of new components by a certain date to help them meet their own deadlines. It’s easy to say yes because it’s a quick way to prove your system’s value early on, but it’s important to set boundaries. Be careful not to commit too much time solving the needs of a single team. Focus on the holistic view and prioritize work that benefits everyone — not just a single team or a single project.
Y is for You
You happen to your design system
Your design system starts with you showing up and being proactive about grassrootsing it. Even if you can’t do it alone, it still takes you to inspire and lead others to believe that it’s a cause worth supporting. Don’t wait for someone to hand you the keys to the design system. Your passion and hard work could be what it takes to grow your system into a dedicated design systems team that wins!
Z is for Zoo
It will feel like a zoo because it is a zoo
Grassrootsing a system and watching it grow from a tiny seed into its own dedicated team is quite the journey. It will feel like order and calm is just around the corner, but around each corner lies new challenges. That’s okay! Embrace the chaos and see where it takes you. The best innovations often come from chaos. Trust your vision, take it one step at a time, and rally your team around creating order from the chaos as you go.
