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:

Inconsistent

Obviously no one wants this.

One-Time/Static

Manual

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

The problem is that your Pattern Library is just documentation at this point. It’s not in sync with your production site, and requires you to come back and remember to make updates as they happen. Things can get messy and out of date quickly, even in companies with the best intentions

Automatic

  • 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

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

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…

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.