Mara logo

Design System

The single source of truth for how a product looks and behaves: tokens, components, patterns, usage rules and the process for changing them.

Deliverables & Artifacts

A design system is broader than a component library. It includes the design tokens that define colour, spacing and type; the components built from them; the patterns that combine components into recognisable solutions; accessibility standards; and — the part most often missing — a documented way to propose, review and ship a change.

Without that last part a system becomes a snapshot: accurate at launch, wrong within two releases, and quietly abandoned once designers start detaching instances. Systems justify themselves on products with many screens and more than a couple of contributors. For a five-screen MVP a style guide is the right size, and building a system instead is a way of spending a month not shipping.

In practice

A team of nine shipped across web, iOS and an internal admin tool with three separate palettes. Before: a brand colour change meant hunting hex values across three repos and took a week. After tokens fed all three platforms from one source, the same change was a pull request. The catch — the migration needed a visual regression suite first.

Learn more

You may ask

Frequently Asked Questions

When is a design system worth building?

When more than one designer and more than one engineer touch the interface, or when the same component is being rebuilt on different platforms. Below that threshold the maintenance cost exceeds the consistency benefit.

Can we adopt an off-the-shelf system?

Yes, and for internal tools it is usually the right call — an existing library plus your own tokens gets you most of the value for a fraction of the effort. Customer-facing products with a distinct brand eventually outgrow the defaults.

Related terms

All terms

Let's talk about your product.

Happy to look at what you're building and say where design would move the needle.

Contact Us