Designing in Systems

A design system is a documented library of interface tokens, components, patterns and best practices that is used to build products. Successful design systems are supported by a shared set of goals, a well defined process, and a plan to continuously improve.

Tokens

Tokens are the baseline of the user interface, they make up the visual look and feel and are crucial to maintaining consistency across even the most complex experiences.

Some examples of tokens include:

• Colors
• Typefaces
• Spacing and sizing
• Decorations: shadows, borders etc.

Components

Components are small, flexible pieces of an interface that can be combined into larger reusable parts and experience.

Some examples of components include:

• Buttons
• Form fields
• Alerts
• Headings

Patterns

Patterns are made up of several components into reusable parts, a single page may be made up of several patterns.

Some examples of patterns include:

• A login form
• A modal
• A navigation bar
• A shopping basket

Best Practices & Process

A design system is tricky to maintain and use if it doesn't have clear documentation, and a well defined process for keeping the system up to date.

This might include:

• A tool that everyone on the team can use to browse and use tokens, components, and patterns.
• A way for anyone to raise issues and offer suggestions for the design system.
• Regular reviews to determine new additions, variations and deprecations of tokens, components, and patterns.
• A quality assurance process that reviews design and code to ensure quality, and identify areas the design system can improve.

Why we design in systems

We choose to design in systems because they offer and improve consistency, collaboration, and productivity.

Consistency

We design in systems to give us the best chance of ensuring consistency in our interfaces. Consistency is an important part of what makes interfaces more usable. When people know what to expect they are often able to use your product faster, and more easily.

A mature design system should allow the whole team to create designs with less concern about consistency because they can feel confident that the design system they are using has built consistency into every output.

Collaboration

Design systems are helpful for collaboration across the entire team. For example, teams often find the handoff period between design and development to be a challenge, something a design system can help with. A design system can enable the whole team to be involved in the creation of new features from beginning to end, even team members from departments that have traditionally felt detached from the design process, such as the marketing and sales teams.

Productivity

Design systems can increase the productivity of the whole team. A design system enables designers to construct interfaces by assembling blocks into entire pages without having to start from scratch.

Well documented design systems also help the development team to work faster, especially if there is a way for them to copy and adapt code snippets that have already been crafted and tested.

In a mature design system it is possible to skip early design exercises like wireframing and prototyping because working interfaces can be built so quickly out of real tokens, components and patterns. So users can test something much more realistic in the same amount of time.

Where to start

Starting a design system can be challenging, and must start from somewhere. We find there are two common scenarios:

1. There is already an existing design library that needs some improvement.
2. We are starting from scratch.

In the first situation, perhaps the library is a little messy, or there are gaps between the designs and what was shipped. In these cases we often start by performing an audit to gain a summary of what can be done to start a design system based on all the resources that already exist. Things that we notice in audits usually fall into three areas: improve, remove, or consolidate. For example, we often find duplicate colour tokens, and many different styles of button that could be consolidated into a consistent system, and components that are no longer used, and can be archived. Once the audit is complete we can use the findings to plan how take action, and start a design system.

In the second scenario, we prefer to start building a design system from the smallest possible elements that have the biggest impact on a future design system, often these are tokens. We often find that we do not have time to build a complete design system for our clients—after all a design system is never ‘done’—instead we try to start with something small, but effective, and high-quality that can be expanded upon later.