Blog

What a design system is for

Tokens, components, and documentation a team can keep — not a file of pretty buttons they abandon in a month.

A grid of dark ceramic modules with teal channels, one module lifted. No people, no text.

A design system is for the next screen, not the last presentation. It is tokens, components, and documentation a team can open in six months and still trust. If nobody can add a view without asking the original designer, you do not have a system. You have a souvenir.

Fluids Design includes a system when the product will live past launch. We will also work inside yours, or tell you if it should be fixed, or replaced. We will not sell you a library for a one-week landing page that will never grow a second page.

What actually belongs in a design system?

Named decisions. Colour, type, space, radius, elevation — as tokens, not as a style guide screenshot. Components with every state an engineer will hit. Documentation next to the thing it describes, not in a slide deck that goes stale the week after the workshop.

Tokens first

If the brand cannot be expressed as a short list of values, the interface will invent new greys. Tokens are the contract. They are also how design survives the build: the engineer does not sample a PNG.

Components with every state

Default is not enough. Hover, focus, disabled, loading, error, empty. Arabic labels that wrap. A button that becomes two words in English and a sentence in Arabic. If those are not in the file, they will be invented in code, differently, twice.

Docs next to the code

A PDF of components is a brochure. The useful system is the one in the repository, or in a tool the team already opens. We document how to use a thing, and when not to.

When do you not need a design system?

When the job is one page, one campaign, one week, and nobody will extend it. A sprint that ships a landing page needs a tight type scale and a few components, not a token architecture. Calling that a “system” is theatre. See how we engage — Sprint, Project, Embedded — and pick the one that matches the life of the work.

Should you keep an existing system?

Sometimes. We will work inside yours if it holds. We will fix it if the tokens are there and the components are lying. We will replace it if the team has already abandoned it. We will tell you which one it is after we have opened the file, not on the sales call.

What will we refuse to ship?

  • Unnamed colours sampled from a mock.
  • Components that only exist in their happy state.
  • A library with no empty, error, or disabled.
  • Documentation that cannot be found from the component.
  • A “system” that is only a Figma page titled System.

How does this show up in a project?

In a full project it is included, not an add-on. It is designed as the screens are designed, then handed over in Ship — tokens, specs, assets, or built by us. That sequence is on how a project runs. If you only need the system repaired, say so. That can be a sprint.

If you want to see how we treat real pages, look at the sites we designed, then book a call.

Book a call