A How-To Guide for Teams Who

Want to Advocate for Consistency,

Efficiency, and Iterative Improvements

HOW TO GET BUY-IN

FOR A DESIGN SYSTEM
IN YOUR ORGANIZATION
Leading Change At Your Workplace By Proving
the Value of Systematic Design Decisions
01
WHY YOU
ARE HERE
INTRODUCTION
More products to ship, more platforms to launch, more form factors to consider. Depending
on your mindset, this can present you with two different paths to follow. The first centers
on growth and scale: advocating for consistency and quality across all the experiences
you create. This includes a visible push toward opportunities for creativity at speed on your
teams. The other is rooted in chaos and confusion: a lack of clear guidelines, which leads
to individual contributors conflicting in opinions and output, to try and do their best work.

Introducing design systems: the logical documentation process across

an organization that groups together every essential piece that your cross-
functional teams need to design, realize, and develop into a product.

Design systems are increasingly becoming more popular, and tend to be driven by self-taught
people. According to a 2019 survey by Sparkbox, 70% of the in-house respondents and 65% of agency
respondents said they first learned about design systems by reading about them. Design systems
can be scrappy, static, and maybe only need to benefit a few people at the start – but, if adopted
company-wide, transform team culture and the ability to make new things, faster, over time.

Instead of following the rules that someone else has written for them, design and development
teams can drive change by deciding it’s time to write their own principles and guidelines.

Most teams tend to see obstacles come up once they get to the leadership or team buy-in stage.
Without acceptance and buy-in, brands and companies can’t evolve or invest the time needed
to maintain a sustainable system. On a deeper level, it’s also about investing in design consistency
to make gains with a cohesive brand and create opportunities for business growth.

In this whitepaper, we’ll look at practical advice and tips on what design systems can help teams
do; how to make a business case for systems thinking and selling to different stakeholders;
how to reframe return on investment; and the benefits of futureproofing your business.

Maurice Timp, a Design Systems Lead at Netherlands-based Angi Studio will

inspire you with real-life insights. He will also guide you toward piloting a design
system in your organization and driving cross-functional collaboration.

Our goal is to arm you with the tools and templates to confidently drive
the adoption of a design system in your organization.

Ready to learn how? Let’s get into the specifics.

INTRODUCTION 3
02
CONSI-
DERATIONS
WHEN DO YOU NEED
A DESIGN SYSTEM?
A design system is an organization’s single source of design truth for everyone
in your organization. The system will contain a few core elements, such as:

■ a pattern or component library: a digitized collection of reusable assets for a product or service
■ a style guide: the representation of a brand through its visuals and voice

Depending on the organization and team needs, the design system can serve as:

■ a UI kit
■ a set of rules related to user behavior and product scale
■ a company brand book

With a set of defined rules, constraints, and principles, each component works as a tool that helps
teams tie every part of their project together. But if you are part of a smaller team, it is up to you
to take the initiative. You can build a design system from scratch if you decide you need one.

The two biggest benefits of building a design system are:

Speed: an ability to do things quickly can save your company time and money (for example,
a team could work towards the goal of launching a product in half the time it took before)

Efficiency: an ability to prioritize and avoid duplication of efforts across teams (for example, reducing
color shades and styles for more consistent-looking buttons across products and experiences)

Inconsistencies in real life

Designing individual buttons isn’t that hard. But when you’re trying to scale a design
system to serve a larger ecosystem, that’s when issues may become noticeable.

– Maurice Timp, Design Systems Lead at Angi Studio

Wondering if design systems should stay a personal project

or be a collaborative initiative from the start?

“If you don’t get permission or actual budget, and you don’t have a centralised team who actually
works on, governs it, or helps educate people about it, you should still, as a designer create some
kind of UI or written documentation, says Maurice Timp, a Design Systems Lead at Netherlands-
based Angi Studio. “If you think it’s important, you should do it. Other people can benefit from it.”

CONSIDERATIONS 5
Don’t be afraid to make the documentation as detailed as it should be, either. “Maybe
in the early stages, it’s just for you. But at some point when you start sharing it, you can
show that other people on your team are using it. You can use it as a starting point
in a design sprint. It can help you build a case at a later stage for consistency.”

Design systems in real life

I’ve seen it happen: even before there’s an official design system, the developers
have already built themselves a comprehensive platform with all the components
built in without anybody knowing it. The whole team was already using it.

– Maurice Timp, Design Systems Lead at Angi Studio

WHY DO DESIGN SYSTEMS FAIL?

(And What You Can Do About It)

Before you can build a design system that fits cross-functional use cases across your
entire company, you need to make a case for adoption. To make a strong case, it’s
important to find out what obstacles you need to overcome. Here are some potential
roadblocks, and how you can approach problem-solving each scenario:

Setback: Leadership May Not Be On Board With The Project Yet

A design system needs approval from the people at the top of your organizational

chart, but they may have a different mindset to you.

For example, they may have other priorities in mind, not understand the purpose or
business impact of a design system, or have their own ideas about design system
implementation, even if they’ve never built or contributed to systems design before.
How do you make them feel like they have a stake in the project?

Progress: Bring Them In, Early and Often

Maurice Timp and his team at Angi Studio have seen some in-house teams identify
senior leadership and management’s lack of knowledge about design systems as a risk.

To reach the goal of implementing the design system quickly, the teams decided

to involve senior level stakeholders in demonstrations, meetings, and workshops related
to design systems from the very start. The more involved leadership felt, the easier it
was to get buy-in. The idea is to become and stay proactive: by anticipating change
and problems, when they do appear, you can adapt and create solutions instead
of wasting time waiting for approvals or revisions.

CONSIDERATIONS 6
Setback: Your Tech Team May Be Skeptical At First

It’s admirable to have a singular vision for a reliable, systematic way for your
organization to collaborate, save money, and see a faster time-to-market.

But not everyone will see things your way. A difference of opinion is an opportunity
to enlighten teams and bring everyone together. Remember: a design system
only works if it motivates your colleagues to collaborate and communicate across
disciplines. How do you make your technical colleagues feel included in the work?

Progress: Make the Time and Effort to Understand Them Better

Timp recommends sitting next to your tech team members, proactively asking
questions, observing their day-to-day work, and figuring out their most common
obstacles.

“Some designers don’t actually talk to developers,” he points out. “Take an interest
in their work. How they build things. How they use your designs. What kind of software
they work in.”

Start to understand what parts of their workflow are labor-intensive. You can then
start a conversation connecting their problems to how documentation and singular
references may help your developer colleagues code more efficiently. “They start
to see what’s possible, test it, build it, use it,” says Timp. “Because you’ve taken the time
to understand what they’re building, you’ve shown how it benefits them, and they also
feel understood.”

Design systems
in real life
In bigger organizations, what we tend to see is that UX designers will do research and
build a prototype. And when they’re done, show it to developers and say, ‘Good luck,
I’ll see you again when it’s finished’. This is a problem. You can design systematically
but miss out on the advantages of collaborating with your developers. You have
to make sure everyone understands everything. Otherwise, inconsistencies still happen.
And you won’t achieve the speed or pace of working that you were hoping for.

Setback: Design Systems Are Seen As a Side Gig or Extra Credit Work

With multiple teams already so busy during regular office hours, suggesting a new
approach can seem like an extra burden. Designing and developing solutions
to problems don’t happen in individual silos or between ‘hand-offs’ – they’re more likely
to come to life with a shared vision and collaborative way of working. So how do you
bring people together?

CONSIDERATIONS 7
Progress: Restructure Your Teams to Dedicate Design System Ownership

Maurice and his team at Angi Studio will often work with in-house teams to restructure
them. “We end up with a design system team where someone is appointed a design
manager: someone who’s ultimately responsible for the whole thing. Someone whose
role it is to educate stakeholders,” Timp shares. “And then in the product team, we’ll
have developers, designers, content designers. The idea is to get to a level where
everyone understands the system’s governance: who is responsible for what, and how
does it work?”

Setback: Design Systems Are Never Finished

Design systems aren’t a ‘one-and-done’ project. They are ongoing; they evolve as
teams and companies grow. So, always design with the next steps in mind. “There
needs to be a desire to develop things further,” Timp points out. “It’s best not to do
everything at once to get better, ongoing results. You need to have some kind of focus
and say what’s important to you. Even if you work across multiple products every day,
you need to define what’s most important to you.”

How do you decide what to work on first?

Progress: Look For New Ways to Innovate by Prioritising

“We try to come up with some kind of MVP. You don’t want to build a design system that
feels separate from your organization. Even if you have 10-30 products, decide to focus
on 1-3. Then you look at the checklist and figure out the top things you need to build.
That’s your MVP. For example, if you have an e-commerce brand, maybe you need
to prioritize all the checkout flows across the entire website.”

Setback: Your organization’s Teams May Have Lots of Unanswered Questions

According to Timp, his team gets asked the most from in-house designers and
developers about issues like:

■ “How do we collaborate?”
■ “What do we work on first?”
■ “How do we communicate?”
■ “How do we ship new features?”
■ “How do we make sure the design system lives within the organization?”

You may not have immediate answers, but these are important issues to raise. How can
you take the learnings from these conversations and create excitement around a new
solution?

CONSIDERATIONS 8
Progress: Appoint or Train People Outside of Your Team to Champion and Educate Others

An executive-level or leadership champion who believes in your vision can help

you make your case and further the cause for a design system. A leadership-level
cheerleader is especially crucial when you’re not in the room to advocate for why it’s
an important business decision.

“You can make it seem like it was leadership’s idea by saying it was your whole team’s
idea,” suggests Timp.

“For example, you can speak up and say, ‘I’m having issues with this specific aspect
of the design process, and I think we can do better. My colleague says the same thing.
My other colleague also says the same thing. Here’s how we can be better, faster, and
more productive, so we’re not all designing the same thing over and over again.’”

By presenting a united front, the design system isn’t seen as a threat to new ideas or as
a boring task you’re forcing on others. It’s an opportunity to make a change and solve
new problems.

CONSIDERATIONS 9
03
BEFORE
YOU BEGIN
HOW TO TURN YOUR
TECHNICAL TEAM MEMBERS
FROM SKEPTICS TO ALLIES
Many design systems fail because teams from different disciplines lack shared goals,
vision, and language. It’s easy to forget when you’re selling your vision for a new
way of doing things that you’re starting to build a product, not a project.

To bring people along on the journey, gain their interest (and buy-in) by demonstrating small wins,
such as time saved. Your technical team members – developers, engineers, product managers,
for example – need to be sold on the vision and believe that it will solve their pain points.

While one person on your team can be inspired to make things happen (maybe that’s you!),
you need skills beyond your own to kick things off and make systems thinking a reality. You
need developers and engineers to help point out the gap between design and code. You
need a product manager to map out goals and timelines for incremental change.

Here are some things to consider as you take on the challenge

of turning pessimism into a genuine partnership.

CHANGE THE MINDSET OF OTHERS,

BY CHANGING YOURS FIRST
Design systems are rarely set-up to look and feel pretty … and you shouldn’t wait
to share or build one until it looks good enough. Their real value lies in being able
to create a level of consistency and predictability in team workflows, and save your
team members time and effort so that they can spend time on higher-value tasks.

It’s not just about design: it’s about who advocates alongside you. Involve your product
team early. Find the engineer who can see what you’re trying to achieve.

Also, hang out with developers to start speaking about your goals in their language: you’re not
just designing new components but also building them to be testable and source-controlled.

SET UP DESIGN OFFICE HOURS

Formality breeds silos; silos separate people from doing great work together.

Even if you are the only person in your company who works in your specific discipline,
it’s still worth making yourself available to learn more about existing attitudes or
concerns across your organization, and how you might influence them.

BEFORE YOU BEGIN 11

Roundtables, one-on-one sessions, or informal chats are ideal formats to make yourself
available to answer questions, get feedback, or share ideas. Make sure to set up a regular
time or open calendar slots, automate a reminder or two, and show up, ready to engage.

SCHEDULE REGULAR
DESIGN REVIEWS
OR POST-MORTEMS
After you get your teams to talk about design system issues every day, it’s time to consider
scheduling regular reviews or check-ups to diagnose what needs to be done next.

This is a good time to look at your design system critically, and discuss:

■ What works and what doesn’t

■ What needs to be improved and by when
■ What needs to be prioritized
■ How to create or revisit your roadmap to make sure that your decisions reflect business needs

MAKE YOUR SYSTEM

EASY TO FIND
(And Keep Everyone Engaged)

Open communication can make or break how (or if!) your design system gets adopted.
Anyone who needs it should be able to figure out where the design system lives.

Create a centralized location where anyone in your organization can quickly find the answer
to a problem they’re facing. Remember your secondary audience, too: your teams may need to share
it with a colleague, client, contractor, or new hire who needs to understand your organization quickly.

It’s also worth creating alerts for every design system update or creating a specific
channel or group to answer design system-related questions across the entire
organization. As progress happens, document it every step of the way.

Now that your team’s on board, how can you get leadership to invest?

BEFORE YOU BEGIN 12

04
SELLING
YOUR VISION
HOW DO YOU MAKE
A BUSINESS CASE FOR
DESIGN SYSTEMS?
By now, you’ve been thinking carefully about why you need to build a design
system and the obstacles that stand in the way of organizational change.

You’re now ready to take your research and learnings, and sell the narrative to leadership.
The aim is to gain the money and resources to make your scrappy DIY design system – or
a lack of documentation – into an initiative with more budget and people’s power behind it.

With a little preparation and support from your colleagues, you can start the buy-in presentation
process. Every company is different, but the basic structure of a buy-in presentation is:

■ Define the problem
■ Explain the risks to the company
■ Offer the solution

After the presentation, there are usually follow-up meetings

to identify the next steps. Next steps can include:

■ How you plan to implement the design system in your organization

■ How much it’s going to cost
■ Reviewing paperwork

To build out a detailed case for a design system, make sure to lay
the groundwork and do some background research.

IDENTIFY THE NEED
FOR A DESIGN SYSTEM
Know the problem you’re trying to solve. Do you feel the product vision has been lost?
Are inconsistencies holding back innovations? Are designers and developers siloed in how
they work? Before you figure out your tools and approach, you need your ‘why’.

If you can’t articulate the problem to your team or leadership, your case is lost.

Be careful of adopting design systems for the sake of following a trend. Let go of the ‘everybody’s
doing it’ logic. Instead, consider the opportunity from the customer’s perspective: what
internal decisions will translate to the best public-facing customer experience?

SELLING YOUR VISION 14

FIND YOUR PEOPLE
Organizational buy-in works on two levels: first, you need a clear yes from your team. “These
are your colleagues who see the same problems as you and can back you up when you’re
put on the spot,” advises Maurice. “Otherwise it’s you against the rest of the world!”

Secondly, you need a clear go-ahead from your stakeholders. These are the people
in your organizational chart who control the budget and approval processes.

Your checklist for

a presentation to the team:

Describe the process of building the interface inventory

Present critical inconsistencies from every category

Explain why these inconsistencies are detrimental to the experience

of users or are negatively affecting the software development process

Present building a design system as the answer to the challenge

Explain that building a design system is an ongoing process

and that you would like to build a small team to manage this process

Clarify that all designers and developers will have the right to contribute to the system

Get a definite ‘yes’ from the team

Your checklist for

a presentation to stakeholders:

Describe the process of building the interface inventory

Present the key inconsistencies from every category

Focus on numbers and the influence on the speed of the process

(62 shades of gray, 16 types of buttons, 5 icon libraries, and so on)

Explain why these inconsistencies are detrimental to the experience of users or increase
the cost of software development (hours involved multiplied by average salary)

Present building a design system as the answer to the challenge

Explain that building a design system is an ongoing process

and you’d like to build a small team to manage this process

Emphasize that building a design system will help the company

deliver a better experience to the market faster

Get a definite ‘yes’ from the team

SELLING YOUR VISION 15

DO A DESIGN
OR PRODUCT AUDIT
For a design system to be useful and survive organizational change or challenges, you
need to think it through. Audits help you – and everyone on your team – understand how
‘big’ your product is, how inconsistencies can be traced back to different people designing
different solutions for the same problems, and help sell the power of reusability.

1 Identify your
2 Identify user flows
user objectives
Note down all the different flows
What are all the different things a user can go through in your product
users might do in your product? to complete a task, in connection to
their goals or objectives.

3 Identify pages
4 Identify key
page patterns
List all the pages your user will
come across during a particular flow Break down each page into
(for example, a shopping cart checkout its patterns or components.
or search query)

Bring it all together

Based on what you’ve found, what are the inconsistencies
and opportunities for reusable components?

Timp suggests using Keynote or Figma to tear up your product screens and
‘match’ buttons, headers, footers, and other key elements together.

At the end of an audit process, your team can summarise your findings and better
understand what kind of problem you’re dealing with, and how to make things better.

SELLING YOUR VISION 16

WHAT IF LEADERSHIP HAS
QUESTIONS ABOUT RETURN
ON INVESTMENT FOR YOU?
It’s to be expected that your leadership team or management will ask how you can
demonstrate a return on investment in a design system. Here are some ways to measure
success, and prove the adoption of a design system is making a difference:

Before and after survey results

gather your quantitative delivery (percentage of perceived speed delivery,

before and after), and qualitative data (team or individual rationale)
regularly, to point to a change in productivity or morale.

Impact on go-to-market
launch speed or project management

compare requests or projects with similar point weights or scopes to quantify how quickly
each request or project was completed before or after the design system was introduced.

Feature bugs or improvements

keep track of bug reports, or how stable components remain – ideally,

automation rather than building from scratch equals more stability

SELLING YOUR VISION 17

05
DS DESIGN
SPRINT
HOW TO ACHIEVE BUY-IN
BY INVITING AND INVOLVING
YOUR ORGANIZATION IN 
YOUR DESIGN SYSTEM PILOT
Change can make people nervous. By finding ways to introduce iterative change, however,
teams can rally around a shared desire for doing things differently and more efficiently.

What’s The Pay-Off of a Design System?

Alignment on the long-term product vision

Leadership isn’t the only team you’ll need to involve in getting a design system off the ground.
Don’t forget your developers and engineers, content managers, user experience researchers,
performance tests, or delivery teams. Everyone will need the system for different reasons, but
need to come together to achieve common goals.

Democratic decision making throughout the sprint

Shared knowledge, needs, and strategic thinking mean you’ll be able to focus on the right
ideas and features. When everyone feels involved, and information flows freely, they also feel
respected.

Fostering a shared sense of ownership and rewarding innovation

Once people start to realize what they are personally responsible for contributing - either as
a marker or a user - they will be driven to work together, with an agency, to find inexpensive
ways to drive long-term organizational change.

Studio Angi recommends adopting a 4-day design system take-off or sprint process.

“It’s a great process to start from nothing. You end up with a validated product
on day 4 or 5. We thought: why can’t we do that for design systems?”

— Maurice Timp, Design Systems Lead at Angi Studio

DS DESIGN SPRINT 19
Day One:

FINDING INSIGHTS AND INSPIRATION

This first day helps the entire team get to know each other. “We have two hours of interviews with
a design manager or product owner,” says Timp. “We also interview designers and developers.”

It’s essentially a crash course on design systems: what they are, and
how they can change your business for the better.

Angi Studio recommends doing group interviews instead of one-on-one interviews. “We do this
so that the designer can ask the developer questions and vice versa. Maybe the developer has
questions about how the design works. Or how a developer can make the design more efficient?
How can design be implemented faster? How can different team members’ needs be met?”

It’s also important to define the size of the team: how many disciplines

exist, and if agencies and freelancers are involved.

Other questions to define the level of systems maturity in an organization include:

■ What kind of tools do you use to create your products or services?

■ Do you have a brand guide?
■ What type of platforms do you support?

“We also look at other design systems, to see what other companies do.
This helps teams understand whether they want to focus on content, on
the brand, on the technical side, what the benefits are, and so on.”

You start on day one with company goals, but by the end of the process, it
should lead to structural change, and prevent systematic variations

Day Two:

MAKING DECISIONS
This second day focuses and defines across-the-line collaboration,
product focus, and tools selection. Questions include:

■ How do we get a component in our design system?

■ How can we get it developed and then deliver it to our teams?
■ How do we promote our design system?
■ How are we going to onboard our team?

DS DESIGN SPRINT 20
Then you need to think about the people part of the equation:

■ Who’s involved?
■ Who’s doing what?

And process-based questions matter, too:

■ How do we do things?
■ What technology do we use?
■ What frameworks or tools are we using to accomplish things in the organization?

Day Three and Four:

BUILDING VERSION 0.1

By day four, your team will have defined a Minimum Viable Product. Out
of everything you could potentially build, what’s most important?

A design system should feel connected to the rest of your organization – instead, it should
blend it and serve a purpose. Your MVP helps you prioritize what to focus on – for example, out
of 30 products, you can decide to improve 1-3 of them. As an example, your teams may notice
inconsistencies with all the checkout flows across the entire website, and focus on improving them.

An MVP brings structure to chaos. Timp recommends planning for best results:
“We try to get the team to follow the process we defined beforehand, with
the tools we defined beforehand, in the roles we defined beforehand.”

“At the end of the 4-day process, you may have 1 to 3 parts in your component library.

It’s less about the components you’ve built and more about

the communication you’ve opened up across teams.

“The goal of building a 0.1 version of a design system is not to deliver a prototype or share insights
gained from building one,” says Timp. “You set-up a design system so that the team can build
a future. Connecting everything in place, and making sure they’re comfortable with expanding.”

‘If you’re hiring you can make your design system public for candidates
to see. You can show them: we take design theory seriously; we take
development seriously; these are our standards; this is how you’re going
to work. That can be great for recruitment. Someone can think, ‘I’d
love to work there because they value design and collaboration’
– Maurice Timp (Design Systems Lead at Angi Studio)

DS DESIGN SPRINT 21
06
DESIGN
SYSTEM
MATURITY
INDEX
FIGURE OUT WHAT ‘STAGE’
OF DESIGN SYSTEM MATURITY
YOU’RE AT
Design maturity levels can change depending on the kind of organization and industry you work
in. You may want to work at a company that already has some iteration of a design system. Or you
may be excited by the challenge of being the person hired to champion and help implement systems
thinking. Here’s a broad spectrum for where you can find yourself as an employee or leader:

No design system.

Designers may not exist here, or designers might instead be engaged as freelancers
and contractors. This leads to a lack of consistency. Developers are relied on to create
UI elements without a designer to back them up. A leader may have realized
that user experience matters and wants to grow the discipline in-house.

A style guide is born.

A single discipline (like marketing or engineering) has taken charge and created
some static brand guidelines for themselves. Things are rarely written down, but
information flows directly and seamlessly. It’s likely the product is very young and
new components are made and communicated with the team as needed.

A pattern library joins the style guide.

Designers and developers are creating new components, but new hires are often
onboarding enough to see inconsistencies and duplications. Detailed documentation
for team rationale doesn’t yet exist, but some members have more knowledge
than others. Slack messages and emails are used to clarify any confusion.

A design system becomes part of the day-to-day workflows

Some people contribute to updating the design system, but far more people have come to rely on it
to do their job. A specific team may form to take responsibility for documenting and keeping track
of components and rationale. The goal is to make the system interactions as automated as possible.

The design system advances

(fully integrated, governed, with a roadmap for future growth)

Expect beautiful websites with detailed documentation. Advanced enough that no

direct communication is needed between the users and makers of the system.

Whichever scenario you’re in, ultimately, you want to create a culture where every point-
of-view across different roles and departments is included and considered equal.

DESIGN SYSTEM MATURITY INDEX 23

CONCLUSION:
The power of design systems relies on creating something people can believe in.

You’ve now learned that building a design system doesn’t have to change the world
or happen overnight. A systems approach takes a lot of planning, scoping, and
communication to create a shared vision across a whole organization.

Your first design system comes to life by gathering disciplines together to define,
pilot and evaluate what works and what doesn’t. To make this a reality, you need
to become comfortable with selling your ideas to other disciplines and leadership.

The right people, at the right time, working on a realistic scope, can not only help build
things your organization needs but also change the culture of how things get done at your
workplace. It won’t be a smooth process the entire way through, but that’s okay. Learn from
your mistakes to better define what success looks like, and what you should be focussing on.

Don’t worry about what tools you use: instead, boost your design system by collecting insights
from across your organization, being open to taking advice, and solving problems as a team.

DESIGN SYSTEM MATURITY INDEX 24

07
TAKEAWAYS
& TOOLS
KEY TAKEAWAYS:
Design systems can improve an organization’s speed and
efficiency – think of it like a product, not a project

You don’t need an official design system to start documenting decisions – you can
start a scrappy system yourself, and make an effort to share it with others

Leadership may not understand the return on investment of design systems,

which is why you need to invite them to get involved early and often

Technical team members may be skeptical, but if you take the time

to understand their pain points, they can be your biggest allies

A buy-in presentation can help you tell the story and make a business

case for why your organization needs a design system

A pilot design system, or defining a Minimum Viable Product, is

a valuable investment for any systemless organization

The size of your team will change and grow but what should become the norm
is a culture of collaboration, iterative improvements, and transparency

Tools and Templates from Angi Studio to Help

You Develop Your Design System Superpowers:

Step 1: Design principles document

Helps build a foundation for your teams about what products and services
exist in your organization, and what you should focus on.

Step 2: Buy-in presentation template

You and your teams believe a design system should exist – now it’s
time to sell it to leadership with a convincing presentation

Step 3: Design system checklist

This checklist helps you prioritize and work out what features,
components, and product or user flows to focus on

Step 4: Design system process puzzle

This game helps teams collaborate and work out how to build design system components
together. Most importantly, it gets everyone talking and sharing ideas!

TAKEAWAYS & TOOLS 26