Website projects
Prepare a useful brief for your web designer
Anchor it to one page and one visitor task, with evidence your designer can inspect.

Start your website brief with the page that needs work. Paste its address, describe what a visitor should be able to do there, and record what gets in the way. Then add the materials and decisions your designer will need to fix it. Use that page and task as the starting point for the scope and the finished-work review.
Give the designer something to inspect
Replace a request like "make the site clearer" with a page, a task, and evidence. The published Superior Duct Cleaning case study gives a concrete example: the archived Dryer Vent section repeated the general indoor-air copy used next to it, and the rebuild separates air duct, dryer vent, and HVAC sanitizing into their own pages. That is a content change, and the case study does not establish a measured sales result. Superior Duct Cleaning case study
For your own brief, capture a dated screenshot or a short note about the page you want reviewed, and name the decision a visitor needs to make. If an idea is untested, label it as an assumption so the designer can tell it apart from something you have observed.
GOV.UK guidance treats opinions that do not come from users as assumptions to prove through research, and recommends learning from existing evidence, real or likely users, and the people who work with them. The guidance is written for government services; adapt the principle to your business. Learning about users and their needs
Describe the first version you need
List the customer tasks the first version must support and put them in order. Write the action and the destination for each one: finding a service's scope, reaching the correct enquiry route, or reading preparation instructions. Name the task that takes priority when time is limited.
Separate required work from ideas you want priced as options, and list the pages and services that must stay available during the project. If you are keeping an existing booking tool, state that constraint and name the person who can explain how it is set up. Ask the designer to flag any proposed feature that depends on information or access you have not supplied.
The same government-service manual's discovery guidance says you need to understand the problem and constraints before committing to a build, and that stopping after discovery can be a good result. The useful part for a small business is making those limits visible before you agree on the work. How discovery works
Gather the material and mark what is missing
Create one folder for approved logos, photos, and current copy. Link to it and note which material can be published. Mark draft descriptions and unconfirmed service details, then name the person who will supply each missing item and agree a date for it.
A reference site can help if you link the exact page and explain the feature you mean, whether that is the way a service is explained or where the practical information sits. Keep visual preferences separate from facts about your business, and supply assets you have permission to use.
List the systems involved in the website and who controls access to them. Keep passwords out of the brief and arrange access separately. For a first conversation, the designer needs to know who can help with the domain, hosting, and any connected service.
Make the next decision possible
State the budget range you want the designer to work within, the desired launch date, and any fixed event behind it. Distinguish a preferred date from a dependency that cannot move. Name who approves the scope and who will pull together the design feedback.
Finish with a review task tied to your opening problem. Write down what you and the designer will check on the proposed page. For a service enquiry, that could mean finding the service details, following the enquiry link, and confirming that it reaches the agreed destination.
Send the brief with a short list of open questions. Ask the designer to name missing inputs, assumptions, and work outside the proposed scope before estimating. Keep their answers beside the brief and date the agreed version, so the same decisions are available when you review the design.