Design System Principles

The following list of principles and action items emerged while working on Thumbprint, from its kickoff in late 2017 into the mature, multi-platform design system it is today.

Design Systems is a business

You’re shipping a product to users and supporting it on many fronts with planning, communication, documentation, diplomacy, roadmaps, promotion, maintenance, adoption, and measuring value. Making all this happen requires a dedicated team with diverse skills working in unison to bring your product to customers. Design systems often flame out by failing to appreciate the complexity and full-time attention that’s needed. This ain’t a side project.

Simplify

It’s been said that “complexity is the enemy of execution” and that is certainly applicable here. Increasing options in a design system exponentially increases permutations, assets, development times, maintenance costs, and the likelihood of bugs. Start with as few options as possible, until it hurts. It’s much easier to expand them later than to remove ones already released.

Designers & developers must work in tandem

Like style guides, design systems are often mistakenly thought of as the domain of Design. But code is not a by-product. The process of creating components should be a feedback loop between designer and developer, moving as a unit, with each inspiring adjustments. This promotes a shared language, better understanding of each side’s concerns, and helps ensure teams have their tools available at the same time.

Don’t build everything at once

It’s tempting to want to clean house and redesign everything. But proceeding in deliberate phases will result in a healthier system long-term, for example, creating those early components will generate learnings to guide future decisions. It will also validate your process: the nuts and bolts of how components get made, who should be involved in that process, and how you socialize your efforts externally. Building a successful design system is a long and windy marathon, not a sprint.

Don’t build too soon

Another pitfall is the risk you’ll build components you don’t actually need. This leads to unused design and code assets and needless complexity. Be sure you have enough existing use cases before committing to build. Your goal is deliver tools that match your teams needs, not a Bootstrap-style library of components they might use in the future.

Don’t build too many options

Avoiding building too soon also applies to the components themselves. Their options and variations should map to actual use cases, not ones you think may be helpful in the future.

Ship good, not great

On the other hand, you don’t want to delay releasing components and documentation until all the evidence is in. If you want your design system to gain traction sometimes you have to make do with limited data. You simply can’t wait for perfection.

Remove friction, add friction (“Pit of Success”)

Among the goals of your system is to speed the process of building products. This means designers and developers should have quick access to the building blocks they need. It also means it should be harder to break out of the system by introducing entirely new elements or customizing existing ones. By making it “easy to do the right things and annoying (but not impossible) to do the wrong things,” we create what has been called a Pit of Success.

Avoid being cops

It’s understandable that designers and developers may initially view a design system as a threat to their autonomy. To dispel this notion, communicate regularly that a primary function of a design system is to watch for emerging trends and, where appropriate, elevate them into the system, and not there to create roadblocks.

Encourage external help

Some number of designers and developers will have an interest in contributing to the design system. Identify and recruit them as resources to help test ideas, make small updates, or even build new components. This demystifies the process and can convert them as advocates for the system.

Allow for variation

Reusing existing assets should always be the first consideration. But acknowledging the necessity of, and making space for, one-off experimentation is essential. When a developer receives a design that doesn't map to existing components they should feel empowered to first find out why. Sometimes the design diversion is unintentional, in others it’s desired. Providing a safe way to reconcile those questions unblocks teams and alerts us to consider if it should be part of the system.

Create a shared language

When building for one platform it’s relatively easy for designers and developers to talk about components using the same words. A “dropdown” as a design asset can be called a “dropdown” in a code component. But what is a “dropdown” on Android? What are the conventions for common interactions and do they change from platform to platform? Try to maintain consistency but accept that you may have to rename components down the road.

Over communicate

Because design systems are a relatively new concept it’s common for people to have misconceptions. Since you’ll be interacting with a wide variety of teams with varying degrees of design system fluency—designers, developers, writers, illustrators, project managers—you can ease their concerns by being transparent and continually sharing your work.

Don’t be too DRY

The concept of DRY in software development, which means “don’t repeat yourself,” is a long-standing principle that encourages a “single...representation within a system.” Though generally good advice, if followed blindly it can lead to unnecessary abstractions, all for the sake of avoiding duplication. Consider whether a reduction in a number of lines of code helps readability and maintenance.

Limit technical complexity

Like any significant software project, the code that houses your components and documentation will likely become complex. You’ll be doing yourself and your coworkers a favor but avoiding over-optimizing for certain use cases as they are likely to change.

Build & document as one process

A common problem with any documentation is content that’s out of date. Let’s say a developer makes a change to source code but neglects to update the wiki. Mismatches and mistakes like this can undermine trust or worse, things can break. When deciding on your technical infrastructure try to link those environments as closely as possible.

Update & migration ownership

As your design system releases new features those changes need to make their way into the products. But who is on the hook for that if the duties of the Design System team ends with publishing? Introducing large changes is scary so don’t let ownership be ambiguous. Establish a process to prevent products from getting multiple releases behind.

Resources

• Design Systems Book.
• Design Systems News email newsletter.
• Design Systems Slack channel.
• Clarify Conf A design systems community conference.