Version 3

Version 2

Version 1

DSM
THE 2018

Field Guide
USERNAME

[email protected]

PASSWORD
 Written by:

Ben Goldman

Contributors:

Aarron Walter
Marco Suarez
Ehud Halberstam
Chris Avore
Emily Campbell
Drew Bridewell
Andrew Godfrey

2
PA R T I

Introduction to design systems

8 How to use this guide

What is this guide? Where does the content come from? What’s the goal?

9 Design Systems overview

What are design systems? A brief overview of design systems today.

10    New trends and challenges

Why have design systems become so important? What are the trends
and challenges that have given rise to design systems?

14    Benefits of design systems

What problems do design systems solve? What are the main benefits
companies are seeing from design systems? How does DSM better
help design systems efforts?

3
PA R T I I

Getting started with

design systems

18    Running a design audit

Why are design audits important? How do you conduct them?
What do you do with the findings?

28   Getting buy-in
How do you convince other stakeholders to buy-in to design systems?
Who needs to be part of the conversation? What are the challenges
of each stakeholder?

36   Team models for building a design system

Who should be part of the core design systems team? How do you
structure communication? How do you determine responsibilities?

40   Creating your UI library

What should be in your MVP? How should you organize assets in your
library? What should you use (Sketch)? What are some best practices
around naming conventions? Creating new assets vs. extracting
existing ones.

4
PA R T I I I

Bringing your design

system into DSM

46   Why do I need DSM?

What is the difference between your master Sketch file and a design
system? How does DSM help me once I have my UI library?

50   Getting your library into DSM

How do you get your assets from Sketch into DSM? How should you
organize it? What should be in the descriptions? Overview of Shared
Drafts, vs. release versions, and when to use what?

54   Version control
Who should you invite? When should you release new versions?
How do you manage updates? Version control best practices
(major v. minor releases).

60   A guide to design tokens

What are design tokens? Why are they important? How can developers
leverage design tokens? What do we support and what is planned?

64   The Web Monument Site

What is the monument site? How can it be used?

5
Conclusion

68   Final thoughts on design systems

6
PA R T I V

Resources

70  Introduction

72   Design Leadership Forum

73   Workshops

74   DesignBetter.co

74   Design Disruptors

74   The Loop

75   Webinars

75   Design Specialists

7
PA R T I

Introduction to design systems

How to use this guide

Design systems promise to revolutionize the way we build digital

experiences by making the process smarter, more efficient, and more
rigorous. They have the potential to create dramatic time savings
for both designers and developers; to help our products scale more
gracefully; and to free up time from repetitive work so that all teams
can focus on solving bigger problems.

But as with any system, building a design system is not a quick or easy
task. It requires rethinking how we’re making digital products today,
and laying the groundwork to set us up for success in the future.

Fortunately, this guide should help.

What follows is a guide that’s compiled from a variety of thought-

leadership content produced by the InVision team on our journey
towards creating DSM–the world’s most powerful platform for
design systems.

8
The content is split into three parts:

An introduction to Best practices How to manage your

design systems on building your first design system at scale
design system with DSM by InVision

The goal is that by the end of this guide, your team will be well
positioned to start leveraging the full value of design systems in your
product design process. It’s not an easy task, but it’s a critical step
towards making digital products a long-term competitive advantage
for your business.

9
 New trends and challenges

Hockey sticks have become the new norm in today’s post-digital world.
No matter what trend you look at–from the amount of time spent online,
to the number of internet-connected devices on the market–all graphs
trace the same hockey stick slopes. In many ways, these slopes have
come to symbolize the digital age, and illustrate just how thoroughly
society has been changed due to these disruptive technologies.

The Internet of Everything

The Hockey Stick

20M
Number of Devices in Use Globally (in thousands)

18M

16M

14M

12M

10M

8M

6M

4M

2M
2007

2012

2014E

2015E

2016E

2017E

2018E
2011

2013
2004

2005

2009

2010
2006

2008

PCs Smartphones Tablets Internet of Things

Connected TVs Wearables Connected Cars

10
At the same time, this radical change has saddled product teams with an
ever-growing list of challenges that add whole new layers of complexity
to their jobs.

Some of these new challenges include:

Designing for multiple devices and screen sizes

Digitizing more areas of business

Expanding scope of digital products

Growing team sizes

Coordinating with more stakeholders

Optimizing processes to ship products faster

When we look at these challenges, and the trends that have created
them, one point has become abundantly clear: our current processes
for designing digital products are not sustainable. They’re not sustainable
now, and they certainly won’t be sustainable in the future, because
these trends will only accelerate.

11
 Brad Frost perhaps expressed this point most powerfully in his
Future-Friendly Manifesto when he wrote:

“ Disruption will only accelerate. The quantity and diversity

of connected devices — many of which we haven’t imagined
yet — will explode, as will the quantity and diversity of
the people around the world who use them. Our existing
standards, workflows, and infrastructure won’t hold up.
Today’s onslaught of devices is already pushing them to
the breaking point. They can’t withstand what’s ahead.

B R A D F R O ST, F U T U R E - F R I E N D LY M A N I F E STO

The good news is that innovation has a way of adapting to even the
most extreme challenges. And that’s exactly where design systems
come in.

In some ways, design systems are the result of a convergence of several

overlapping theories and practices that have existed for decades; from
component-based software development, popularized by Douglas
McIlroy in the 1960s; to Brad Frost’s atomic design theory, which was
pioneered almost 50 years later.

12
Though each of these concepts refer to something different, they all
converge at one functional point in design systems–enabling teams to
build better products faster by making design reusable. This is the heart
and primary value of design systems. A design system is a collection
of reusable components, guided by clear standards, that can be
assembled together to build any number of applications.

And while this sounds simple on paper, the difference this makes in
how we build digital experiences is nothing less than transformative.

Introduction from the Design Systems Handbook

In the 1960s, computer technology began outpacing the speed of

software programming. Computers became faster and cheaper, but
software development remained slow, difficult to maintain, and prone
to errors. This gap, and the dilemma of what to do about it, became
known as the “software crisis.”

In 1968, at the NATO conference on software engineering, Douglas

McIlroy presented component-based development as a possible
solution to the dilemma. Component-based development provided
a way to speed up programming’s potential by making code reusable,
thus making it more efficient and easier to scale. This lowered the effort
and increased the speed of software development, allowing software
to better utilize the power of modern computers…

Now, 50 years later, we’re experiencing a similar challenge, but this

time in design.

13
Benefits of design systems

Design systems have emerged as an increasingly hot topic in recent

years because of how they help product teams solve these new
challenges of the digital age. But not only do design systems solve
challenges, they also bestow considerable benefits onto the product
teams that get them right.

The main benefits of design systems can be reduced to three

main categories:

Speed: Being able to assemble digital experiences from a set

of pre-existing components makes the product design process
dramatically faster. Not only does it reduce the amount
of re-work for designers, but it also reduces re-work for
developers, since developers can utilize code that was
created, tested, and implemented previously.

Scale: When designers work from a common visual language,

it makes the process of scaling our digital products easier.
Instead of punctuating our products with disjointed design
elements, we can ensure that designers are working from the
same UI library as captured in our design system, resulting in a
better user experience. It also combats the increasing problem
of “design debt,” by making it easier to make a change to one
component, and then roll that change out to other areas of the
product with that same component.

14
Innovation: With a design system, a designer doesn’t need
to spend time thinking about how a button looks, or what
styling to provide a form field. Those decisions have already
been made by a dedicated team. This eliminates the need for
redundant and repetitive work, thus freeing up a designer’s
time to solve bigger business problems, such as creating
innovative user flows. And the same benefit also extends
to developers.

15
 “
Agile, cross-functional teams benefit immensely
from a design system because it allows the
team to collaborate using a common language.
Experimentation and prototyping goes faster,
developers get early insights into potential
technical constraints, and the team can focus
time on bigger problems without sacrificing quality
or efficiency. The biggest benefit I’ve experienced
from adopting a design system is when our
team’s conversation moved from discussions
about visual solutions to discussions about the
problem. In that regard, design systems bring
everyone closer to the user.

E M I LY C A M P B E L L , D E S I G N S P E C I A L I ST AT I N V I S I O N

16
“ One of the biggest values [of] a design system is that
it increases productivity by providing fundamentals that
reduce duplication of effort.

D AV I D C R O N I N , G E

“ A design system contains components that can be

combined and reused to build user interfaces. It enables
teams to focus on how a user interacts and converses
with a piece of software, rather than arguing over what
color a button should be.

IBM

“ A unified design system is essential to building better and

faster; better because a cohesive experience is more easily
understood by our users, and faster because it gives us
a common language to work with.

AIRBNB

17
PA R T I I

Getting started with

design systems

Now that you understand what design systems are, and how they can
help your team, it’s time to get started building your own. The following
chapters will guide your team through the basic steps necessary for
creating a performant design system.

Running a design audit

Starting a design systems initiative requires achieving buy-in, which

is why a design audit (or “UI inventory”) remains an important step.
A design audit is simply a visual collection of design assets in use
across your entire product line. But what this does is provide your
team with an invaluable overview of the design debt that’s accumulated
in your products.

18
“ Where Technical Debt affects the integrity of the codebase,
Design Debt affects the integrity of the user experience.
This is what happens when a bunch of incremental changes
collect over time and yield a disjointed, inconsistent, and
patched-together experience.

AU ST I N K N I G H T, D E S I G N D E BT

19
In addition to chronicling design debt, an audit provides a valuable way
to take inventory of what components, patterns, and styles are being
used throughout the entire platform. This can help you prioritize which
components need to be worked on first based on the amount of usage.

For Example: You could have tooltips used throughout your

product. You realize you use them on every single page in
the product but you also realized that you have 4 different
variants of tooltips being used.

This is an opportunity to prioritize tooltips and componentize

them to design a pattern that works for all scenarios.

Without an inventory/audit of your system this might never

have happened.

20
 “
In addition to a formal design audit, consider
running surveys or interviews of potential
end-users of your design system, like developers
and other design teams. This can help you learn
about existing code patterns, give you insight into
how to structure your eventual documentation,
and find champions and partners that can help
you with adoption of your system.

E M I LY C A M P B E L L , D E S I G N S P E C I A L I ST AT I N V I S I O N

21
Before you audit, know what to audit

Before you begin the audit, identify which products should even be
included in the audit in the first place. In many larger organizations, you
may have dozens--sometimes even hundreds--of products, and not
every piece of software will benefit equally from the design system.

For organizations with multiple products, we recommend identifying

one flagship product to utilize the design system, and ideally one more
product in your portfolio.

This approach provides a few benefits:

1. You immediately focus attention on comprehensively addressing

one product
2. You demonstrate how a design system serving one product can also
cascade to other products in the portfolio
3. You can work with multiple business, product, and engineering
leads to get additional diverse perspectives of what a design system
needs
4. You may gain credibility with senior stakeholders since you’re
not trying to take on an impossible task in retrofitting dozens of
legacy platforms. By strategically identifying candidates for the
design system, you’re showing you can prioritize what will secure
the biggest benefit for the design teams, engineering teams, and
ultimately the entire organization.

22
 “
For companies that don’t get design systems, a UI
inventory is the way you communicate why this is
important. Making the pitch for a design system
“stop the presses” style – that’s a tough sell. But
when people start to see the design debt that’s
built up, or the technical debt required to support
that, that’s when you organically begin to change
minds. If you have 50 different button styles, think
about the code required to support that. Innovation
gets slowed down, and everyone gets lost in low-
level details instead of thinking about, “What’s the
problem we’re trying to solve for our customers?”

A A R R O N WA LT E R , V P O F D E S I G N E D U C AT I O N AT I N V I S I O N

23
Performing the audit

Conducting the audit doesn’t require overly formal processes,

but it should be as thorough as possible.

Start by collecting screenshots of different design elements as they

exist in your product today. Then group these together by category
(e.g. “buttons,” “forms,” “navigation”) in one place, such as a Sketch
file, Keynote presentation, or InVision Board or Freehand.

Pro tip: To get a quick overview of the colors and typography

used on your website, check out https://cssstats.com.
This can help quickstart your process.

Pro tip: If you choose to consolidate the design inventory into

a Sketch file, you can quickly share it out via InVision Freehand
to get other eyes on it. Simply install the Craft Manager plugin
and click on “Freehand.”

24
Visual Assets Colors

Font Colors Fonts

UI audit inside a Sketch file

25
Visual Assets Colors

This is our
standard color

Font Colors Fonts

All of these need to be redone

Collaborating around a UI audit in InVision Freehand

26
When sharing the results of the design audit with colleagues, it’s
important to communicate how the inventory translates to lost time
and resources. What appears to be a simple button on the surface
can actually conceal many hours of work implementing that button.

According to design systems expert Nathan Curtis, he calculates that

teams waste anywhere from $20,000 to $1,000,000 annually just on
buttons alone, depending on the size of their teams and products.
And that doesn’t even get into cost inflicted to the business by having
an inconsistent user experience across your product lines. But with
a design system, this work can be completed once, saving countless
resources over time.

Design audits help you communicate all of these consequences and

benefits in a clear and concise way. And they’re a critical step towards
the next important step for design systems–achieving buy-in.

Rough illustration showing the “iceberg” of technical debt underlying even the
simplest of buttons

27
Getting buy-in

Building a design system can’t happen in a silo. For a design system

to become truly valuable, it must be adopted across your organization,
and that requires achieving buy-in. Evangelizing your system for new
and existing team members will be an ongoing project. To do this,
you’ll need to make a business case for design systems.

Running a design audit can help this process dramatically. It provides

a simple visual overview of the design debt that has accumulated in
your products.

But there are other ways to communicate the urgency of a design

system as well. Here are a few potential areas to explore with your
team as you start to make the case:

The growth of your digital products: Take a look at your digital

products today, and compare them to where they were even
five years ago. If your company’s situation is anything like
most, your digital products will have grown significantly.
As our product lines grow, so too does the challenge of
managing those products.

28
The size of your backlog: It’s one thing to look at the size of
your digital products today, another to look at where it’s going
to be in the future. Backlogs and roadmaps provide a glimpse
into all the challenges ahead of your team–challenges that
can be greatly minimized with a design system.

The growth of your team(s): Growing product sizes aren’t

the only factor that contributes to complexity. As your design
team grows, so too does the challenge of ensuring everyone’s
work remains consistent. Design systems enable a large team
to maintain consistency by providing the building blocks for
your user experience. It also greatly reduce the ramp time for
new hires, since they can begin working with the pre-existing
components immediately.

The increasing competitiveness of your space: No matter what

industry you’re in, odds are that new competition sprouts up
almost daily. One of the ways that competitors gain an edge is
by bringing products to market faster than their rivals. Whether
you’re the mainstay incumbent, or the hot new startup, design
systems will help you bring products to market faster.

29
 Achieving buy-in from developers

Perhaps the most important team to achieve buy-in from is the

development team. When communicating to developers, make sure
to stress how design systems will make their lives easier.

According to Stuart Frisby, the head of design for Booking.com,

“The primary benefit to developers is that it reduces repetitive, dull work
from their workload.” Frisby cites the amount of effort that goes into
coding something like a mobile carousel. With a design system, Frisby
says, a developer can code this once and then reuse it indefinitely.
It also allows them to invest the time and energy into creating
high-quality code upfront, since they know it will be put to good use.

“Engineers that pride themselves on creating good performant work don’t

want to cut corners,” says Frisby. “If they can use the carousel in the
design system, and be sure that it will work, and be sure that it will be
better than what they can create in the 2 or 3 days they have in the sprint,
they will see the benefit immediately. You only really need an engineer to
have that realization once to become an advocate for the design system.”

Another important point is to communicate the design system as a

solution to technical debt. According to Aarron Walter, InVision’s VP of
education, “A design system means standardized code components that
are easier to maintain, lighter weight, and you can potentially improve
the speed of a product by having standardized pieces of code, because
you’re not recreating things over and over again. You’re reducing entropy.”

30
Of all the allies that you will need to build a successful design
system, the most important may be the front end developer. According
to Aarron Walter, InVision’s VP of education and the former head
of design at Mailchimp:

“
“If there’s a key step, it’s to find a front-end
developer (FED) ally–someone who knows how to
write the code components, and who understands
the importance of the design system. When
forming your core design systems team, always
ensure that there’s at least one FED.”

A A R O N WA LT E R , V P O F E D U C AT I O N AT I N V I S I O N

31
 Discovery research

Conducting discovery research with your target audience (primarily

design and engineering) is a great way to get teams to feel included and
involved from the start, and can significantly help your buy-in efforts.

While some smaller organizations may have their engineers onsite and
you can discuss the goals of the design system over coffee, there
are many teams and organizations that don’t have that luxury. In those
instances, try using an online survey tool to ask questions across the
entire development organization. Use the survey to question your
assumptions about the technologies used, where those teams have the
biggest pain points, and how familiar they are with design systems, either
in prior positions or through their own exploration.

Consider using these questions as a starter:

1. List the primary products you work on

2. Describe the technologies you use in your day to day development
workflow
3. What do you and your teams currently use to increase reusability &
portability?
4. How familiar are you with design systems?
5. Who else should we be talking to in your team?
6. Would you be open to a 20-30 minute follow-up conversation to
discuss your responses?
7. Would you like to receive updates via email (about 1-3 a month)
about our progress?

32
Surveying your developers to uncover pain

All the tokens, audits, documentation, and reusable components won’t

mean anything without buy-in from the teams who will use the design
system first-hand. Likewise, it’s easy to say you should get buy-in from
the development teams, but it’s another thing to actually do it.

One useful way to communicate the need for a design system is by

uncovering the pain associated with the current way of doing things.

Consider asking developers to rank the pain of the following tasks

on a scale of 1 to 5, with 1 being not a challenge at all, and 5 being a
significant challenge:

1. Finding the right color, font, or other front end/presentation layer

component to use
2. Reusing one component or pattern (either elsewhere in your
primary application or another application all together)
3. Reading appropriate documentation about which component to use
and when
4. Reusing code or components from other development teams
5. Confirming the design you’re working from is the latest approved
design artifact
6. Losing development time due to meetings about which
components or artifacts to use
7. Refactoring existing work after an update to a design pattern or
component

33
System goals

With a solid understanding of your development organization’s awareness

and interest in design systems and a coalition of cross-team allies, you
can begin creating a realistic plan of what your design system will and
won’t include, and then dive into auditing your current interface assets.

This plan doesn’t have to be overly prescriptive or carved in stone.

But showing a plan goes a long way in convincing development and

product executives that you’re thinking about, and accounting for, how
to turn this design system from an abstract idea to the foundation of your
organization’s digital product strategy.

Be prepared to capture, articulate, and defend the goals of the design

system in a deck or other presentation you can deliver to teammates,
partners, and stakeholders throughout the organization, regardless of
their familiarity with the technical underpinnings of the design system.

Even if your organization is resistant to communication via decks or

presentations, there’s still value in capturing the following themes in one
place to give you a signpost of where you started and what you thought
was possible when you revisit the presentation at a later milestone.

34
 Such a presentation, at minimum, should address the following topics
and themes. Do your best to get each theme on only one slide to craft a
concise, but thorough, plan.

1. Who you have spoken to when exploring the idea of a design

system?
2. Why a design system is necessary now?
3. Describe the scope of a pilot design system–what products are in
and which are out (be prepared to discuss the rationale behind what
you selected for the pilot)?
4. Estimated timeline for the pilot–describe how many months it will
take, how many hours per week, if some weeks will require more
time than others, etc.
5. Your best guess at the team of volunteers to support the pilot
6. Measures of success to determine you’re on the right track and your
estimates are proving accurate.
7. High level plans for a full feature-rich design system if the pilot is
approved, and the pros and cons of bringing on a dedicated team.
Describe what you need to learn to determine if you’ll recommend
furthering the pilot.
8. Immediate next steps.

“ Practice getting your main points into bite-size soundbites.

Repeating the vision and goals of the design system
in jargon-free, concrete language will strengthen your
negotiating position.

C H R I S AVO R E , D E S I G N S P E C I A L I ST AT I N V I S I O N

35
Team models for building a design system

So, you’ve achieved buy-in. Maybe you looked at your growing

product backlog, and demonstrated the need to design products
faster. Maybe you’ve catalogued all the design debt that has
paralyzed your ability to innovate and add new features.

However you did it, you’ve made the case for a design system,
and received the necessary buy-in. It’s go time.

But now the question shifts from why you should build a design
system, to how.

In this chapter we’ll discuss the four main models for building
a design system.

Utopian Model: In a perfect world, a design system would be

treated like a product, not a project. This means you would hire
a core team whose sole job is to build and maintain the design
system. This could include designers, front-end developers,
and possibly even a product manager. The benefits of
this approach are obvious, but there still remain important
downsides. The biggest downside is that a design system
requires broad adoption to succeed, and if the existing design
and product team feel they have no stake in the design system,
it could hurt this goal. Additionally, many companies simply
don’t have the budget to hire a core design systems team.

36
20% Model: Based off of Google’s “20% time” policy,
this model is when you assign a group of designers and
developers to make progress on a design system as a
part-time “project.” In other words, do it in your own time.
This is perhaps the easiest way to get started with a design
system without disrupting the status quo, but rarely are design
systems successful when built in this way. A design system
requires intensive heads-down time, close alignment between
members, and a commitment to advocating and raising
awareness of it. This model makes it hard to achieve
any of the above.

Skunkworks model: The skunkworks model is among the most

effective for building design systems, especially for companies
that can’t hire a dedicated design systems team. Historically,
“skunkworks” refers to an experimental, specialized initiative
inside a larger organization. Using this model, a core team
is given a predefined amount of time to focus exclusively on
building out a design system. Once completed, they present
the design system to the broader organization and continually
advocate for it. But be careful not to mistake Skunkworks for
Secret--you’ll alienate stakeholders and possible allies if they
feel surprised or caught off guard when you start socializing the
design system.

37
 Contracting: Some companies have found it worthwhile to
offload all the hard work of design systems to an outside
firm or agency. This can speed up the process of creating a
design system, but going this route can create a problem of
ownership once the design system is handed over. And similar
to the problem mentioned in model #1, this route can create
obstacles if the main design and development teams don’t
possess a sense of shared ownership for the end result.

38
Sample design systems team makeup:

UX Designer Visual Designer

Front-End Front-End
Developer 1 Developer 2

Content Writer Product Manager

39
 Guilds: a post-launch team model

Design systems are products, not projects. They require ongoing support,
maintenance, and improvements. That’s why a “guild” can be extremely
effective models for ensuring your design system receives the love and
attention it needs to succeed after it’s built. At its most basic, a guild is a
collection of designers and developers who meet regularly (e.g. once a
month, or once per quarter) to discuss ways to improve and evolve the
design system. Ideally a guild would be comprised from multiple teams
working across different product lines, so that every area of the product
team can provide input.

Sample pilot timeline by InVision design specialist Drew Bridewell: https://bit.ly/2L4eRWs

40
 Creating your UI library

Building out your UI library is both the most important part of building a
design system, as well as the easiest.

It’s important because it represents your “map of the universe”–the

codification of your product’s visual language into one master file. And
because the components of your UI library will be re-used indefinitely,
it’s critical that your design systems team gives considerable thought
to the quality and versatility of these components.

On the other hand, it’s the easiest part of building a design system
because this is what product teams do every day–design and code.
As such, it’s the most familiar aspect of building a design system,
and is the one area where both designers and developers are
already predispositioned to success.

That said, there are a few ideas and best practices that will ensure
your team stays on the right track during this stage.

“ The easiest part of building a design system is sitting

down and designing that UI library. You can do it all by
yourself, or with a couple designers, it doesn’t really
matter. It’s where you start to get other people involved
that it gets complicated.

A A R R O N WA LT E R , V P O F E D U C AT I O N AT I N V I S I O N

41
 “
Like any product, your design system won’t be
perfect on the first pass. Save time during design
reviews and team retrospectives to discuss any
limitations with the system and talk about ways
to push it forward. Don’t just build out your initial
system and then consider it ‘done’; let it evolve
with your product! Refactor it, expand it, and even
remove definition where it makes sense. The more
attention you give your design system, the better it
will reflect the existing state of your product, and
the stronger tool it will be for your product teams.

E M I LY C A M P B E L L , D E S I G N S P E C I A L I ST AT I N V I S I O N

42
Think function, not style: When creating visual assets, focus
on how they will be used, rather than the style. For example,
instead of creating Blue Button and Light Blue Button, think
Active Button and Inactive Button.

“Avoid the attributes and focus on the action,” says Aarron

Walter, VP of education at InVision. “When we created our
design system at Mailchimp, we’d name things P1 and P2–
first priority, and second priority. What is the styling for P1?
Well, it could totally change. The brand changes, the trends
in design change. Anything could influence the look of that
button, but functions remain constant.”

Practical first, principles second: It’s a good idea to think

about the principles of your design system, but focus first on
the practical components that will make your design system
immediately useful. For your first release, make sure you
have accounted for the essential ingredients–buttons,
forms, navigation, menus, cards, and others.

Once you’ve managed to build all this out, and are using the
design system in the field, then you can focus on defining what
the principles of your design system are for the next iteration.

43
 Pilot projects: One way to make your design system
immediately useful is to build it in the context of a pilot project.
A pilot project enables you to put your design system to good
use, without having to worry about the stakes of redesigning
your whole product line. Once you’ve managed to successfully
use your design system on a few discrete areas of the product,
then you can think about a larger-scale redesign using the
contents of your new UI library.

Litmus tests: A good exercise for determining whether your UI

library is robust enough to constitute V1 of your design system
is to perform a litmus test. Identify 5-10 areas of your product
as they exist today, and take screenshots. Once you can
recreate these designs using your design library, you will
know that it’s good enough for an initial release.

Mobile vs. Desktop: One question that comes up often

is where to start–mobile, desktop, or both? The truth is that
a design library will vary greatly from one platform to the next,
and even within mobile your iOS design might look significantly
different from your Android design. The good news is that
you don’t have to do everything for V1. When starting a design
system, focus on the platform where the majority of customer
interactions take place. For instance, an enterprise SaaS
product likely will prioritize desktop, whereas a social app will
focus on the mobile experience. Once your first design system
is created, you can then focus on building additional libraries
for your other platforms. The need for different libraries is
one of the reasons DSM supports unlimited libraries,
and duplicating libraries.

44
Using InVision to stress-test your design system

InVision connects the entire product design workflow, from ideation

to developer handoff. That makes it an ideal platform to “stress” test
your design system with, to ensure that it holds up at every stage
of the product design process.

What follows is a quick rundown of a 4-part test that you can use
to see how your design system works in the field.

1. Ideate with Freehand: Start by coming up with an idea for a product,

then wireframe a user flow for that product using InVision Freehand.
2. Design with DSM: Load your UI library into DSM and then start to
assemble your design using the contents of your newly created DSM
library. Try to make the design as close to the wireframe as possible.
3. Prototype: Once you’ve created your screens using your design
system, link them together into an InVision prototype, using either the
web portal or Craft plugin. This will allow you to see how your design
system holds up with interactivity thrown into the mix.
4. Handoff to developers with Inspect: Now that your designs have been
prototyped, it’s time to for the developer handoff. Launch Inspect and
see how well your design system translates for developers. Are you
able to easily access the various components of your design system?

By testing your design system in the context of a connected

workflow, you will be able to better identify any areas for improvement.
And you’ll be confident your design system works for every stage of
the design process.

45
 PA R T I I I

Getting started with DSM

Congratulations–you’ve assembled a team, built out your master

UI library, and now are ready to bring it into DSM. Getting to this point
required a lot of hard work. The good news is that getting that design
library into DSM is simple, fast, and intuitive. This section of the book
will tell you everything you need to know about how to use DSM for
managing your design system.

Why do I need DSM?

By now you probably have a master Sketch file which includes all
the visual assets of your UI library. A natural question that arises is,
”If I already have a UI library in Sketch, why do I need DSM?”

But the fact is that a file is not a system. A proper system needs
to address questions around version control, user permissions,
change management, and other complexities of a true system.

A good analogy to consider is how businesses manage their CRMs.

Technically, the raw data of a CRM can exist in an Excel spreadsheet.
But try to manage a single Excel spreadsheet across an entire
organization, and you’ll quickly see how this becomes impractical.

46
The same holds true for a design system. Trying to use a Sketch
file as a design system will create immediate problems that quickly
degrade its reliability. How do you ensure designers are using the
latest version? What happens if I try to save a change to a file while
someone else has it open? How do we control who has edit
access? When these questions aren’t answered, a design system
inevitably will fail.

Therefore, the better question to ask is how do you turn your

design library into a design system? The answer to that question
is Design System Manager by InVision.

DSM is the platform layer that sits on top of your design library,
enabling you to manage, share, and utilize it to the fullest extent,
across your entire organization. Its features include versioning,
library-level permissions, advanced security, an auto-generated
microsite, and a developer API.

DSM enables you to take the hard work that went into building
your visual language as a design library, and transform that work
into a true system.

47
How to access DSM

For InVision Enterprise accounts: sign into your account and then use
the following URL, replacing your-domain with your InVision enterprise
subdomain: https://your-domain.invisionapp.com/dsm.

Once you’re signed in, follow these steps to get started:

1. Follow the prompts to create an organization and a library.

Note: Please be careful when first creating your organization name,
as it can’t be edited/deleted and recreated at this time.
2. Follow the prompts to download the Craft Manager plugin for Sketch.
Note: If you’re using Craft Manager, make sure to uninstall and
reinstall so you’re on the latest version.
3. Open Sketch and enter cmd+L to open Design System Manager.

If you’re using DSM during its early access phase, please follow these
instructions instead: https://bit.ly/2zazEky

Cmnd+L is your friend

Accessing DSM inside Sketch couldn’t be easier. Simply hit CMD+L to

pop open the window inside Sketch, or navigate to the “Plugins” menu
in the Sketch navigation bar and click “Design System Manager.”

48
Creating and using your design library

Using DSM; TLDR version

We know you’re busy. And DSM is pretty intuitive to use.

So here’s a TLDR of what’s covered in this chapter.

1. Importing to DSM: Inside your Sketch file, select whatever you want
to import (e.g. component, icon, color, font) then hit the + icon inside
your DSM Sketch plugin.

2. Using components and icons: To use a component or icon in your

design library, simply drag it from inside your DSM sketch plugin onto
your artboard.

3. Applying colors, fonts, and layer styles: You can’t drag-and-drop

colors, fonts, or layer styles from DSM. Instead, you apply them to
design assets. To do this, just select the asset you want to change,
then switch to the DSM plugin and click on the color, layer style,
or font you want applied.

Voila!

49
Importing components: To important components into DSM, simply
select the assets you want to add. You can select individual assets,
or click and drag to select multiple assets at once.

Once you’ve selected the assets you’d like to add, switch to your DSM
plugin, select “Components” on the left menu, and then click the + icon
inside your DSM plugin window (bottom right corner).

You will be prompted to enter a category name. This is because hitting

the + icon while your top-level components menu is selected will prompt
you to create a new sub-category. If you’d like to add assets to an
existing sub-category, simply select the assets and then select the
sub-category before clicking the + icon.

Repeat this step for all the different components in your design library.

Note: If you can’t see the + icon inside your DSM plugin, make sure
you are working from the Shared Draft. To change to Shared Draft,
click on the name of your design library in the top left corner of your
DSM window inside Sketch. Hover over your library name, then navigate
to “Switch Version.”

50
 Component Categories: Good practice is to create a subcategory for all
the relevant component types, such as “Buttons,” “Forms,” “Badges,”
“Tables,” etc.

Remember that adding components while the top-level “Components”

category is selected will prompt you to create a new category. To add to
an existing subcategory without creating a new one, simply select the
subcategory you wish to add components to.

Nested symbols and overrides: DSM syncs nested symbols and

overrides with the components. When you upload a component,
DSM automatically upload its entire dependency tree with it. This way,
you don’t have to hunt for dependencies and upload them individually.

Similarly, when you pull a component into a new document, DSM brings
its entire dependency tree with it. This means you can start choosing
among possible overrides as you design with the component, and don’t
have to worry about pulling each dependency independently for the
component to render.

When an updated symbol syncs to the document, the previous overrides

are kept in place, so you can apply a visual refresh while maintaining the
component state.

51
Importing colors and layer styles: To add a color to your design library,
you’ll first need to make sure to select the layer containing the color
within Sketch, otherwise you’ll be prompted to add a global color.
The target group must also be selected before clicking the + button on
the bottom right of your DSM plugin. Color names, as all other element
types, can have the same name.

Note: When you import components, it will automatically bring in any

colors, fonts and layer styles associated with that component.

Updating colors, icons, and components: Colors can be updated in

DSM if the color is added as a layer style. You can use layer styles for
updating colors across a project.

In order to update an element, make the changes, then find the element
in the DSM library and press the + button in the bottom right corner.
You will then be presented with the option of updating the element or
creating a new one. Updating the element replaces the existing
element definition.

Once updated, you can quickly update all instances of your symbols
across your artboards by selecting the download icon from the DSM
plugin window. For non-symbol elements, you’ll be able to drag and
drop them from your DSM library to your file to make changes.

Removing/deleting items: To delete an item from DSM, go to your

DSM plugin modal, right click the item, then click Delete.

52
An example process of where DSM fits into the
designer’s workflow by design specialist Drew
Bridewell:

1. Designer receives a project or problem: Designer creates and

documents work inside of InVisionapp.com. Iterates on the solution
then evaluate’s the design and realizes there’s an opportunity to make
a component. The designer then designs all versions, states, and
aspect ratios for the new component, documents them, while getting
engineering and product alignment. The designer also validates that
the work meets the team’s needs and solves the user’s problems.

2. Engineering, Product, Design collaboration: The team utilizes InVision

Cloud to validate the work. Engineering uses Inspect as a resource
to build out the component experience. Since Engineering, Product,
and Design had partnered up front, the work was prioritized to be
implemented as a new component. All teams can utilize moving
forward.

3. Build it. Ship it. Add it: Engineering delivered on the sprint and the
component has made it into the code base. During implementation,
the lead designer who was working on the design adds the
component to the shared draft inside of DSM.

4. Awareness, usage, and governance: After the component was added

into DSM, the lead designer wants to inform the rest of the teams by
releasing a new version to the Design System. Included in this update
was a Slack notification with a link to the component page along with
rich descriptions of how to use the new component. All designers can
now leverage this new component by switching to the latest library
version and pulling down the library.

53
Version control

One of the most common reasons design systems fail is the lack
of proper version control. The good news for you is that DSM comes
equipped with one of the most powerful versioning features of any
design tool ever built.

Creating a new version: When you’re ready to release a new version of

your library to your team, you’ll do that from within the Sketch plugin.

1. Go to your DSM plugin modal.

2. Click the drop down menu, then hover over your library name.

3. Click Release New Version.

4. Enter the version name and a description of the changes from

the last version.

5. Click Create Version.

6. A new library version is propagated to all team members.

7. The See What’s New link opens a browser showing the changes
as updated in the version description.

When you release a new version, team members currently working with
the design library will see an alert notifying them that the library has been
updated to a new version. The updated assets and styles are available
to use immediately. No manual opt-in or download is required.

54
Switching between versions: To switch between versions.

1. Go to your DSM plugin modal.

2. Click the drop down menu, then hover over your library name.

3. Hover over Switch Version.

4. Select the version you’d like to switch to.

Viewing version history: To see a version history along with their details.

1. Go to your DSM plugin modal.

2. Click the drop down menu, then hover over your library name.

3. Click Version History.

The web view will open and you can use the ••• menus to view any
version or compare a version to the latest version.

You’ll see a list of the assets that were added, removed, and changed.
To see a side-by-side comparison of a changed item, click More Details
on an item that changed. Click Highlight Changes to see highlights of
the differences between the two images.

55
Shared drafts vs. versions: When using a design library in DSM, you
have the option to switch to a release version of your design library,
or work from a Shared Draft.

The Shared Draft is the only way to make changes inside your design
library (e.g. adding or removing components). Think of it as the staging
area for a design system-in-progress. This allows you to iterate and make
changes, without having to worry about breaking things, since you can
always revert back to an official release version of the design system.
This concept is almost identical to the “nightly build” idea that’s so
commonplace in software development.

Version naming conventions: DSM lets you name your versions any
way you like, but it might be a good idea to adhere to some best
practices around naming releases.

One of the most common standards for naming releases used by

software developers is the 1.0.0 model. According to this convention,
the first number represents major changes, the middle number
represents minor changes, and the last number represents fixes.

1.4.3
Major updates: Minor updates: Fixes:
This includes large- Small changes to your Simple corrections
scale changes to your design system, such as of mistakes, errors,
design system. updating a few buttons bugs, etc.
or colors.

56
 Writing release notes: Release notes are crucial in design systems.
They help your team understand what is different from one version
of the library to the next.

How release notes can help in DSM:

 • Inform users of new or updated components

 • Setting expectations by sharing library progress
 • Educate people about the library and its purpose

Pro tip: Keep the language of the release notes consistent and
informative. Remember that you’re creating a design language
and even the release notes should support this goal.

Example of a bad release note:

 • Updated colors
 • Button improvements

This doesn’t give enough detail about the release and might cause
your team to wonder what has specifically changed and why.

To create your release notes, keep a list of everything that you’ll add
to your release. Then break that list into things that have been
New and things that are Updated.

57
 Pro tip: Prioritize your list. The most requested or most
important addition to the release should be at the top.

Example of a good release note:

New:

 • New grid system alert! Soon we’ll be switching from 12 columns to

8 columns for desktop viewport. To prepare for this, an additional
artboard with the 8 column layout has been added to the library.
Your product owner’s have been informed of this change. Please test
and provide feedback or issues to [email protected].
 • Search overlay for desktop viewport is now available. This is a new
product feature. Both states included.
 • Additional notification banners have been added for mobile viewports.
Notification states included are error, success and warning.

Updated:

 • Primary text link colour is now AA compliment. Hooray!

NB: This is a big deal. Accessibility is everyone’s responsibility.
 • Fixed secondary button and is now displaying the correct
corner radius value.

58
 Pro tip: Use markdown to call out important statements
in your release notes.

This gives a good idea of what is going into the release and what your
team should watch out for. Importantly, it gives a good understanding
of why something has been included in the release.

59
 Brief guide to design tokens

“ Design tokens are the visual design atoms of the design

system — specifically, they are named entities that store
visual design attributes. We use them in place of
hard-coded values (such as hex values for color or pixel
values for spacing) in order to maintain a scalable and
consistent visual system for UI development.

SALESFORCE

Design tokens are one of the most exciting developments for the
future of product design. They hold the potential to bridge the gap
between design and development, so that a change to a design
element could be pulled by the developer to change the code
associated with that element.

While design tokens haven’t reached their full potential yet,

their implementation inside DSM represent an important first step
towards making this dream become a reality.

60
What are design tokens?

Perhaps the most concise definition of a design token comes from the
website bits.24ways.org, which writes:

Design tokens are named entities that store visual design

information. These are used in place of hard-coded values
(such as hex values for color or pixels for spacing) in order
to maintain a scalable, consistent system for UI development.

While this may seem a simple concept on the surface, in practice

it makes a profound difference in speed and efficiency. If we can
associate a piece of “visual design information” with a name, then this
allows us to change the design information, and then have that change
propagate into the codebase wherever that name is found.

61
A practical example of design tokens

Let’s look at an example of how design tokens could be used today

inside DSM.

Imagine your brand uses a yellow with the hex value FFFF00. Because
this is your standard brand-yellow, your development team then inserts
this hex value into their code in dozens or hundreds of places across
your product line. Now, if you ever wanted to change the hex value for
that yellow, your developers would have to track down every place
that value appears and update it manually.

But by using design tokens with DSM, you can associate that hex
value with a name, such as “Warning Yellow.” The developer can then
reference “Warning Yellow” in their code, rather than the hex value
itself. Then, if you ever were to change the hex value of “Warning
Yellow” inside DSM, the developer can choose to pull that change
and have it automatically update the look of “Warning Yellow”
everywhere it appears in their code.

62
 “
A design token is an abstraction so you don’t
have to refer to specifics. It gives you the flexibility
to change values and things down the road, and
not have to go re-communicate to everyone,
‘Hey, don’t use that red anymore.’ You just refer
to some high level idea and things can change
behind the scenes.

A A R R O N WA LT E R , V P O F E D U C AT I O N AT I N V I S I O N

63
The Web Monument Site

DSM features a web portal that automatically updates to reflect the

contents of the latest version of your design system. It is a critical feature
that allows you to invite anyone in your organization to experience
your design system, and is especially valuable to engineers, marketers,
product managers, and executives.

The key to awareness

According to Aarron Walter, InVision’s VP of education, the hardest

part of building a design system is actually what happens after the
design system is built.

“The awareness campaign is probably the hardest part of a design

system,” says Walter. “The easiest part is sitting down and designing
a view of the universe. You can do it all by yourself or with a couple
designers, but it’s where you start to get other people involved that
it gets complicated. So the monument site is not just a nice to have,
it’s essential because people need to see what this thing looks like.
They need to see the opportunity.”

By capturing your design system in an easily accessible website, it

allows you to share your company’s visual language across the entire
organization. Whether a social media designer in marketing needs
to grab a brand-approved color, or a developer needs to download
a specific icon, the monument site makes this possible.

But it also helps demonstrate the value of your design systems efforts
to executives in a way that a Sketch file or a Dropbox folder never can.

64
 1 2
3

1. Download plugin

2. Design tokens developer API

3. Manage permissions

4. Change version

5. Navigation

65
Manage versions: The web portal enables you to manage versions,
including comparing different versions to see what’s changed,
as well as roll back your design system to a previous version.

Manager users and permissions: Advanced roles and permissions let

you fine-tune who has access to what. This includes deciding read
vs. write access, as well as setting library-level access permissions.

Integrate with developer API: The developer API integration is

accessible through the monument site, and supports a wide variety
of formats including CSS, Sass, Less, Stylus, JSON, Android and iOS.

Create libraries: DSM supports unlimited libraries, so you can scale

design systems no matter how big your organization. Creating libraries
happens within the web portal.

66
Benchmarking design systems by design specialist
Drew Bridewell:

Small Medium Large

1-3 weeks 1-3 months 8-12 months

Measure + Learn + Iterate

 • Total/average time from first team meeting kick off to a solved

problem and product usage.
 • Total/average time from first team meeting kick off to design
engineering handoff.
 • Total/average time from first team meeting kickoff to 1st
approved design.
 • Quality and satisfaction for customers via NPS, Social Media,
or Surveys.
 • Quality and satisfaction of engineering staff with design collaboration.
 • Quality and satisfaction of product staff with design collaboration.
 • Current usage of InVision across the product (total projects,
collaborators, reviewers, executives inside the tool).
 • Benchmark with CSS stats the total amount of inconsistencies
across product lines.
 • Total/average time from engineering to product launch.
 • Total/average number of components used by engineering.
 • Design can successfully manage and update a version of the library.
 • Horizontal teams in the organization have found value form having
a source of truth for the pattern library.

67
Conclusion

The emergence of design systems is a historic moment in the evolution

of product design. They are a necessary response to intensifying
challenges around building products in our post-digital world.

They also represent a fundamental shift in the way we design digital

experiences—a shift away from a process that has traditionally been
bespoke, imprecise, and unpredictable to one that is faster, smarter,
and more rigorous. In other words, a process that holds up at scale.

But changes in technology always require changes in human behavior

to succeed, a point stressed by Marco Suarez, one of the creators of
the Etsy design system, who now works on design systems at InVision.

“Design systems attempt to fix a human problem, which it can do to

a point, but it will inevitably fail if you don’t have a good trust with the
people you work with,” says Suarez.

68
According to Suarez, this trust is especially important considering the
transformative potential of design systems—not just for our products,
but for the role of designers as well. Design systems hint at a future
where designers spend less time micromanaging the visual design
of things like buttons and form fields, and instead spend more time
thinking strategically about digital products holistically in the context
of a “user experience.”

This should excite designers greatly, because it elevates designers to

the very heart of business success, and it represents a new opportunity
for designers to become leaders. Ans s the world becomes increasingly
design-driven, it will be the designers who drive that change who will
benefit the most.

69
PA R T I V

Appendix

InVision—your partner in driving change.

InVision is more than just a platform. We’re your partner in elevating your
organization’s people and practices too, which is why we invest heavily
in education for our users and the design community at large.

Our world-class education team is led by Aarron Walter, who previously

served as the head of design at Mailchimp, and who is the author of
the book Designing for Emotion–a staple of design school classrooms
everywhere. Through our education portal DesignBetter.Co, InVision
has published several books on product design, and partnered with
prominent thought leaders in the design space to create workshops
that have been attended by thousands of professionals around the
globe. Some of the instructors we’ve worked with include Brad Frost,
the creator of atomic design theory; and Jake Knapp, author of the
NY Times-bestselling book Design Sprints.

70
For more hands-on development, InVision’s customer success team
offers experienced design specialists to help train your team on
cutting-edge best practices, and ensure you’re leveraging the InVision
platform fully. And dedicated customer success managers provide
ongoing guidance on a regular basis.

But those are just a few of the ways InVision can help your team.
With a broad catalogue of events, film screenings, webinars, trainings,
and onsites, InVision offers educational programs for any team,
no matter where they are in their design maturity.

Some of the teams we’ve helped educate over the years include
Google, Netflix, Capital One, Intuit, Nike and others. Now let’s work
together to find out which programs are right for your team.

71
 Design Leadership Forum

This forum is for the best in design leadership to learn from each other
and share solutions to common problems. It’s to advance the practice
of design leadership. It’s to elevate design in business. Members of the
Design Leadership Forum convene at events like dinners and retreats in
major cities around the world. These gatherings are for design leaders
to have honest conversations about their biggest challenges and get
the perspectives of peers who have been through similar experiences.
Find out more at invisionapp.com/design-leadership-forum.

“ Face-to-face conversations are the best resources for

growing as a design leader. The connections I’ve made here
are real, the advice and anecdotes are fresh and relevant,
and it’s been equally rewarding to offer some help in return.

F R A N K YO O , H E A D O F P R O D U CT D E S I G N AT LY F T

72
 Workshops

As part of our mission to elevate the practice of product design, we offer

workshops in partnership with notable thought-leaders in the design
space. These workshops cover a variety of topics, from building a design
system, to leveraging design thinking in product design, and provide the
foundation needed to create great products faster. Past instructors have
included Jake Knapp, Brad Frost, Dave Malouf, and more. Find out more
at http://designbetter.co/workshops.

“ The design thinking workshop with InVision leveraged our

entire team, providing a framework for rapid problem solving
that called on the creativity of each team member. The time
we invested with InVision reinforced the power of design in
making great customer experiences.

JAS O N H A R V E Y, C R AT E & B A R R E L

73
DesignBetter.co

Introducing the best practices, stories, and insights from the world’s
top design leaders. Loaded with in-depth books, podcasts, and more,
DesignBetter.Co is your essential guide to building remarkable products
and teams. Some of the books include The Design Systems Handbook,
Design Thinking Handbook, and The Principles of Product Design.
To view all this and more visit http://designbetter.co.

Design Disruptors

This feature-length documentary film by InVision explores how

age-old, billion-dollar industries have been disrupted by a new breed
of design-driven companies. The film has been screened at hundreds
of companies, and to tens of thousands of design professionals.
To host a screening of Design Disruptors with your team, please visit
designdisruptors.com or contact your InVision representatives.
Executive cuts are also available.

The Loop

A documentary about IBM’s inspirational journey to adopt design thinking

and transform business outcomes throughout the company. To arrange
a screening with your team, visit: https://www.invisionapp.com/
enterprise/ibm-design-thinking.

74
Webinars

Discover insights from top minds in design with DesignTalks from

InVision. These webinars cover a broad range of topics related
to product design, from building a design system to bridging the
gap between design and development. To find more webinars,
visit http://invisionapp.com/webinars.

Design Specialists

InVision employs experienced design leaders to work with customers

to ensure that they’re getting the most out of InVision by leveraging
a modern design process across their organization.

Their primarly goal and responsibility is to help empower you and

your team to get the most out of the InVision platform, its tools,
and to share tips, tricks, and best practices along the way.

These design specialists are also available to help coach and guide
you on your journey towards achieving a high-value design system.
To schedule a design specialist consultation, please contact your
InVision representative.

75
Field Notes

Contents

Introduction to design systems 8

How to use this guide 8

New trends and challenges 10
Benefits of design systems 14

Getting started with

design systems 18

Running a design audit 18

Performing the audit 22
Getting buy-in 26
Team models for building a design system 30
Creating your UI library 35

Getting started with DSM 40

Why do I need DSM? 40

How to access DSM 42
Creating and using your design library 43
Version control 48
Brief guide to design tokens 54
The Web Monument Site 58

76
Conclusion 62

Appendix 64

InVision—your partner in driving change. 64

Design Leadership Forum 66
Workshops 67
DesignBetter.co 68
Design Disruptors 68
The Loop 68
Webinars 69
Design Specialists 69

Field Notes 70

77
 Settings

Profile

Location

Notifcations

Social

LOG OUT
SYNCING

SYNCED

.button {
color: #ffffff;
border-radius: 20px;
background: #76baf8, #ac6bfe
font-family: maison neue;

font-size: 12px;
font-weight: medium;
letter spacing: 1px;
text-align: center;

height: 50px;
width: 200px;