A Maturity Model for Design Systems

Marcelo Somers
Nov 9, 2015 · 5 min read

When I attended CSS Dev Conference last month, I spoke with dozens of designers and developers advocating for Design Systems and Pattern Libraries within their organizations. It’s a given at this point that you should have one. The question is, how do we go from where we are today to where we should be?

A useful model for framing up this discussion is a design system maturity model that John Gully and I put together:

Image for post
Image for post

Inconsistent

The absence of any design system. This organization hasn’t even tried to unify under a single UI paradigm. This sounds crazy, but too many companies live here.

Obviously no one wants this.

One-Time/Static

This is the standard agency model where you hire an agency to do your branding. They deliver a gorgeous PDF and every app you build tries to adhere to this guide. It’s pretty much dead on arrival because the system doesn’t evolve to fit the needs of growing organizations.

Manual

This is the first level that attempts to reflect the reality of the sites or applications you are building. Maybe you’re using a tool like KSS or Pattern Lab to capture the live examples and code snippets for developers to use. These pattern libraries reflect the reality of HTML/CSS and get out of static PDF documents.

“Unless it’s part of your build, your style guide is just more documentation to maintain” –Phil Hawksworth

Automatic

This is the holy grail of design systems — the moment when your documentation has no choice but to remain in sync with your production site. There are several requirements to achieve a truly automatic design system:

  • UI code must be shared between the pattern library and production applications (CSS and possibly front-end templates)
  • UI code must be downloaded from a remote location as a part of your application’s build process
  • UI code must be versioned so various applications can be tied down to the design system at different states
  • The UI Code’s live examples in the documentation must be automatically updated with any changes

An approach to get an automatic style guide is to build your styles and import them using a package manager like NPM or Bower. We built PatternPack with this ideal in mind — to make it as easy as possible to spin up a Pattern Library that is documented, versioned, and distributed through a package manager.

Achieving an automatic pattern library is much more than a technology problem. It requires organizational consideration to think through how to govern your pattern library. When multiple applications are pulling from the same codebase, making a change is much more complicated than “just update the CSS file.” Someone has to think through the implications in multiple projects.

At Slalom Dallas, this is the baseline level we strive to get our clients to. Anything less, and we have seen the Pattern Libraries fizzle out as soon as we leave.

The Team

Some companies take things a step further. Salesforce has spun up an entire team devoted to maintaining their Lightning Design System. Not every company has to do this, it all depends on the specific situation you are in.

Nathan Curtis wrote a fantastic article about Team Models for Scaling a Design System that is worth evaluating before your team runs off and hires designers and developers to maintain your pattern library.

The ideal that Nathan recommends is a federated model that brings product designers from various teams together to construct a meaningful and relevant design system:

Such a committee federates a system’s design direction to a representative, empowered subset of designers and leaders designated to collaborate on the system for a period of time.

They make design decisions collectively, even if only a subset — or others — record, build upon and communicate those decisions through artifacts like a living style guide.

In this situation, the team is not a group of people hired specifically to do this job, but a committee that works together for the better of the company and design system.

Moving Up The Maturity Model

Maybe you want to build a design system? Maybe you have a Zombie Pattern Library?

You’ll be glad to know that in our work, more often than not, we’re extracting a design system from a client’s existing application(s). Here’s how we approach it:

  1. Take an inventory of your application ecosystem — look carefully at the baseline styles (fonts, colors, icons, etc.), components, and page templates, and taking careful note of what’s meaningful to your design system, and what you’re ready to move away from.
  2. Standardize your inventory — the bigger your app ecosystem, the more likely you have variations across pages and even various apps. Bring designers and developers together to make up their minds for where they want to go. Standardize your spacing units, plugins, etc.
  3. Document your design system — good documentation makes your design system accessible to developers. Investing time in documenting how to use it is important. For inspiration, check out this list of Pattern Libraries.
  4. Define your CSS Standards & Refactor to get there — Most CSS is terrible. Define where you want to go and work slowly to get there. Rebuild a table or modal, and then re-implement it across all your applications

Moving up the maturity model takes time, but even going from one step to the next can yield huge returns for your product and design team. In the end, a mature design system accelerates design, prototyping, and development and decreases the time you spend fighting your code.

If you are interested in building a pattern library that follows these conventions, we’ve created an open source tool called PatternPack that makes it easy to build your pattern library, version it, and distribute the code to other applications via npm or bower. Check out the Guides & Resources to get started.

Slalom Build

The Build Blog is a collection of perspectives and…

Thanks to Jina Anne

Marcelo Somers

Written by

Experience Strategy + Design at Slalom

Slalom Build

The Build Blog is a collection of perspectives and viewpoints on the craft of building digital products today, written by the technologists that build them. By builders, for builders.

Marcelo Somers

Written by

Experience Strategy + Design at Slalom

Slalom Build

The Build Blog is a collection of perspectives and viewpoints on the craft of building digital products today, written by the technologists that build them. By builders, for builders.

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