tokens
before pixels.

The fastest way to draw sixty screens is to draw none of them twice.

So the first day of every week goes to the parts every screen shares — colour, type, spacing and the shell — before a single screen exists. It looks like a slow start. It's the reason the rest of the week is fast, and the reason the files are still useful a year later.

A screen drawn before the system exists has to be redrawn after it. Every early button becomes a later inconsistency; every one-off colour, a later clean-up; every “we'll tidy it at the end”, a day you don't have.

So we skip that step. The system is decided while it's still cheap to decide — before thirty screens depend on it — and everything after it inherits the decision for free.

• Colour as variables — dark and light from the start, not converted at the end.
• Type as text styles: one scale for web and mobile.
• Spacing and radii as variables, so every layout snaps to the same rhythm.
• Components with auto layout, and layers named for code and Framer.
• The shell — navigation, tables, forms, dialogs — built once and reused everywhere.

None of this is decoration. Each item removes a decision from every screen that follows, and a week is mostly a question of how many decisions you can avoid making twice.

On Signal AI Ops, an AI-agent operations dashboard designed in one week, that came to:

Once the system holds, a new screen is a matter of arrangement, not invention. That's why days two to four go to screens — every one, web and mobile — and day five to the states that make a product feel finished: empty, error, loading, tooltips, dialogs, toasts.

States are where most products look unfinished, because they're drawn last and in a hurry. With a system they're drawn last and calmly: the empty table already has a style, the error already has a colour, the dialog already has a size.

“nothing drawn twice.”

The system pays for itself again on day 6. A note like “the primary blue is too loud” is one variable, not sixty screens. Fix a token, and every screen that uses it follows — light and dark, web and mobile.

That's what makes a single round of notes enough. When a change costs minutes, you can afford to take all of them in one go.

You don't get pictures of screens. You get the system that made them: components, variables, text styles, auto layout, named layers and an annotated handoff — yours once payment has cleared.

Your next screen, made by anyone, starts from the same parts. Your developers read the same names in Figma that they'll write in code.

Add front-end code and the same tokens become the code's tokens, so the Figma file and the build don't drift apart. The repo is handed over on day 14.