Start with the business outcome.
‘We need a modern website’ describes an ambition, but it leaves the important decisions open. Explain what is difficult today: visitors cannot find the right service, the team cannot update the content, or enquiries arrive without enough context.
Choose a primary visitor action. That might be requesting a quote, purchasing a product or discussing an agency partnership. Then describe what someone needs to understand before taking that step.
- Who is the website for?
- What should visitors do next?
- What is getting in their way today?
Bring the evidence, not just the references.
Reference websites help explain a visual preference. Real project photographs, service details and examples of your work give the new site something specific to communicate. Collect both, and label why each reference is relevant.
Separate approved content from material that still needs writing, photography or permission. A missing case study can change the structure of a page as much as a missing technical feature.
For a concrete reference, explore the Peaster Pools project and note which parts of its presentation are relevant to your own brief.
Describe how the site will be used behind the scenes.
List who will edit pages, where enquiries should go and which systems the website must connect to. Include the existing domain, hosting, product catalogue and any forms or booking tools that the team depends on.
For an existing website, identify URLs that need to remain available. A redesign should account for useful existing content and links, rather than treating the old site as disposable.
Make the constraints visible.
Share the intended budget range, launch date and the reason behind that date. Identify who approves the work and who supplies the content. These details help turn an open-ended idea into a realistic sequence of decisions.
For white-label work, also agree on communication boundaries, staging access and handover expectations. Everyone should know who speaks to the client and how feedback reaches the build team.
If you are briefing work for a client, our agency partnership approach explains the communication and delivery boundaries to agree upfront.
Agree on what finished means.
A page looking good in a presentation is only one checkpoint. Your brief should also identify the journeys to test, the content to approve and the access your team needs after launch.
Use the brief as a working agreement. When the scope changes, update the decisions and their effect on delivery. That gives design and development a shared direction throughout the project.
Turn your definition of done into a review plan with the website launch checklist.
Frequently asked questions.
Do I need a finished brief before getting in touch?
No. Start with your business, the problem you want to solve and any constraints you already know. We can use the first conversation to identify the missing decisions.
Should I choose WordPress or Shopify before writing the brief?
Describe what visitors and your team need to do first. Product management, checkout, publishing and integrations help determine which platform fits. A platform preference is useful context, but the requirements should lead the decision.
What if my content and project photography are not ready?
List what exists, what needs creating and who is responsible for each item. Share a few representative examples early so the layout can account for real content rather than placeholder text.
How detailed should the budget and deadline be?
An intended budget range and a target launch date are useful starting points. Explain whether the date is tied to an event or commitment, and identify any scope that could be delivered later.
Put the thinking to work.
Tell us about your website, your next project or the problem you need to solve.
Start a conversation