What a design system is, and when your product needs one

What a design system actually is

It is three things kept together. First, the basic decisions: colours, typefaces, spacing, corner shapes. Second, the components built from those decisions: buttons, form fields, tables, navigation, dialogs. Third, the rules for using them: which button means what, how a form reports an error, what happens on a small screen.

The important part is that design and engineering share it. A set of mock-ups that the code does not match is a style guide. A component library the designers never see is a code library. A design system is both, kept in step.

Signs that you need one

• The same element exists in several slightly different versions, and nobody knows which is correct.
• Every new screen is designed from nothing, and built from nothing.
• Small visual changes take days, because they have to be made in many places.
• New team members ask where things are and get different answers.
• The web product and the mobile app have drifted apart and no longer look like one company.
• Accessibility problems are fixed on one screen and return on the next.

One of these is normal. Three or more usually means the cost of not having a system is already higher than the cost of building one.

When you do not need one yet

A product still looking for its first users changes too fast for a system to keep up. Until the main screens have settled, rules written today describe an interface that will not exist next month.

At that stage a short list of agreed colours, two typefaces and one spacing scale is enough. It costs an afternoon, and it makes the later system far easier to build.

What goes in first

• Colour, with every combination checked for contrast.
• Type sizes and weights, as a short scale and not a free choice.
• Spacing, as a fixed set of steps.
• Buttons, links and form fields, with every state: resting, hover, focus, disabled, error.
• Feedback: messages, empty states and loading states.
• The layout grid and how it changes on small screens.

This covers most of what a product uses every day. Rarer components can wait until the second time someone needs them.

How to build it without stopping the roadmap

Do not pause feature work for a quarter to build a system. It rarely gets finished, and it is designed without the pressure of real use.

Start from what exists. List the components already in the product, pick the best version of each, and make that the standard. Then adopt the standard screen by screen, as each screen is next touched for a feature. Within a few months the most-used parts of the product are consistent, and no time was set aside that the business would not have spent anyway.

Who looks after it

A design system is never finished. Components are added, rules are questioned, and exceptions appear. If nobody is responsible, each team makes its own exception and the inconsistency comes back.

It does not need a dedicated team. It needs a named owner on the design side and one on the engineering side, a place where changes are proposed, and the habit of updating the system when the product changes and not the other way round.