What a good web project brief contains

A brief is not a formality — it is an agreement. The more precisely it describes what needs to be done, the less room there is for interpretation, surprises and extra costs later.

Many web projects start with a vague description: "we need a new website" or "we want to redesign the site". That is not a brief — that is a wish. A brief is a document that describes precisely what needs to be done, and on the basis of which an accurate estimate and work plan can be made.

What a good brief contains

Business goal

The most important question is: what does this website need to do from a business perspective? Not "which pages are needed", but "what changes when this website is ready".

Is the goal to find new clients?
Is it self-service for existing clients?
Is it sharing internal information with staff?
Is there a specific conversion target — an order, registration or contact?

Without a business goal, it is hard to assess whether the solution works.

Target audience

Who uses this website? Not in general, but specifically: age range, prior experience with digital tools, whether it is used on mobile or desktop, any accessibility requirements.

The target audience affects design, content tone, navigation simplicity and technical decisions.

Functional requirements

A list of what the system must do. Not a design description, but a behaviour description:

the user can register and log in;
the administrator can add new products without a developer;
the system sends an automatic confirmation email;
the site is available in Estonian and English.

Functional requirements are the most important part of a brief for a developer.

Non-functional requirements

These describe how the system must perform — not what it does:

page load speed on mobile;
accessibility level (WCAG 2.1 AA);
the site must work without JavaScript;
data must remain on EU servers.

Non-functional requirements are most commonly missing from briefs — and then arrive as expensive surprises at the end of development.

Existing system and constraints

Is anything already in place? What is the current platform, what are its limitations, what must connect to the new system (CRM, payment system, accounting software)?

Integrations are often the main source of project complexity — they are much easier to plan ahead than to discover mid-project.

Content

How much content is there, who manages it, who creates it? Is existing content migrating or is everything being created fresh? Who has editorial access, who approves changes?

Content management is often the most underestimated part of a project — both in volume and in time.

Timeline and budget

Both must be realistic. If there is a fixed deadline (a trade fair where the site must be ready, for example), it needs to be stated. If there is a budget limit, it helps scope the work correctly.

The absence of a budget does not mean the project is "open" — it means there is no basis on which a developer can make a sensible proposal.

What a brief does not need to contain

A brief does not need to contain:

a description of the design (that comes later in the design phase);
a technical solution (that is the service provider's job);
a complete specification of every feature (that gets refined during the work).

A good brief is precise enough to receive a realistic estimate and start a collaboration — not so detailed that it replaces the development work.

Ask before writing

If it is unclear what the brief should contain, the most practical approach is to start with a short description and ask the service provider what information they need to give a more accurate estimate. Write to us — we can clarify what to include.

Kaido Toomingas WebPro Company OÜ

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.