A web design brief gives an agency enough context to recommend a useful scope. It explains what your NZ business needs the website to do, who it serves, what content exists and which decisions still need work. You do not need to arrive with a finished sitemap or every technical answer.
This guide is written by No Brainer Creative, an Auckland web design and digital marketing agency. It includes a reusable brief you can copy into a document and use with any provider. It does not promise a particular build price, turnaround or sales result.
What a useful website brief should answer
Start with the business need. A site that helps customers request a quote needs a different journey from a store selling products or a business taking appointments. Choose a main purpose and identify secondary needs so the agency can explain the trade-offs.
Describe the customer and the area you actually serve. Include the questions people ask before they enquire or buy. This is more helpful than beginning with a long list of visual effects or a general request to “make it modern”.
For an existing website, explain what is useful and what is getting in the way. Keep a record of important pages, customer journeys and systems that must be reviewed before a replacement goes live. A redesign should start with an understanding of the current business, not an assumption that everything needs to be discarded.
Copy this web design brief template
Download the fillable website brief (PDF, 3 pages). Save a copy and complete it in a PDF reader, or use the copyable template below for your project discussion.
Use the headings below as a starting point. Keep answers specific, and write “to discuss” where you need advice. The provider should help resolve unknowns before treating them as a fixed scope.
Paste the outline into a document or your message and fill in what you know.
To copy without JavaScript, select the template below or download the PDF above.
Website project brief
Business and current website:
Business name, current URL or new-site status, and a short description of what you do.
Main goal:
What should the website help the business achieve? What should a suitable visitor do next?
Audience and service area:
Who needs the service or product, where are they, and what do they need to understand before acting?
Essential pages:
List the services, products, locations and supporting information needed at launch. Separate later ideas.
Features and connected tools:
Describe forms, booking, shop, payment, CRM or other systems. Name existing tools and the intended handover between them.
Content and brand assets:
What copy, logos, photography, product information and approved testimonials are ready? Who supplies or approves the rest?
Reference sites:
List a few URLs and explain a specific feature you find useful. Describe the need behind it rather than requesting a copy.
Existing-site requirements:
Which URLs, content, records and business processes must be preserved or reviewed during a migration?
Budget and ongoing costs:
Give a range if you have one. Ask the provider to separate the build, hosting, software, care and marketing costs.
Timing and approvals:
State any real deadline and its reason. Identify who provides feedback and who gives final approval.
Launch checks and later measurement:
What must work before launch, and how will the business assess the result afterwards?
Questions and options:
List the decisions you want the agency to help with, including training, ownership, support and scope choices.
Turn features into a customer journey
“We need a booking system” is a starting point, but the useful detail is what should happen. Which service is booked, who is available, what information is collected, who receives the notification and what happens if the appointment changes?
For a quote request, describe the information your team needs and who handles it. For a shop, describe product options, payment, delivery information and the work that follows an order. A short example helps an agency identify dependencies that a feature label can miss.
Keep the proposed journey separate from a claim that it already works. If the site connects to a CRM or automation workflow, agree the fields, events, ownership and test cases. A saved connection is not proof that enquiries or messages are delivered correctly.
Be clear about content and evidence
List the content you have and the content that needs creating. A page name alone does not supply its service details, images or call to action. Decide who gathers the facts, who writes the copy and who checks the finished page.
Use genuine examples of your work where you have permission. Provide original photographs and accurate descriptions rather than asking an agency to invent a case study or a result. If you want testimonials included, confirm their source and the permission to use them.
For reference sites, explain the part you like: a clear navigation label, a useful service comparison or a straightforward enquiry flow. A designer can then respond to the underlying need using your own identity. Our No Brainer project portfolio can help you discuss the kind of website and design work you have in mind.
For a dealership example, our Esteem Cars website project shows vehicle presentation and mobile layouts that can help explain the customer journey you want to support.
Include SEO and migration in the scope
If the existing website has useful pages or search visibility, put that information in the brief. Ask who will review the current URLs, choose the pages to keep or improve and plan any redirects needed when addresses change. Do not wait until launch to discover that important content was left out.
Clarify which search work is included. Basic page structure, metadata and a working sitemap are different from an ongoing SEO programme. Ask how target services and customer questions will influence the page plan, and how the work will be checked.
For a redesign, the brief should identify the current platform, forms, domains and third-party tools. Access arrangements can be agreed separately. The agency needs enough information to assess the dependencies before committing to a migration plan.
Compare proposals by scope and responsibility
When proposals arrive, compare what each one includes and the assumptions behind it. A lower total may cover fewer pages, a different content responsibility or less integration and testing work. A longer proposal is not automatically a better fit either.
| Area to compare | Useful question |
|---|---|
| Pages and content | Which pages are included, who writes them and how are changes handled? |
| Design and revisions | What is custom, what is reused, and how will feedback be agreed? |
| Features and integrations | Which journeys are included and what dependencies remain to be checked? |
| SEO and migration | What happens to existing URLs and which search tasks are included? |
| Testing and launch | What must pass, who signs off and what happens if a required check fails? |
| Ownership and ongoing costs | Who controls the accounts and assets, and what is paid after launch? |
For more buying questions, read our affordable web design guide. It focuses on scope, costs and handover rather than a ranked list of providers.
When you have two proposals, use our website quote cost comparison to total setup, monthly, annual and required one-off costs over the same period. Use the same GST basis and check exclusions separately.
Agree how the finished website will be accepted
Write a short launch checklist around the most important customer paths. It might include finding a service on a phone, sending a controlled test enquiry, changing a booking where applicable, checking product information and reviewing important redirects. Choose the tests that match the agreed build.
Name the person who checks the facts and the person who can approve launch. Record unresolved items and their owners. A preview looking good is different from a verified form submission, booking or payment journey.
After launch, assess the site with the evidence available. Keep visits, enquiries, qualified conversations, appointments and sales distinct. Agree which outcomes the business can record so the review does not rely only on a traffic graph.
Web design brief questions
How long should the brief be?
Long enough to explain the business need, scope and unknowns. A concise document can start the conversation; complex shops or integrations need more detail. You do not need to solve every technical question before contacting a provider.
Should I include a budget?
A range helps the provider discuss scope options. Ask for the initial build and ongoing costs separately. If the budget is undecided, explain that and ask which decisions will affect the quote.
Do I have to write the website copy?
Agree who does it. You may supply facts and draft content, ask for copywriting, or use a shared process. The proposal should explain the responsibilities and approvals.
How long will the build take?
Ask for a timeline based on the agreed pages, content, integrations and review process. A universal number of weeks cannot account for every project’s dependencies.
Can No Brainer help shape the brief?
Yes. Our Auckland web design service starts with the business and the customer journey. Tell us about the website you need, using the template above if it helps. We can discuss the unknowns and a practical scope.