What a tidy Figma file is worth

We build from whatever arrives. Some files are immaculate, with variables, named components and a documented spacing scale. Some are a single page containing forty frames called Frame 214. Both get built, both get built properly, and we don't send passive-aggressive emails about either.

But the tidy ones are quicker and therefore cheaper, and it's worth being specific about why — because the reasons aren't the ones most articles about design handoff talk about.

1. Consistent spacing, above everything else

This is the single largest factor and it has nothing to do with tooling. It's about arithmetic.

If the gaps in your design are 8, 16, 24, 32 and 48, we build a spacing scale once and use it everywhere, and every component inherits from it. If they're 14, 18, 23, 31 and 46, every single component becomes its own decision — and worse, each one becomes a question we have to either ask you or guess at. Was 23 deliberate, or is it a 24 that moved?

You don't need a documented system or a token library. You need to have used the same handful of numbers more than once. That alone does most of the work.

The related version is type: if there are five heading sizes in the design, there's a ramp. If there are eleven, there are five sizes and six accidents, and we'll be asking about each of the six.

2. Variables for colour and type

Named variables map almost directly onto design tokens in the build. When they exist, the entire palette and type ramp move across in a single pass and stay connected to their source.

When they don't, we're eyedropping. Eyedropping mostly works, and it's exactly where a #1B1B1B quietly becomes a #1C1B1B on one component because a layer had an opacity on it. Nobody notices for a year, and then somebody does, and it's a bug report.

Naming matters more than completeness here. Three well-named variables beat thirty called Colour 7.

3. Auto layout on anything that repeats

Auto layout communicates intent, and intent is what we're short of.

A card built with auto layout says: this padding is deliberate, this gap is deliberate, and this text is expected to grow. The identical card drawn by hand says nothing at all, so we have to decide for ourselves whether the space under a heading should hold when the heading runs to two lines, or collapse, or grow proportionally.

Static frames are completely fine for one-off compositions — a hero that only exists once doesn't need it. For anything the CMS will repeat with content of varying length, auto layout is the difference between a build and an interrogation.

4. One state of the truth

The genuinely costly thing is not a messy file. It's two files, or three versions of the homepage in one file, distinguishable only by somebody's memory of which was most recent.

We will build the wrong one. You'll spot it at review. Everyone will be very polite about it and a day will be gone.

This is the cheapest problem on the list to prevent and the most expensive to hit. One link, one page, one frame per template, and a note saying which is current if there's any doubt at all.

Tidy is optional. Unambiguous isn't.

5. Tell us what happens in between

Designs describe a desktop and a phone. Everything between those two is inference, and we're happy to infer — but there are usually one or two places where the inference genuinely matters and where getting it wrong means rebuilding a component.

A three-column grid that should become two before it becomes one. A navigation that has to collapse earlier than expected because the link labels are long. A comparison section whose entire purpose is the side-by-side, and which shouldn't stack at all if there's any way to avoid it.

That's five seconds to say and an afternoon to guess wrong.

6. Say something about the content that doesn't exist yet

Empty states, long names, missing images, and what a card does when the client writes forty words instead of twelve.

You don't need to design any of them. You need to have an opinion we can ask for, and ideally to have written it somewhere. The most useful single sentence a designer can add to a file is what the longest realistic version of a piece of content looks like.

What we do when the file isn't tidy

We build it anyway, and within one working day of starting we send back a list of every ambiguity we found alongside the call we intend to make on each one.

Not a list of questions requiring answers — that just moves our problem onto your desk. A list of decisions, already made, that you can correct where we've got them wrong. Most studios correct two or three and let the rest stand.

The point is that nothing is a surprise at review, which is genuinely the only part of this that matters. A messy file costs a little extra time. A surprise at review costs a relationship a small amount of trust, and those don't recover as quickly.