New format
Website specification: brief, structure, and common mistakes
A website technical specification locks what should be delivered: goals, audience, pages, design direction, responsive rules, integrations, and timelines. Without it the contractor leans on their own taste — and the result often misses yours.
Below: how to reach shared understanding through a brief, what to put in the document, why a prototype helps, and which mistakes most often lead to rework. This isn’t a “sign and forget” template — it’s a working contract of meaning between both sides.
Why a spec at all
The document cuts “I meant something else.” The contractor follows agreed requirements; the client checks stages instead of arguing about button color at the end.
Without a spec you hand the business to someone with another taste and another picture of success. Small tweaks are normal; a concept change at the finish almost always means a leaky brief.
Each side’s jobs:
- client — goals, limits, materials, acceptance
- contractor — delivery to the spec, questions on ambiguity
- both — timelines and “done” criteria
Brief first, then the document
A long requirements wall before a conversation often scares people and still stays leaky. A brief is a short questionnaire: business, audience, site goal, examples, style and feature wishes.
In dialogue the contractor offers workable options (for example, menu type); the client accepts or rejects. From the answers you build a structured spec — no longer a negotiation room, but instructions.
What to include in the spec
Describe the company and product so someone outside your industry gets the point. Lock audience and site goal: lead, purchase, subscribe, signup — that drives UI emphasis.
If a site already exists — the URL, strengths and weaknesses, what to keep. Then: page and menu structure, integrations (CRM, payment, analytics), style and references, materials (copy, photos), responsive and devices, questions and limits.
Document blocks:
- company and offer
- audience and site goals
- current site (if any)
- structure and key screens
- design references and tone
- content and who prepares it
- responsive and integrations
- timelines, stages, access
Sample brief fields
| Item | What to write |
|---|---|
| Company | What you do, product, differences |
| Audience | Who buys, job, barriers |
| Site goal | Lead / purchase / other CTA |
| Structure | Pages, menu, required blocks |
| Look & feel | References, colors, fonts, tone |
| Tech | Responsive, CRM, analytics, payments |
Prototype before “pretty”
A prototype shows the frame: where the headline, offer, form, and reviews sit. It isn’t polished design. Without references and clear placement rules the contractor guesses — and “light tones” mean different things to everyone.
It helps to review competitors and strong third-party sites as structure orientation, not copy-paste. A prototype is especially useful with many blocks and contested accents.
Common client mistakes
No stage deadlines — the project drifts. No references — endless taste revisions. No saved hosting and domain access — risk of losing control after a contractor change.
Another mistake is staying silent about doubts. If a spec line is unclear, clarify before layout. The client may be weak in design or code — that’s fine; what matters is locking the business outcome and acceptance criteria.
Checklist before work starts:
- goals and CTA agreed
- references exist, not only “pretty”
- stage deadlines written
- who provides copy and photos is clear
- domain and hosting access stays with the client
FAQ
Are a brief and a full spec the same thing?
No. A brief is a short questionnaire and discussion. The spec is the final action guide once details are agreed.
Can freelancers work without a spec?
They can, but dispute risk is higher. At minimum lock goals, structure, references, responsive rules, access, and deadlines.
Do you need a prototype?
Preferably yes: it shows block placement before polished design and cuts “the button isn’t there” revisions.
How should you describe design?
Not “make it pretty” — share reference links, palette, fonts, and tone. Vague words mean different things to everyone.
Who writes the spec — the client or the studio?
Often together: the client brings business and goals; the contractor structures and clarifies tech. Both sides approve the final.
Is a copy brief different from a site spec?
Yes. The site spec covers development. A separate copy brief describes volume, keywords, and page tone.
Brief says “make it pretty” — and the build turns into endless taste edits?
We’ll lock goals, structure, references, and stage deadlines — a prototype before polish, access stays with you.
Discuss the task
