How to write a useful website project brief

Start with the business task

State why the project exists. “We need a modern website” gives little guidance. “Visitors cannot compare our packages and staff answer the same pre-booking questions every day” identifies a task that design and content can address.

Name the primary audience and the action that matters. If several audiences use the site, explain their different needs. Include what would make an enquiry unsuitable so the brief does not simply optimise for more form submissions.

Copy these questions into your brief

Download the plain-text website brief template and fill in what you know. Leave unresolved points as questions for your supplier.

1. Purpose: what should improve, and how will you recognise the improvement?
2. Audience: who visits, what do they already know and what must they decide?
3. Offer: which services, products or programmes need explaining?
4. Content: what copy, images, reviews and project evidence can you provide and publish?
5. Functionality: which forms, bookings, accounts or workflows must work? Describe examples.
6. Existing systems: what software, domains and data does the project depend on?
7. Ownership: who approves work, supplies content and resolves conflicting requirements?
8. Constraints: what is the budget, is there a genuine launch deadline and what drives it?
9. After launch: who updates content, manages accounts and handles support?

Include one difficult example

A real edge case can be more useful than a long feature list. For a booking site, describe a customer changing dates after a deposit. For a service business, describe an enquiry that needs routing to a particular person. Use fictional or anonymised records in the initial brief.

Distinguish requirements from ideas. “Staff need to find outstanding bookings” is a requirement. “We want a dashboard with four coloured cards” is an idea for meeting it. This leaves room for a simpler design if one is available.

How long does a website project take?

Digizu’s published FAQ gives a typical marketing-website timeline of 4–8 weeks, depending on scope and content readiness. That is not a guarantee for every build, and it should not be applied to an unspecified application.

Ask for a schedule that includes your own tasks: supplying copy, approving designs, reviewing test pages and signing off launch. A fixed event date may require reducing scope or separating the first release from later features. Booking software and integrations can introduce dependencies that must be investigated before a firm schedule is possible.

Compare suppliers on responsibility as well as style

A freelancer, studio or larger agency can be appropriate depending on the project. Ask who does the work, who communicates with you, how absence is covered and how the site can be maintained later. The size of the supplier is less informative than the delivery and support arrangements.

Give shortlisted suppliers the same brief. Ask each to explain scope, assumptions, exclusions, recurring costs and the handover. Our quote-comparison guide helps make those proposals comparable.

Prepare for launch while the project is still small

List existing URLs and account access early. Decide who checks forms and customer journeys, and who can authorise launch. If the new site replaces an old one, include the migration tasks in the brief rather than adding them the day before release.

For an initial conversation, send what you know and mark unresolved points clearly. Digizu’s services overview can help identify whether the work is primarily website design, booking development, custom software or automation. A short, specific brief is enough to start that discussion.