Encouraging Play in Design Systems

As more and more design systems, pattern libraries and style guides debut, some common traits emerge. There’s usually an introduction, maybe some information about the guiding principles or brand assets and color palette. Front-end components are documented in detail, with nicely highlighted code samples. Sometimes a collection of templates will show how the whole thing comes together.

Something I rarely see: A place for contributors to experiment, make mistakes or stumble across brand-new solutions. If tomorrow someone wanted to try out a radical new idea within the system, where would that happen? Would it be visible to their colleagues?

Any system without clear answers to those questions runs the risk of stagnating once version 1.0 is out the door.

The larger a project grows, the harder it becomes to keep track of all its component parts. Without clear documentation and standards, a team member might create a redundant interface element accidentally, or because it wasn’t clear how to make the existing element meet their needs. As these Bizarro patterns accumulate, performance dips and the user experience grows inconsistent and fragmented.

But in the same way that our well-meaning immune systems may overreact to harmless histamines during allergy season, a design system without a clear and approachable strategy for free-form, collaborative contributions can accidentally discourage innovation.

Nothing kills an idea faster than realizing you’ll have to complete a gauntlet of steps before you can even try it out.

Say your team consists of visual designers, front-end designer-developers and application developers. Chances are, each of these groups has their own preferences in terms of how they naturally express their ideas.

Design systems can be intimidating to start, and it can be tempting to go “all in” on a single framework or technology. But consider who that may exclude from the process. How many designers could you empower by generating a Sketch resource? Would your patterns appeal to more designer-developers if they worked with vanilla HTML and CSS instead of requiring knowledge of React?

Having the resources to visualize or test an idea is terrific, but it does little good if team members have to invent solutions for sharing and collaborating on their explorations.

Many pattern library tools include features for identifying “in progress” elements or features. At Cloud Four, we proposed states in Pattern Lab and added labels to Drizzle for this purpose.

But once those patterns are resolved and the system is live and in use, things can stagnate. Introducing work-in-progress stuff post-launch could confuse new adopters or introduce regressions.

Another challenge is having a clear location for experiments that won’t disrupt existing patterns. Can team members easily display static mockups or screenshots? Can they create self-contained prototypes with new styles and behavior without polluting the master?

One solution to this problem is to separate the development environment from its documentation. Brad Frost uses the aforementioned Pattern Lab for active development, which is then presented by a complimentary tool called Style Guide Guide. In this setup, the Pattern Lab could continue to act as a workshop for active development and play, while the style guide presents only what’s stable and agreed upon.

Another option is to allow for separate development versions of design system resources. At Cloud Four, we use Netlify’s deploy previews to automatically generate shareable URLs for proposed changes.

Our projects also have sandbox or prototype directories for compiling new assets without polluting the rest of the system. These can import the same modules, variables and resources as the rest of the pattern library, but are exported as their own self-contained files in a separate place.

So you’ve invested in a design system with outputs that map to your team’s skill sets. You’ve accounted for continued prototyping in your environment, and those experiments are super easy to share.

But nobody uses it. Because no one has time.

I’m a designer at heart, so I’ve focused this article on what are essentially two or three usability issues I’ve identified while interacting with design systems. But none of these ideas help if your system lacks clear ownership and continued investment. No one uses the new jungle gym if class never breaks for recess.

Treat your design system as a product. Identify its owners. Plan releases. Empower team members to be advocates for it. Schedule brainstorms, hackathons or other inclusive opportunities to improve it.

Because design systems that encourage play also encourage progress. Without progress, they’re doomed to become time capsules.