A useful website brief explains the business problem before it lists pages or visual references. These questions help your team make better decisions before design begins.
Choose the action the website should help a relevant visitor take: request a quote, book a conversation, buy a product or understand a service. Secondary actions can support the journey, but treating every page as equally important makes prioritization difficult. Write down how the current experience fails and what evidence would indicate an improvement.
List the people using the site and what they need to know. A first-time buyer may need an explanation of fit and process. A returning customer may need support or documentation. A procurement team may need evidence, scope and contact details. Group pages around those tasks rather than simply mirroring your internal organization.
Gather approved service descriptions, product information, original images, team details, policies and genuine proof. Identify who can review technical and commercial claims. Where content is missing, make it part of the scope. A beautiful layout cannot compensate for unclear offers or unverified claims.
Write essential features, integrations and content-management needs separately from visual preferences. Record existing URLs if search visibility matters. Confirm who owns the domain, hosting and third-party accounts without sharing passwords in the brief. This helps the implementation team assess dependencies and migration risk.
Agree who approves the work, who updates content and what support is required after launch. Budget for accessibility checks, mobile review, form testing and redirects. After release, review actual customer questions and key actions before commissioning more features. Explore our web development approach.
Write the business objective, audience, primary action and current problem in plain language. Add the known constraints: deadline, budget range, existing systems and approval responsibilities. This summary helps everyone check whether they are solving the same problem before discussing layouts or technology.
Gather current URLs, approved copy, product or service information and assets you have permission to use. Label references with what you like about them. A navigation example and a visual reference may serve different purposes; explaining that distinction helps the designer make better decisions.
List the pages and interactions that must work on day one. Include forms, direct links, mobile navigation, policy pages and any redirects from the existing website. Assign an owner for final content approval and for the platform after launch. A website brief is useful when it supports decisions throughout delivery, not only when it starts the quotation process.
The platform decision is easier once you know who will maintain the website and what visitors need to do. A brochure-style service website, a publishing operation and a customer portal do not necessarily need the same architecture. Compare the ongoing editing experience, integrations, maintenance work and hosting responsibilities alongside the initial development quote.
A CMS is worth assessing when non-technical staff regularly publish articles, change services or build campaign pages. Before choosing it, ask the developer to demonstrate the actual editing tasks your team will perform. Confirm which components can be reused, which changes need technical help and who is responsible for updates and backups. WordPress development is one route; it should be evaluated against your requirements rather than chosen by habit.
A customer portal with accounts, permissions and operational data involves more than adding a login button. Document user roles, permitted actions, data sources and recovery steps. A custom React interface can be considered where the experience benefits from it, but authentication, storage and access controls still require an appropriate backend. Explore custom portals and integrations before treating these features as ordinary marketing pages.
A lower headline price can reflect a smaller scope rather than better value. Ask each provider to state which pages, content, design rounds, integrations and launch checks are included. Separate initial implementation from ongoing hosting, software subscriptions and support. If one quote includes copywriting and another expects finished copy from you, they are not pricing the same work.
A useful comparison also records exclusions. Who migrates existing articles? Are redirects included? Does the quote cover a real enquiry-delivery integration or just a form interface? Who supplies imagery and confirms usage rights? Ask for these answers in writing before approving production. An estimate becomes more meaningful when both sides can identify what would count as a change request.
This is a planning example, not a client case study. Imagine a logistics company whose enquiries often omit the shipment type and destination. Its primary requirement might be clearer service information and a more complete quotation request, rather than a customer app. The first release could include a services overview, individual transport services, actual coverage details, an about page and a short enquiry journey.
A useful acceptance condition would be that a visitor can identify a suitable service and send the agreed shipment information from a phone. Another would be that the responsible employee receives the request through the agreed channel. Track the proportion of usable enquiries after launch rather than claiming the design will automatically increase revenue. See the related logistics and fleet website approach for more planning considerations.
Check the approved service descriptions, contact details, key policies and every primary call to action. Open important pages directly, not only by navigating from the homepage. If this is a redesign, compare the previous URL list with the new structure and decide where each useful old destination should lead. A missing page should produce an appropriate not-found response instead of silently displaying unrelated homepage content.
Review the site with a keyboard and at narrow viewport widths. Check visible focus, form labels, error messages and useful image descriptions where images carry information. Test the actual enquiry flow from submission to receipt, including its failure path. Accessibility is a continuing design and development responsibility; a single automated scan is not a complete review. The W3C accessibility planning guidance provides a useful framework for assigning that responsibility.
Confirm that important content is accessible, each page has a useful title and canonical URL, and the sitemap lists the intended public pages. Keep ownership of domain, hosting and third-party accounts clear. Record who can publish content, restore a backup and respond to a failed form. Use the search-ready website guide to plan this part of the launch.
There is no useful universal price without knowing the scope. Content volume, design requirements, integrations, migration and ongoing responsibilities affect the estimate. Start with a shared brief and compare like-for-like proposals. Request a scoped estimate when you can describe the intended audience and essential outcome.
Not automatically. Begin with the tasks users need to complete and how often they repeat them. A responsive website may meet a discovery or enquiry need. Device capabilities, distribution requirements or repeated authenticated workflows may justify a separate mobile app scope.
Bring a short description of the business, current website if any, audience, main problem, required launch date and known constraints. Label references with what is useful about them. You can discuss uncertainty during discovery; a finished technical specification is not required to begin.
Services · Projects · Support
Explore our services, plan a project, or ask a question. Your next step starts here.
