The handoff spec we send every studio

Before a build starts we send the same short document to every studio we work with. It isn't a contract, and it isn't a requirements specification — those exist elsewhere and serve different purposes. It's six questions that are trivial to answer at the beginning of a project and expensive to answer in week three.

The reason it exists is that sub-contracting feels like more work than doing it yourself precisely when the questions arrive one at a time, spread over a fortnight, each requiring the studio to stop what it's doing and make a decision. Thirty small interruptions is a worse experience than one twenty-minute conversation, even though the total time is lower.

1. Which file is the truth

One link. One page. One frame per template, ideally named after the template rather than after what was happening when it was created.

If there are three versions of the homepage in the file, tell us which one. If there's a newer version in a different file, tell us that too. This single question resolves more problems than the other five combined, because building the wrong version of something is the only mistake in this list that wastes days rather than hours — and it's discovered at review, in front of everyone, which makes it feel worse than it is.

We don't need the file tidied. We need to know which part of it is current.

2. What's in scope to build

A list of the templates you expect to exist. Not a wireframe, not a sitemap diagram — a list, in a message, that takes two minutes to write.

It is remarkably common for a design file to contain a page nobody intends to build, and to omit one that everyone assumed was obvious. The two cancel out in the estimate right up until the moment they don't, and then there's an awkward conversation about whether a 404 page and a search results page were ever mentioned.

The templates most often forgotten, in order: search results, 404, the article listing as distinct from the article itself, any form's success and error states, and whatever the site does when a section is empty.

3. What the client will actually edit

This is the most under-answered question in web design and it has the largest cost attached.

Every template falls into one of three categories. Fixed: the client can change words and images but not structure. Partly editable: certain sections are composable, the rest is fixed. Fully composable: the client can build the page from a library of blocks and put them in any order.

The cost difference between the first and the third is significant — a fully composable template needs every block designed for every context, every combination checked, and the whole thing has to hold together whatever order somebody assembles it in. That's more work, and it's often the right work, but it needs deciding rather than assuming.

The failure mode when it isn't asked: we build a fixed template, the client asks in month two why they can't add a section, and the answer is a change request that costs more than building it composable in the first place would have.

4. What happens between the breakpoints

You've designed a desktop and a phone. Everything between them is inference, and we're happy to make it — but tell us the one or two places where the in-between genuinely matters.

Usually it's a grid that must go to two columns before it goes to one, a navigation that needs to change earlier than you'd expect because the link labels are long, or a section whose whole point is the side-by-side comparison and which shouldn't stack at all if we can avoid it.

Everything else we'll handle with common sense, and we won't come back to you about it. We're not asking you to design more screens. We're asking which decisions you want to keep.

We're not asking you to design more. We're asking which decisions you want to keep, and which you're happy for us to make.

5. Content: real, or coming later

If the copy is still being written — and it usually is — tell us the extremes rather than the ideal. What's the longest a headline might reasonably get? Might a card have no image? Could a list have one item, or forty? Is there a product name that's three words long sitting next to one that's twenty characters?

Designs are made with ideal content and they break on real content. Every one of those breaks is cheaper to design for than to patch after the client has loaded the site and found the thing that looks wrong.

We don't need the real copy. We need to know what shape it might arrive in.

6. Who signs it off, and when they're away

One name. Not a committee, and not "the team" — one person whose approval means the thing is approved.

And their holiday. Reviews stall far more often on absence than on disagreement, and knowing in advance that the decision-maker is away for the second week of a three-week build completely changes how we sequence the work. We'll front-load the things needing sign-off and back-load the things that don't.

This one takes ten seconds and prevents the specific failure where a build is finished on time and launches two weeks late because nobody could approve it.

Why it's worth the twenty minutes

Nothing on that list is difficult. All of it is knowable before a build starts. And the difference between a project where these six things were answered and one where they weren't is roughly the difference between four questions and thirty.

Thirty questions spread across three weeks is what makes studios conclude that sub-contracting is more trouble than it's worth. It isn't the building that's the problem. It's the interruptions — and nearly all of them are avoidable by asking six things at the start, when everyone still has the project in their head.

We send it as a single page. Most studios fill it in during one sitting. It has done more for the quality of our working relationships than anything else we do.