Website brief for an agency: what to define before requesting a proposal

A website brief is not a wish list of colours, animations and isolated features. It is a basis for decisions. An agency needs to understand the business problem, the boundaries of the engagement and the conditions for acceptance. If those points are missing, suppliers estimate different projects even when their proposals appear similar.

A useful brief does not need to be long. It needs to reduce uncertainty in the areas that influence scope, design and delivery. Unresolved questions can remain, but they should be labelled as decisions to be made during discovery rather than treated as hidden assumptions.

1. State the business outcome and the primary action

Start with the outcome, not the page list. The site may need to generate qualified enquiries, sell products, book appointments, attract applicants or reduce routine support work. Several goals can coexist, but one should guide the main journey.

Define the primary user action as well. “Present the brand in a modern way” is not sufficiently testable. “Help a decision-maker compare three services and request a consultation” gives the team clearer direction for navigation, content, forms and measurement.

Record:

• the primary and secondary business goals;
• the main conversion and meaningful intermediate steps;
• the current baseline where reliable data exists;
• the intended improvement without promising an unsupported result;
• the owner of commercial and content decisions.

2. Describe audiences through their decision context

Basic demographic profiles rarely provide enough direction for a website. The more useful question is why someone visits and what they need to decide. Are they discovering the company, comparing suppliers, trying to solve an urgent problem or preparing an internal business case?

For each important audience, describe:

• the initial problem and level of awareness;
• common objections and perceived risks;
• evidence and selection criteria;
• the preferred purchase or contact route;
• relevant devices, languages and accessibility needs.

These details usually influence content order and page structure more directly than a broad persona based on age and interests.

3. Define scope through page types, not a page count

“A 20-page website” is not a dependable scope. Twenty location pages built from one template are different from a homepage, service hub, knowledge centre, account area and interactive calculator.

Create a provisional page-type inventory:

• homepage;
• service or category pages;
• detail pages;
• about, team and contact pages;
• portfolio entries or case studies;
• blog or knowledge content;
• legal pages;
• paid-campaign landing pages;
• search, filter, account or checkout interfaces.

Mark which types need a distinct layout, which use a repeatable template and which already have approved content. If the information architecture is not known, include structure and navigation design as an explicit discovery deliverable.

4. Express features as testable workflows

Labels such as “CRM”, “multilingual” or “booking system” hide more than they explain. Describe the user journey and the internal process that follows it.

For a form, define:

1. required fields and validation;
2. the destination of submitted data;
3. the confirmation shown or sent to the user;
4. failure and retry behaviour;
5. consent and deletion requirements;
6. the event that represents a successful outcome for measurement.

For each integration, name the system, interface, direction of data, owner and available test access. A “CRM integration” might mean a simple email notification or a two-way synchronisation with identity and status rules. Those are not comparable workloads.

5. Assign content ownership

Unclear content responsibility is a common source of delay. The brief does not need to contain every final paragraph, but it should explain who supplies and approves each content type.

Clarify:

• who writes, edits, translates and approves copy;
• which images, video, diagrams and documents already exist;
• whether current content will be retained, revised, merged or removed;
• who validates technical claims and mandatory legal text;
• the delivery format and naming convention;
• the number and scope of review rounds.

For multilingual sites, decide whether every section will be localised or whether some content will exist in one language only.

6. Document technical and operational constraints

List the domain, hosting, content management system, analytics tools, consent platform, email services and existing integrations. Add known requirements for security, privacy and ongoing operations.

Useful questions include:

• Who owns the domain, accounts and credentials?
• Must an existing platform remain in place?
• Are there hosting-region, role or backup requirements?
• Who owns updates, monitoring and incident response?
• Which browsers, devices and accessibility target will be tested?
• Are there expected traffic peaks or seasonal loads?

The technical approach should follow the requirements. Naming a platform without explaining the reason can exclude better options before the actual problem has been analysed.

7. Include SEO and migration before design decisions

For a redesign or migration, the brief should cover current URLs, organic landing pages, redirects, metadata, internal links and language versions. SEO cannot be added reliably after structure, templates and navigation are already fixed.

Request at least:

• an inventory of existing URLs;
• an old-to-new URL map where addresses will change;
• editable titles, descriptions and headings;
• control of canonicals, robots directives and XML sitemaps;
• crawlable links and a logical navigation model;
• structured data only when it reflects visible, eligible content;
• technical testing before and after release.

If search demand and keyword-to-page mapping have not been researched, treat that work as a separate deliverable rather than an invisible part of copywriting.

8. Make budget, timing and acceptance explicit

A budget range helps an agency propose an appropriate solution. Without it, one supplier may design an extensive discovery programme while another quietly excludes strategy, migration or content. State fixed dates and the reason behind them. A contracted event date is a different dependency from a preferred launch month.

Acceptance should be based on observable conditions. “Fast website” needs a defined set of templates, devices, measurement method and owner. “The form works” needs success, validation-error and transmission tests. The same principle applies to integrations, content, redirects and analytics.

Briefing checklist

Before sending the brief, answer or deliberately mark as open:

• business outcome and primary user action;
• audiences and decision situations;
• page types and approximate content scope;
• workflows, integrations and data movement;
• content production, localisation and approval;
• technical and operational constraints;
• SEO, analytics and migration requirements;
• budget range, timetable and acceptance criteria;
• project owners and decision routes.

A strong brief does not replace discovery. It ensures that every agency is evaluating the same problem. That makes proposals easier to compare and exposes the assumptions that would otherwise become additional cost, delay or disagreement after the project has started.