How to brief a 3D website

Seven things to decide first

None of these require you to know anything about the technology. All of them change the price.

• What the 3D is for. Explaining a product, letting somebody configure it, showing a space, or looking different from your competitors. All four are legitimate. They are not the same build and the last one has no usability argument, so say it plainly rather than dressing it up.
• What the visitor can do. Nothing, rotate it, or change it. Each step up is a different project. The third one brings state, combinations, testing and usually a way to save or share a result.
• Whether the models exist, and in what format. If they came from engineering or manufacturing, say so. See below, because this is the one that catches people out.
• The oldest device that matters. Look at your analytics by revenue, not by visits, and name a phone. "It should work on everything" is the most expensive sentence in the brief, because the work goes into the fallbacks rather than the scene.
• How many scenes. One on the homepage is a project. One per product is a system, and a system is designed differently from the start. Deciding this after the fact means rebuilding.
• Who edits what afterwards. Text and images, you. But can somebody on your side swap a model, or does that come back to us every time? Both answers are fine. Only one of them is cheap to add later.
• Whether the rest of the site is in scope. A scene dropped into an existing site and a new site with a scene in it are different amounts of work, and briefs are often silent on which.

The file you already have

If you make a physical product, somebody in your company will say the reassuring thing: we have the 3D files, so that part is done.

It is worth understanding why that is usually not true, because otherwise it arrives as an unwelcome line on a quote and looks like padding.

A file built for engineering describes the object completely. Every thread, every internal part, every tolerance, because a machine has to make it. A file built for the web describes only what a person will see, at the size they will see it. The first is source material for the second, not a substitute.

Turning one into the other means rebuilding the geometry at a sane density and remaking the materials, because engineering materials carry no visual information. On a complicated product that is days, sometimes weeks. Your file makes it possible and cheaper than starting from nothing. It does not make it free.

Put the format in the brief. Whoever is quoting will know immediately what they are looking at, and you will get a number that survives.

Ask for the weight, in the brief

This is the single line that most improves the quotes you get back, and almost nobody includes it.

Write: "tell us the compressed page weight you are targeting, and when in the process you decide it."

You do not need to know what a good answer is. You need to see whether there is an answer at all. A studio that has shipped this work will give you a number and say it gets agreed before anything is modelled. A studio that has not will say they handle performance at the end, which means the models get built without a budget and then cut to fit, and that is where quality goes.

For reference: our own homepage runs a full scene and ships 186 KB of compressed JavaScript, with three.js itself accounting for 87 KB of that. We publish it so you have something to hold other answers against, not because it is a target for your project.

What not to put in

Two things that make briefs worse.

A technology. "Built in three.js" or "we want WebGPU" narrows the field before anybody has understood the problem, and it invites a yes from people who will use it whether or not it fits. Describe what has to happen and let the answer come back with a reason attached.

A folder of award-winning sites with no explanation. Reference is useful, but only with a sentence saying what you are pointing at. "This one, because you can tell the weight of the object" is a brief. Eight links to Awwwards is a mood, and a mood gets priced defensively, which means high.

The page that gets you comparable numbers

Send the same document to everybody. One page is enough:

• What the 3D is for, in one sentence.
• What the visitor can do with it.
• What assets exist and in what format.
• The oldest device that matters, named.
• How many scenes, now and in a year.
• Whether the rest of the site is in scope.
• Who writes the copy, and when it will be ready.
• The weight question, asked exactly as above.
• Your decision date, and who signs.

That last pair is not filler. Timelines run from when content is finalised, not from signature, and it is the variable that delays most projects. A studio that knows who signs and when copy lands can give you a real date. One that doesn’t is guessing, and will pad.

Reading the quotes you get back

With a brief like that, differences in price start meaning something. Three things to look for.

Whether the scope is written down. A number with no scope is not a quote, it is an opening position. What is included, what is not, and how many rounds of change are in it.

Whether anybody pushed back. The most useful quote we ever send is often the one that says a chunk of the brief is not worth building. Somebody who accepts all nine points without comment has not thought about your project, they have priced your document.

Whether the timeline has conditions attached. "Eight weeks" is a wish. "Eight weeks from content sign-off, assuming feedback within three working days" is a plan.

Where this advice works against us

A brief written this well makes us easier to compare, and that is not in our interest.

Vague briefs favour whoever is best at selling, because there is nothing to check the promise against. A brief with a named device, a weight question and a decision date favours whoever is best at the work. We would rather compete on the second, but it is worth being clear that the nine points above are not a favour: they narrow the gap between studios and put more of the decision on price and evidence.

The other thing it costs us: a brief this specific occasionally concludes that the project should not happen, or should be much smaller. That has happened, it will happen again, and it is the correct outcome when it does.

If you can’t answer half of these

That is normal and it is not a reason to delay.

It does mean the first thing you are buying is help deciding, not production. That is a real piece of work with a real price, and it is much cheaper than discovering the answers during a build. Say so in the brief. Anybody worth hiring will tell you the same thing and quote for it separately.

What does not work is asking for a fixed price on a project nobody has defined yet, and then treating the spread in the answers as evidence that somebody is trying it on.