Artur PopovProduct designer & developer
Guide

What to prepare for a one-page website

Before a one-page website is designed, agree on your offer, who it is for and what a visitor should do. Then collect the material and write down how you will check the finished page. The brief below is free to copy; it needs no registration.

This guide covers a new page for one main offer. A catalogue, customer account or web service with several workflows needs a different scope.

Start with the visitor’s next step

“Tell people about the company” leaves the next action unclear. Choose something observable: send an enquiry, contact a specialist or follow a booking link. That decision helps determine which information and buttons belong on the page.

Before contacting a bicycle workshop, someone may need to know which bicycles it accepts, how to describe a fault and what happens after an enquiry. A list of work, limits, photographs and a contact route can answer those questions. Taking payments online is a separate requirement; a button does not make it part of the scope.

A brief you can copy

Copy the template into a document. Write “to discuss” where you do not know the answer, so the gap stays visible when the project is estimated.

1. Offer: which one service or product will this page explain?
2. Visitor: who will arrive, and what do they already know?
3. Their question: what must they learn before contacting you?
4. Action: what should they do on the page?
5. Content: which sections help them make that decision?
6. Evidence: what real work, photographs or documents exist?
7. Materials: what is ready, what is missing and who prepares it?
8. Languages: which are needed, and who checks the wording?
9. Contact route: form, direct link or booking service?
10. Delivery: where do enquiries arrive, and who checks them?
11. Domain and hosting: what exists, and who controls the accounts?
12. Limits: what is outside the first version?
13. Acceptance: how will we check content, mobile use and delivery?
14. Handover: which files, account access and instructions are needed?
15. Date: is there a reason to finish by a particular day?

Do not put passwords or secret keys in the brief. Service names and the identity of the account owner are enough to start. Access can be arranged separately.

A worked example

This is a fictional workshop used to explain the brief, not a client case study. It makes no claim about sales, testimonials or commercial work completed by the author.

Field Example answer
Offer City bicycle repairs, arranged after an enquiry
Visitor A bicycle owner who wants to describe a problem and learn the next step
Main action Send a description of the fault and an address for a reply
Questions before contact Which bicycles are accepted, which repairs are offered and what to include in an enquiry
Sections Offer, work and limits, real workshop photographs, enquiry steps, common questions and a form
Materials The owner supplies the work list and photographs; those facts are used to shape the copy and sections
Language One language; another is estimated separately
Form Name, task description and reply email; the need for each field is discussed
Delivery An email to the workshop; the owner confirms a test enquiry arrives
Outside scope Payments, parts catalogue, customer accounts and unconfirmed promises of appointment availability
Acceptance Content matches the work offered, buttons lead to the agreed action and a test enquiry arrives

The real business owner supplies the location, address, prices and opening hours. A photograph does not establish those facts, and another workshop’s details are not a substitute.

Gather the material

Your offer. Describe the result of the service, who it is for and which work you do not take on. If cost depends on inspection or scope, explain how an estimate is made.

Answers to questions. Collect what people ask before ordering. For a new service, prepare likely questions and discuss the answers without presenting assumptions as customer experience.

Photographs and examples. Label each file with what it shows and whether it may be published. An image found online does not prove your work. Use testimonials and results only when they are real and may be disclosed.

Contact details. Identify the contact route and the person who will reply. For a form, agree on its recipient and delivery checks. For an external booking service, check the current destination link.

Test the whole enquiry route

A success message is one part of the journey:

  1. Open the published page on a phone and fill in the form with ordinary test data.
  2. Check that required fields are clear and missing or invalid input is explained near the field.
  3. Submit and wait for a result. If it fails, the visitor should understand what happened and what to do next.
  4. Check the recipient’s inbox, including junk mail. Compare the message with what was entered.
  5. Confirm that the recipient can reply through the chosen contact route.
  6. Test a second press and a lost connection. Agree on how the page handles an uncertain result.

Input also needs validation on the server. Browser validation helps the visitor but does not secure server-side processing on its own; see the W3C form validation tutorial.

Domain, launch and handover

Record who controls the domain and hosting, who pays for them and which recurring costs exist. After launch, you should know where the source code lives, which services are connected and how to update contact details.

Agree on what counts as a correction within the original scope and what starts a new task: another language, section, payment flow or integration. That leaves a concrete list to check at handover.

Before-launch checklist

Publishing does not mean immediate inclusion in search. Google explains discovery and indexing in its SEO Starter Guide; inclusion dates and rankings are not guaranteed.

Even a partly completed brief is a useful starting point for discussing one-page website development. It makes the scope, missing material and estimation questions easier to identify.