UI/UX system or just a Figma file? Knowing the difference

A designer hands the team a Figma file. The team forwards it to engineering. Engineering opens it, looks at 47 unconnected frames, and asks the question that breaks every handoff:

“Is this a system, or is this just a really long file?”

Nine times out of ten, the answer is the second one. The team doesn’t know it yet. They will, in week three of the build, when every change request requires a designer to point and an engineer to retrace.

Here’s how to tell the difference before you write the cheque.

★ The three-question test

We run this on every prospect’s existing design work before we quote a UI/UX engagement. If the founder can answer yes to all three, they don’t need us — they need a build team. If they answer no to any of them, the work we’ll quote starts with rebuilding the system before any new screens.

1. Are colour, type, spacing, and radius declared as variables?

Not “we have a brand colour, here’s the hex”. Variables. A real system has --color-brand-magenta, --color-bg-subtle, --space-md, --radius-md as named tokens — in Figma Variables OR in a typography styles + colour styles library that the file actually consumes. The test: change the brand colour in one place. Does every component update? If yes, system. If not, file.

This matters because engineering eats variables. Tailwind, CSS custom properties, Webflow Variables — they all consume Figma Variables 1:1 when the names match. Files without variables produce 40 hex-coded instances in the codebase that an engineer will rebuild, then mis-rebuild, then rebuild again when the colour shifts.

2. Do components have variants and props?

A button in a system has variants: primary / secondary / ghost. It has properties: size (sm/md/lg), state (default/hover/disabled), iconLeft/iconRight (boolean), label (text). The Figma component swaps these in one click.

A button in a file is six different rectangles on six different artboards, each redrawn fresh. The team doesn’t notice until the build, when the engineer picks one and the other five drift across screens. Or worse: the engineer builds six different React components because that’s what the file showed.

3. Are usage rules written down?

The system says “use Card / Pricing when the price is the main message; use Card / Feature when the icon is”. The file says nothing — the team has to guess. Guessing is fine for the designer who knows the rationale; engineering doesn’t, and neither will the next designer who joins.

Usage rules don’t have to be a 60-page brandbook. A one-pager per major component, with screenshots of correct and incorrect uses, lives in the same Figma file as the components. Twenty minutes of writing per component. Saves twenty hours of back-and-forth per surface that uses it.

What a Figma file looks like (and why teams ship them)

The file is what you get when a designer makes screens. Each screen is a destination, drawn once, in service of “showing what it looks like”. The team commissions the file because they want to see the product before they build it. Reasonable.

The trap is when “showing what it looks like” becomes the deliverable. The team approves the screens, the engineer opens them, and there’s nothing structural between the screens and a Webflow / React / Swift project. Every component is a one-off. Every spacing decision is an artboard-local pixel measurement, not a token. The engineer reverse-engineers a system that isn’t there.

By month three, the product has shipped with eight different paddings between cards, three subtly different shades of “brand neutral grey”, and a button that’s 4px taller on the pricing page than everywhere else. None of these are bugs the engineer caused. They’re bugs the absence of system caused.

What a system looks like

The system is the file PLUS the structure that makes the file reusable. A real system, regardless of brand:

• Tokens — colour, type, spacing, radius, shadow as named variables. The brand colour has a name (--color-brand-magenta), not a hex code. Spacing has a scale (--space-xs through --space-2xl), not arbitrary 13px values.
• Components — every reusable pattern (button, input, card, modal, nav, footer) is a Figma component with variants + properties. The team uses the component; nobody re-draws.
• Documentation — usage rules per component, do / do not examples, breakpoint behaviour, accessibility notes. Lives in the Figma file or in a linked Notion page.
• Engineering handoff — the system exports cleanly. Either via Figma’s native dev mode + Variables → CSS export, or via a separate token JSON file the engineering team consumes. Either way: zero hex codes in production code.

The dividing line between “file” and “system” isn’t size. We’ve seen 12-screen files that are real systems and 200-screen files that aren’t.

Why founders confuse the two

Three reasons, in descending order of frequency:

1. The designer didn’t tell them the difference. Most product designers shipped files for years before “design system” became a phrase. They’re good at making screens. They’re not all good at building structure. If the founder didn’t specify a system, the designer ships a file and calls it a system because that’s the word everyone is using.

2. The build team didn’t push back. Engineering opens the file, sees the gap, and shrugs because deadlines. They build from the file as-is, accumulate technical debt, and the team doesn’t realise the cost until it has to redesign or hire a second designer.

3. “We have a design system” gets said. Once a team adopts the language, no one wants to be the person who says “actually, this is a file”. The phrase calcifies. The system never gets built.

What this means for the build

Two paths:

• You have a file, you want a build. The build will ship. It will have visible drift. It will need a “design system project” in 6-12 months to fix the drift. Total cost: file fee + build fee + system retrofit fee. Industry-standard but expensive.
• You have a file, you want a system. Convert the file into a system before the build starts. Tokens, components, documentation, handoff. Total cost: file fee + system fee (smaller than retrofit) + build fee. We push prospects toward this path because it’s cheaper across the lifecycle, even though it adds a phase up front.

If the existing file came from a contractor and you don’t own the source, you might be stuck. We’ve inherited those projects; the conversion phase is longer and more expensive than starting from a brief. Worth it, still.

The audit

If you’re not sure what you have, we’ll tell you. Send a URL or a Figma link and we’ll record a 15-minute Loom — what’s a system, what’s a file, what would need to change to convert. Free. No follow-up sequence.

If you already know you need a system, the SaaS UI/UX design agency engagement is the closest match. The App Redesign — UX Overhaul case study walks through how we rebuilt a 1,000-user product around a real system instead of a fresh file.