A useful website brief explains what needs to change, who the site is for and what a successful launch must include. It does not need to prescribe every screen. Its job is to give your team and the studio a shared basis for scope, priorities and decisions.

You can start with a short document. Mark unknowns clearly rather than filling them with assumptions. The questions below help turn an initial conversation into something a designer or developer can assess.

Explain the business and the reason for the project

Describe what you sell, who buys it and how people currently find or contact you. Then explain why the website needs to change now. Perhaps the offer has evolved, the content is hard to maintain or prospects misunderstand what you do.

Use specific examples. “People contact us asking whether we offer a service we stopped providing” is more actionable than “the website is outdated”. Include the current URL and any useful evidence, such as enquiry themes or customer feedback.

Define the audience and the next step

Identify the main visitors and the questions they need answered. A buyer evaluating a software product has different concerns from a returning customer looking for support. Prioritise the audience that matters most for this phase.

Choose the primary action: book a call, request a quote, start a trial or buy a product. Explain what happens after the action and who handles it. If enquiries go unanswered, redesigning the button will not resolve the whole problem.

List the pages and content responsibilities

Provide a starting list of pages, even if you expect it to change. Identify the content already available: copy, product screenshots, photographs, case studies and brand assets. State who owns the material and who can approve its use.

Separate content that needs writing from content that needs editing or migration. Agree whether copywriting, image sourcing and uploading existing posts are part of the studio’s scope. These tasks affect effort and timing as much as the page count.

Describe functions and integrations

Explain the actual workflow behind each requested feature. “A booking page” might mean linking to an existing calendar service or building a custom scheduling system. “Customer login” may imply permissions, account recovery and ongoing support.

  • Which forms are needed, and where should submissions go?
  • Which booking, payment, CRM or email tools already exist?
  • Who edits the site after launch, and what must they change themselves?
  • Are there languages, accessibility needs or business-specific requirements to plan for?
  • Which existing URLs, downloads and integrations need to be retained?

Share access requirements during planning, but use an appropriate secure channel for credentials rather than including passwords in the brief.

Set useful visual references

Include a few websites and explain what you like about each: the typography, navigation, image treatment or clarity of the offer. A screenshot with an annotation is often more useful than a list of agency URLs.

Review our selected work as a starting point. Ignition One demonstrates a client identity direction, while Finto is an independent website and product concept. References help communicate an intention; they do not need to be copied.

Be clear about budget, timing and approval

A budget range helps a studio recommend an appropriate scope. Name the reason for a deadline and distinguish a fixed event from a preferred date. Identify who will approve the proposal, content and design, and how feedback will be consolidated.

Agree what “ready to launch” means: content approved, key journeys checked, redirects prepared where needed, and the responsible person trained. Set expectations for maintenance and support separately from the initial build.

A website brief template you can copy

  1. Business: what we offer and the audience we serve.
  2. Current problem: what is failing, with examples.
  3. Project goal: what visitors should understand or do.
  4. Scope: proposed pages, workflows and integrations.
  5. Content: what exists, what needs creating and who supplies it.
  6. Design direction: references and the reasons we chose them.
  7. Constraints: budget range, deadline and required dependencies.
  8. Ownership: approvers, editors and the post-launch support plan.

For a software business, use our SaaS website checklist alongside the template. If the product itself is still uncertain, compare a prototype with an MVP before defining a larger build.

Explore our website design and development service or send us your outline. A clear brief gives us a better starting point for a useful scope and proposal.

Contrivea studio notes · 17 October 2026. About the studio.