Defining Design Systems

Getting to the Root of What Your System Really Is

Nathan Curtis
Oct 10, 2017 · 7 min read

Defining design systems seems a daunting challenge. It’s not as if our community hasn’t made many, many, many, many, many, many, many, many, many, many, many, many, many attempts. Recently, Sarah Federman wrote about distilling it into its essence and warns us to avoid getting trapped defining things and being dogmatic about what it is and isn’t.

Design systems is a growing field formed by vibrant, collaborative voices. It is important to posit what a system is and how it fits, or we risk undermining its value due to incoherent understanding. We shouldn’t suffer challenges, and there’s common ground to gain. My livelihood depends on it, selling ~15–25 design systems engagements a year to clients understanding the outcomes and outputs (hint: not just UI kits, code, and doc) and why they matter.

“What is a Design System?”

If I have ~30 seconds in an elevator or over animated slides, I’ll lead with:

If only 10 seconds, I’ll say:

If only a tweet, well then there’s this:

Formally, a system is a set of interconnected parts forming a unified whole. In the case of design systems, this definition actually alludes to not one but three interrelated systems you’ll need to solve for to be successful:

  1. a kit of reusable, interconnected parts,
  2. a set of cohesive, interconnected products, and
  3. a community of collaborative, interconnected people.

#1. A Kit of Reusable, Interconnected Parts

To its primary customers, the system is a set of tangible outputs that they encounter on a day-to-day basis. I’ll start plainly with:

Almost always, a design system offers a library of visual style and components documented and released as reusable code for developers and/or tool(s) for designers.

These days, a system of parts connects a codifed visual style (e.g., color, space, typography) to composible UI components (buttons, forms, headings, so much more) used to design and build interfaces.

This starting point packs a punch of intention, revealing beliefs: A system serves developers and designers, in that order. A system must be well-documented. A system must offer style and UI components. Yet every system is different, so I’ll expand a system’s scope to include:

A system may also offer guidance on accessibility, page layout, and editorial and less often branding, data viz, UX patterns, and other tools.

This variability fosters useful conversations that draw boundaries around what an organization wants and needs. Some concerns (always style and components) are realized far more often than others (editorial guidance and data visualization).

#2. A Set of Cohesive, Interconnected Products

Words like “offer” and “released” are intentional, casting the design system as a product satisfying the needs of customers (chiefly, developers and designers making products of their own) through tangible outputs they use.

Invoking product concepts trigger a cascade of concepts useful for those familiar with product management applicable to a system too: roadmap, backlog, releases, program increments, sprints, dependencies. However, to focus only on development of parts risks missing what makes systems work. Especially, the system’s customers!

A design system is adopted by and supported for other teams making experiences. These teams use it to develop and ship features more efficiently to form a more cohesive customer journey.

Design systems invest in marketing to product teams to consume the kit of parts to form a unified and cohesively holistic experience. Fostering adoption requires clear messaging to sell others to adopt system and improving themselves (individually and collectively) by realizing its benefits over time as a dependency.

Product management also evokes how design systems fit in product operations, such as DevOps delivery (“How do we release it? How is it automated?”), integration (“How do we version? What’s a breaking change? How, how frequently, and when do we upgrade?”), and infrastructure (“Where’s our repo? Where’s our doc hosted? Is it public?”).

Easy to miss in the definition above is supported for, framing the support and service of the customer. Effective documentation is essential. Beyond that, there must be paths to and time for providing help, responding to requests, patching defects, and consulting, all in an environment that’s open and responsive.

To cast a design system (and the effort needed to make it work well) as just developed style, components, and assets — to the exclusion of the marketing, service, integration and operations that success depends on— is too narrow.

#3. A Community of Interconnected Collaborators

To help stakeholders understand the impacts of a system, I also route conversation through the people and activities required to operate a system.

A design system is made by an individual, team, and/or community. While some arise less formally, organizations now dedicate small to large squad(s) to develop and release system versions and processes over time.

Characterizing a system team as a product squad sets the choice in terms familiar to product and marketing professionals: is this important enough to put a team behind it? That team can adopt rituals, showcase work, and evolve a roadmap to become part of the fabric of how enterprises make products.

In cases I’ve observed, this team is responsible for the workflows, connections, and community engagement across an enterprise to decide how a system is applied and evolved. Historically referred to as “governance,” I’ll avoid that term to favor a tone of collaboration over control.

From the outside, a designer, engineer, or someone else in a community may not sense the level of execution behind such activities. That doesn’t mean that they aren’t developed, operated, supported, and used deliberately for months or years. This execution of community interactions is an effortful yet intangible product that make a system successful.

Composing a High-Level System Definition

While not my intent, this writing returned me to the framework of a Parts, Products, and People workshop I’ve run for years. This activity steps participants through a prescribed protocol to detail what parts their system needs, what products it’ll apply to, and who does the work.

Parts, Products & People Worksheet Activity

However, it’s reasonable to precede or replace this meticulous activity with a leaner, fill-in-the-blanks template to ground understanding:

Over years of contributing to design systems, this statement would yield similar yet always unique answers. A system I’m working on now would fill these blanks as:

A system I am starting now exhibits a different composition that necessitates a different approach to how it’s made & consumed:

What flummoxes our community is the variability of systems composition. The consistent objective — adopting products producing a cohesive experience more efficiently — is reached through many potential means by involving different kinds of groups with varying areas of focus.

There’s no de-facto formula, no winning methodology (but we’re getting better). Instead, system success requires adapting how you define it to conditions and constraints of the enterprise it serves.

About to embark on a design system, or need to dive deeper to discuss products and players? EightShapes conducts systems planning workshops and coaches clients on design systems. Let’s talk!


A collection of stories, studies, and deep thinking from…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store