Sample editorial content. This article gives general guidance only. It is not professional, legal, tax or financial advice and contains no original research.
A website project that runs late or disappoints rarely fails because of the code. It fails because key questions were left unanswered: what the site is for, who will provide the content, who will approve it and what happens after launch. Each unanswered question reappears during the build as a delay or an argument.
Time spent planning is the cheapest part of the project. This guide covers the decisions worth settling before design and development begin, whether you are working with an agency, a freelancer or an internal team.
Start with purpose
State in a sentence or two what the website must achieve for the business. Examples include generating enquiries for a service, allowing customers to order products, or giving existing clients a place to find documents. A site can serve several aims, but ranking them helps you make trade-offs later.
Then describe the main visitors and what each one wants to do. A prospective customer, a job applicant and a supplier will look for different things. Mapping these journeys early tells you which pages the site actually needs.
Take stock of what exists
If you already have a site, review it honestly. Which pages are visited, which are outdated, and which address real customer questions? Check whether you control the domain name, hosting and any existing content, and who holds the logins. These practical details are surprisingly common sources of delay.
Plan the structure and content together
A common mistake is to design the pages first and fill in words later. Content shapes layout, and not the other way round. Draft a simple page list and a short outline of what each page needs to say. Decide who will write it, who will supply images and who will approve each page.
Questions to answer for each page
- What question is this page answering for the visitor?
- What should the visitor do next?
- What text, images or documents are needed, and who is providing them?
- How will we know when it is finished and approved?
Imagine a small physiotherapy clinic planning a new site. Its pages might cover each treatment area, the practitioners, fees and appointment process, and directions. Writing those honestly in advance reveals gaps, such as missing practitioner photographs, while there is still time to arrange them.
Decide on features deliberately
Every feature adds cost, testing and maintenance. Online booking, payment, member areas and live chat can be valuable, but only if they serve the purpose you set. List features as must-have for launch, desirable later or not needed. A leaner launch followed by improvements is usually healthier than an overloaded first version.
Think about search and speed from the start
Whether people find the site and whether it loads promptly are design decisions, not afterthoughts. Clear page titles, sensible headings, descriptive text and mobile-friendly layouts help both visitors and search engines. Large uncompressed images and unnecessary scripts slow pages down. Ask your developer how these will be handled.
Set a realistic budget and timeline
Costs depend on the number of pages, the amount of custom design, the features and who creates the content. Ask for a written scope that itemises what is included, how many rounds of revision are allowed and how extra requests are priced. Timelines tend to slip because of slow feedback, so allocate time on your side for reviewing drafts and supplying material.
- Agree the goals, audience and page list.
- Collect brand assets, images and draft content.
- Approve the design direction before the full build.
- Build, then review on phones, tablets and desktop screens.
- Test forms, links and any integrations, and check privacy wording.
- Launch, then monitor for problems in the first weeks.
Plan the handover and the after-life
Launch is the beginning of the site's working life. Settle who updates content, who handles security updates and backups, and who answers if something breaks. Ask for basic training so your team can edit routine content without calling a developer each time. Ensure you receive the logins, source files and documentation you are entitled to.
- Hosting, domain and security updates have a named owner.
- Backups exist and can be restored.
- There is a schedule for reviewing content for accuracy.
- Enquiries from forms reach a monitored inbox and receive timely replies.
Where to start
Write the purpose of the site in two sentences, list your main visitors, and sketch the page list with a note beside each page on who will supply the content. Confirm that you control your domain and hosting. With that one-page brief in hand, conversations with any developer become sharper, quotations become comparable and the project is far more likely to land on time.