Writing a website brief without the vocabulary

You do not need to learn web design vocabulary to write an accurate brief. You need to describe what the business needs the site to do, in plain sentences, and let the supplier translate that into their own terms — that translation is part of their job, not a prerequisite for yours.

Why jargon in a website brief for web design or website design is worse than no jargon at all in a design brief

A term used correctly saves a sentence of explanation. A term used incorrectly costs several, because a supplier first has to work out what you actually meant before answering what you asked. Take “we want a responsive site with a good CMS”, written by someone unsure what either word means. It can describe almost any project. Now take “the site has to look right on a phone, and someone in our office who is not a programmer has to be able to update the opening hours”. It describes one project precisely, using no jargon at all. The second version is the more useful brief, not the less professional one.

Translate the requirement, not the term: writing brief template answers instead of studio jargon

For nearly every piece of web design vocabulary — whether you’re briefing a freelancer or a design studio — there is a plain description of the underlying need. It works just as well in a brief. The table below gives the plain-language version for the terms that come up most often when a business is briefing its first website.

Term you might hear	What it actually means	What to write instead if you are unsure of the word
CMS (content management system)	The software that lets someone edit pages after launch	“Someone in our office needs to update prices and hours without calling anyone”
Responsive	The layout adjusts to phone, tablet and desktop screens	“It has to work properly on a phone, not just look shrunk down”
Wireframe	A plain layout sketch before design is applied	“Show me the structure of a page before you show me the colours”
Sitemap	The list of every page and how they connect	“List every page you plan to build, before you build any of them”
Staging site	A private preview version before launch	“I want to see it before it goes live, not after”
Hosting	Where the site’s files actually live online	“Who is paying for and controlling the server it runs on”
SEO	Search-engine optimisation — being findable on Google	“People need to be able to find us by searching, not just by typing our name”

Describe the job, not the technology: what you need site-wide, within real constraints

If you are unsure whether you need an online store, a booking system, or a content management system, do not guess at the term — describe the transaction. “A customer needs to be able to pay us online and get an automatic receipt” is a complete functional requirement. A supplier can quote against it regardless of which platform or technical term eventually attaches to it. The term is the supplier’s problem to choose; the transaction is the fact only you actually know.

Three questions that surface real requirements without any jargon

Ask yourself these three questions and write down the answers in full sentences. What does someone do on this site right now, on your current site or by phone, that you want them to be able to do online instead? What does someone in your own business currently do by hand that the new site should do automatically? What has gone wrong with your current website? Describe it as an event, not a diagnosis — “the booking form doesn’t send us an email” rather than “the integration is broken”. You may not know which part is actually broken, and it is not your job to diagnose it before you have even hired anyone.

Vocabulary picked up during the project is a bonus, not a requirement

Most business owners end a website project knowing considerably more web design vocabulary than they started with, simply from being in the conversations. That is a welcome side effect, not a precondition. Nothing in this section, or in the brief itself, depends on arriving at the first conversation already fluent in terms a supplier uses every day for a living. Treat any term you do not recognise during the project the same way suggested above. Ask for a one-sentence plain explanation on the spot, rather than nodding along and looking it up later.

A design agency’s job is to meet you in plain language, not the other way around

A competent supplier translates plain descriptions into technical decisions as a matter of course. Translating in the other direction — jargon into a real requirement — is slower and more error-prone. And it is not a skill a business owner is expected to have. If a supplier responds to a plain-language brief by insisting on jargon before they will discuss it, that tells you something useful about how the rest of the relationship will run.

Website design services sets out, in plain terms, what is actually included in a typical build — pages, content, functions and the handover. It is worth reading before you write a brief, because it gives you the vocabulary of what is normally on offer, without requiring you to learn the vocabulary of how any of it is built.

What to do next: writing website brief sentences in plain language

Write the brief entirely in plain sentences describing what the business needs the site to do. Use the table above only to check your own understanding, not to write the brief itself. What a brief must contain sets out the nine specific facts every brief needs, none of which require a single piece of web design terminology to state accurately.