From Design Brief to Live Site – The New Agency Workflow

A brief used to be a document that someone read, interpreted and rebuilt. Now it is closer to something executable, and that changes what a good brief has to contain.

The design brief used to be a document. Someone wrote it, someone else read it, and a fortnight later a design appeared that was an interpretation of it. The gap between those two moments is where most project friction lived.

That gap is closing, and it is changing what a brief has to contain. When a written description can produce a working page in minutes, vagueness stops being a harmless placeholder and becomes the actual bottleneck.

Why briefs were allowed to be vague

A traditional brief could get away with a line like "modern and clean, similar to Stripe but warmer" because a human designer sat between the sentence and the output. That person filled in the gaps using taste, experience and a few clarifying calls.

The cost was invisible but real. Every gap was filled by someone guessing, and every wrong guess surfaced days later as a revision. Two rounds of that on a mid-sized project is a fortnight gone.

What a brief has to answer now

When the description drives the build directly, the useful brief gets more specific in a few particular places.

Purpose per section. Not "a features section" but what a visitor should understand or do by the end of it.
Hierarchy. What is the single most important thing on this page, and what is genuinely secondary.
Tone, with examples. "Confident but not salesy" means little on its own. Two sentences written in the target voice means a great deal.
Constraints. Brand colours, typefaces, required legal copy, the things that are not up for reinterpretation.
Content reality. Whether you have twelve case studies or two changes the layout entirely.

This is not a new discipline so much as an old one that stopped being optional. The case for treating the prompt with the same rigour as a brief is made well in The Prompt Is the New Design Brief, and it matches what we have seen on our own projects.

How the working rhythm changes

The most noticeable difference is where feedback happens. In the old pipeline the client saw a static comp, approved something they could not interact with, and discovered problems after the build. Now the first reviewable artefact is usually a working page.

That reorders the conversation in a useful way. Questions about whether the navigation makes sense, or whether a section earns its space, get answered by clicking rather than imagining. The revisions that remain are better ones.

A practical sequence

Write the brief properly. Purpose, hierarchy, tone, constraints, real content volumes.
Generate a first pass. Treat it as a draft to react to, never as a deliverable.
Review in the browser. On a phone as well as a desktop, because that is where layout assumptions break.
Refine in place. Section by section, rather than regenerating the whole page and losing the parts that worked.
Then apply judgement. Typography, rhythm, spacing, the copy edit. This is the part that still separates good from generic.

If you want the full version of that loop written out end to end, this prompt to live website guide covers the mechanics in more depth than we will here.

What this does not solve

Being straightforward about the limits matters more than the enthusiasm.

A generated first pass is confidently average. It will produce a competent hero section and a plausible three-column feature grid, because that is what most of the web looks like. It will not tell you that your proposition is unclear, that your case studies are the strongest asset you have, or that the page should open on a number rather than a slogan. Those judgements are the work.

Tool choice matters less than people expect, too, though it is not irrelevant. If you are weighing options, this comparison of the main AI builders in 2026 is a reasonable starting point, and looking at real finished sites such as those made in Modulify is more informative than any feature table.