Before choosing a layout or requesting a quote, write down the problem your website needs to solve. A business may need clearer service information, a more dependable enquiry process or a way to show its previous work. Those are different priorities, and they lead to different decisions.
Start with the questions below. Keep the answers specific enough that your team and your developer can use them to decide whether a proposed feature belongs in the project.
1. Define one primary business goal
Choose the most important action for a visitor: requesting a quote, booking a consultation, purchasing a product or contacting the team. Identify the pages that should support that action. Secondary goals can still matter, but making everything equally prominent can leave visitors unsure where to start.
Describe how you will recognise a useful enquiry. For example, a service business might need a visitor's name, preferred contact method, required service and a short project description. Agree which details are essential and which can wait for a conversation.
2. Describe your customers and their questions
List the people you want to reach, the locations you serve and the questions they ask before choosing a provider. Include the information that helps them decide whether you are a good fit, such as service scope, process, availability and how to request pricing.
Use real questions from customer conversations where possible. A page that answers a specific concern is more useful than a broad claim that your business offers the best service.
3. Separate what must stay from what needs to change
If you already have a website, specify the parts you want to preserve. That can include the logo, homepage design, colours, fonts, animations, page addresses and existing content. Mark the requested changes separately so a small improvement does not accidentally become a redesign.
A practical brief for an existing site
“Keep the current homepage layout, logo and animation styles. Add individual service pages and connect them to the existing menu. Update the footer links. Preserve all other page content.”
Attach source files when you have them, along with screenshots of the relevant areas. Screenshots show appearance; source files show how the website is built. Both help, but they serve different purposes.
4. List the pages, content and features
| Area | What to specify |
|---|---|
| Pages | Required pages, their purpose and how visitors reach them. |
| Content | Who provides and approves the copy, images and service details. |
| Enquiries | Required form fields, the recipient and the confirmation visitors should receive. |
| Portfolio | Approved projects, accurate descriptions and permission to display the work. |
| Editing | Who will update the site and whether they need a publishing dashboard. |
| Launch | Hosting access, backup arrangements, checks and responsibility for publishing. |
Keep essential launch features separate from future ideas. A focused first release is easier to review than a brief that mixes the immediate requirements with every feature the business may eventually need.
5. Decide how future updates will happen
Explain whether you want to edit through a content management system or are comfortable uploading revised files. Ask the developer to demonstrate how you will publish a blog post, replace an image and update contact details using the chosen approach.
This choice affects the implementation. A site built from static files does not automatically include an administration dashboard. If a dashboard matters to your team, write that requirement into the brief before development starts.
6. Agree on the handover and acceptance checks
Specify the files and access you expect at handover. Include the website files, asset dependencies, publishing instructions and a record of any settings that still require your input. For an existing site, ask for a backup and a clear description of what changed.
- Open every menu link on a phone and a desktop.
- Check that the logo, images and approved content display correctly.
- Submit a controlled test enquiry and confirm it reaches the intended recipient.
- Confirm that essential buttons can be reached and used with a keyboard.
- Review the mobile layout and the steps needed to publish future updates.
Give each check an owner. A form that looks complete still needs its delivery settings verified, and a website that works in a preview still needs to be checked on its actual hosting.
Turn the brief into a manageable next step
Share the completed brief before requesting a final scope and estimate. If something is uncertain, record it as a decision to resolve rather than allowing it to become an assumption. For help planning the build, explore our website design and development service or contact AKW Brains with your current website and priorities.