Website planning guide

How to build a website project brief before hiring a developer

A useful brief does not prescribe a layout. It gives a developer enough product context to recommend the right page structure, expose missing inputs, and estimate a defined outcome.

Start with the business decision

The page exists to help a specific visitor make a specific next decision. Define that decision before listing sections, animations, or technical preferences.

Name one audience

Describe the buyer or user in operational terms: their situation, urgency, and what they already understand.

Name one primary action

Choose the action the site should make easier: enquire, book, apply, buy, join a waitlist, or understand a complex offer.

Define the launch decision

State what the first release needs to prove — for example, whether the offer is understood well enough to generate qualified enquiries.

Separate inputs from design decisions

Supply the evidence and constraints that only you know. Leave information architecture, component choices, and responsive behaviour open for the delivery team to solve.

Inputs you own

Offer details, audience knowledge, proof, legal requirements, brand assets, access, deadlines, and the person who approves the work.

Decisions to make together

Page count, content order, interaction model, CMS needs, analytics events, technical stack, and the smallest credible launch scope.

Unknowns to expose

Mark assumptions explicitly. An unknown is safer in the brief than hidden inside an estimate as an untested expectation.

Website brief worksheet

Write one or two concrete sentences for each row. If a row is unknown, label it as an open question instead of filling it with a guess.

Offer: What is being offered, to whom, and why would they choose it now?
Primary visitor: What situation brings this person to the site and what do they need to understand first?
Primary action: What single action should become easier after reading the page?
Proof: Which public examples, outcomes, credentials, process details, or product evidence can support the claims?
Content inputs: Which copy, images, brand assets, legal text, and product information already exist?
Constraints: Record the real deadline, languages, integrations, approval process, accessibility needs, and budget range.
Launch test: What observable result will tell you that the first version is useful enough to keep or extend?

Choose the likely website shape

One audience, one offer, one primary action

Start by testing whether a focused landing page can carry the decision.

Several distinct services or audience paths

Plan a compact multi-page site with a clear page for each search and buying intent.

Content changes frequently across many entries

Treat a CMS and content model as part of the scope, not as a late implementation detail.

Turn the worksheet into a delivery scope

The guide is a planning aid, not an estimate. The related service page explains the normal deliverables, process, and baseline boundaries for this kind of engagement.

Explore website development →

Discuss a similar project

Describe the problem, current situation, and outcome you need. I will suggest a sensible first step.

Send a project enquiry