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 the reasons aren't the ones most articles about design handoff go on about.

1. Consistent spacing, above everything else

This is the single largest factor and it has nothing to do with tooling. It's 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 component becomes its own decision, and 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, just to have used the same handful of numbers more than once. That alone does most of the work.

The same goes for 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 whole palette and type ramp move across in one pass and stay connected to their source.

When they don't, we're eyedropping. Eyedropping mostly works, and it's exactly where a #1B1B1B 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 tells us what you meant, and that's what we're short of.

A card built with auto layout says: this padding is intentional, this gap is intentional, and this text is expected to grow. The identical card drawn by hand says nothing, 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 with it.

Static frames are 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 a long list of questions.

4. One version of the truth

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

We'll build the wrong one and you'll spot it at review. Everyone will be 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.

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 matters and 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 whole 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, ideally written down 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.

A list of questions would just move our problem onto your desk, so it's 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 aim is that nothing is a surprise at review. A messy file costs a little extra time. A surprise at review costs some trust, and that comes back more slowly.