1. Choose the job your website must do
Write down who is visiting, what they need to understand, and what they should do next. For a service business, that might be requesting an estimate. A restaurant might need visitors to read its current menu. These are different page priorities, even if both businesses want more customers.
Choose one primary action for the first version. “Request an estimate” needs a working enquiry destination and someone responsible for replying. “Book now” needs a real booking service, the right appointment type, and available times—not just a button with that label.
2. Supply facts a customer can rely on
Collect the business name, public contact details, service area, current services, and opening hours if relevant. Say which information is approved and which needs checking. For a rebuild, list the existing pages and destinations you want to keep, including menu, booking, and product links.
Describe what makes the offer specific: what is included, who it is for, and what happens after an enquiry. Provide evidence before using awards, credentials, testimonials, or performance claims. Do not ask the designer to invent these to fill space.
3. Plan pages around decisions, not word counts
A useful first brief lists each page’s purpose. A home page explains the offer and next step; a service page answers scope questions; a contact page explains how and where to reach you. Only add pages you can supply with distinct, useful content.
For each page, name its owner and mark the copy as ready, needs editing, or missing. Separate launch essentials from later additions. A shop catalogue, booking workflow, and member area each add functional scope; they are not simply extra headings on a brochure site.
4. Gather visuals with a clear role
Supply a usable logo and a small set of approved images: the place, the team, the product, or the work itself. Explain what each image shows and where it can be used. Keep a record of permission for identifiable people and third-party assets.
For the main image, choose a subject that explains the business even when cropped on a phone. If original photography is missing, flag that gap before approving a design that depends on it. A placeholder is a design aid, not proof of your team, premises, or completed work.
5. Specify integrations as working handoffs
“Connect booking” is not a complete instruction. Name the booking provider, the service to book, who controls the account, and what confirmation the customer should receive. For a form, identify the destination inbox or CRM and who will check that a test enquiry actually arrives.
Corpus’s custom-build intake offers booking, payments, lead forms/CRM, and analytics categories, plus notes. Use those notes to explain the required workflow and existing providers. Selecting a category records a request; it does not mean an integration is already connected or that every provider is included. Confirm scope before proceeding with the paid build.
A worked brief: a local bicycle workshop
This fictional example shows the level of detail to aim for. Replace every detail with your own facts before using it.
Business: Example Cycle Workshop, a local bicycle service business.
Audience and action: Nearby riders who want to ask about a service. Primary action: request an appointment, not instant booking.
Content: Explain the offered services, how enquiries are handled, and where to find the workshop. Service list, address, hours, and response expectations are all to confirm.
Visuals: Approved workshop exterior and team-at-work photos. Permission and final image selection are to confirm.
Function: Enquiry form with service type and contact details. Destination inbox and responsible person are to confirm. No online payment required in the first version.
Launch approval: Owner checks facts, phone layout, contact links, and receipt of a test enquiry before approving launch. Domain account owner is to confirm.
6. Separate the prototype from the launch
In Studio, the owner path starts with a name and business description. The result offers visual directions and editable business content. Use that stage to check hierarchy, factual accuracy, and the overall direction—not to assume that a form, booking service, payment flow, or custom domain is live.
Before launch, agree who approves the final copy and scope, who controls the domain, and who will maintain the site. Verify phone layouts, keyboard access, contact links, form delivery, and any agreed booking or payment workflow. Confirm existing domain email will be preserved when launch settings change.
The custom-build handoff is a separate step from generating the prototype. Review its current scope and price before checkout. A visual preview is not a completed custom website.
Have a name and an offer? Start there.
Enter your real business name and description in Studio’s owner form. Keep this checklist for the facts, assets, and integration decisions you will need next.
Create your website prototype →Planning a service video too? Use the service-business shot-list guide to make its final invitation match your website’s next step.