Your own design systems

The Design page. Alongside the thirteen the platform ships, your workspace can author its own.

This is the point of the whole feature. Set your brand up once and every application in the workspace can be built in it, so the fifth looks like it came from the same company as the first. Change the palette later and every one of them restyles in seconds, with no build spent — a rebrand that would be a quarter of work across five applications is an afternoon here.

Building for clients? One design system per client, in a workspace per client. Everything you hand over is in their brand rather than in ours.

Your own systems are visible and editable only to your workspace. A client's brand belongs to the people working with that client, not in a gallery everyone browses. Two workspaces can each have one called "Primary" and neither will ever see the other.

Starting one#

Two ways in.

From one of the platform's. Copies its palette and its brief, which is a far better starting point than an empty page — you are adjusting a working design system rather than inventing one.

From nothing. Neutral greys and system type, recognisably unfinished rather than a quiet copy of whichever system happens to be the default.

Importing a brand#

Three routes, and each of them proposes a palette and a brief for you to read, edit and accept. Nothing is saved automatically — a brand imported wrongly and applied silently is worse than one entered by hand.

From files#

Logos, screenshots, a brand book as a PDF, your web fonts. Images and PDFs are read directly.

Fonts you upload are copied into every application built in that design system, so your typefaces are genuinely used rather than approximated.

From a website#

Give it an address. The page is opened in a real browser and its colours, typefaces, corners and spacing are measured from what is actually rendered — not from what a brand document says they should be. You get a screenshot alongside the proposal.

This is usually the fastest route, and often the most accurate.

From a Figma library#

Published colour and text styles, read through Figma's API with a personal access token. The token is used for that one request and never stored.

The brief matters more than the palette#

The palette takes ten minutes. The brief is what makes applications in your design system feel like your software.

Write it as instructions to somebody designing screens:

Dense. Tables rather than cards. Navigation in a left sidebar, always visible. Primary actions top right, never floating. No decorative imagery. Numbers right-aligned and tabular. Errors stated in words, not just in red.

Be specific about the page architecture — where navigation lives and what the content actually is. That instruction is binding, and it is what stops every application coming out with a sidebar and four stat tiles.

Sample screens#

A design system can have sample screens drawn by the builder — an overview, a list and a detail page — stored with it and shown in the gallery. That way people choosing see what an application becomes rather than a row of swatches.

Changing one later#

Colours, type and shapes reach existing applications immediately, with no build spent.

A changed brief cannot restructure screens that already exist. The workbench notices, says the design system has moved on, and offers Restyle on each application, which runs a build.

Never automatic. One edit should not silently spend a build on every application in the workspace.