How to brief a website developer: seven questions to answer.

1. What should a visitor do next?

A website can help someone request a quotation, find a product, book a conversation or place an order. Choose the most important action before discussing colours or animation. That decision influences the page structure and what information should appear first.

For an industrial supplier, the useful next step might be a product enquiry with enough detail for the sales team. A restaurant visitor might need a menu, a location or a clear route to ordering. These are different experiences, even if both projects are described as a business website.

2. Who will use it, and on which devices?

List the people who will use the public website and the staff who will maintain it. Think about language, mobile use and any accessibility needs. If a staff member needs to update products from a phone, include that in the brief rather than discovering it after an administration interface has been built.

3. What content already exists?

Gather the current site, brand assets, photography, service descriptions and product information. Mark what can be reused and what needs to be written or photographed. A design cannot resolve missing technical specifications or an outdated menu.

For a catalogue, send a representative sample containing the difficult cases as well as the simple ones. Products with multiple documents or incomplete images can reveal requirements a polished sample would miss.

4. What happens behind the enquiry?

Describe who receives an enquiry, where it is recorded and what happens next. If the website needs to connect with a CRM, ordering tool or inventory system, name the existing system and confirm whether API access is available. Include the actions the integration must support, such as creating a customer record after an enquiry, and who handles unsuccessful requests.

5. What needs to survive a migration?

Keep a list of existing URLs, important downloads, forms, analytics and domain access. A replacement should account for search traffic and incoming links. Content migration, redirects and data cleanup need time in the plan. They should not become last-minute tasks.

6. Who owns updates after launch?

Decide which content your team needs to edit and how often. A custom administration tool is useful when the workflow warrants it, but every editable feature adds design, validation and maintenance requirements. Identify the actual editor and the changes they make rather than asking for everything to be editable.

7. What is essential for the first release?

Separate launch requirements from later ideas. Include your preferred launch window, business constraints and a budget range if you have one. This makes it possible to propose a realistic first release instead of spreading the available budget across too many incomplete features.

A useful brief can be short: your business, audience, main action, content, integrations, migration needs and first-release priorities. Bring that to a developer, ask how assumptions will be confirmed, and compare proposals by what they actually include.