A web project often starts with the sentence: “We need a new website.” Soon the conversation turns to the CMS, template, colours and launch date. It still is not clear what the new website should change.
That is an expensive mistake. Technology can very quickly produce something the company does not need.
First write down which decision the website should support
I do not start with a page list. I start with the situation of the company and visitor. Should the site bring qualified enquiries, shorten sales explanations, sell without a person, reduce support work or move the brand into another category?
The goal must lead to a decision. “A more modern presentation” is a wish. “More relevant enquiries from manufacturing companies and fewer questions about one-off small jobs” already lets you decide on content, navigation and measurement.
- Who matters to the website and in what situation do they arrive?
- What do they need to understand, compare or do?
- What evidence can the company honestly show?
- What next step suits their readiness?
- How will we recognise improvement after launch?
The content map comes before the wireframe
Only then do I assemble the information architecture. Main navigation should not copy the company's organisational structure. It should help people find an answer and understand the offering.
For an existing site, I first inventory URLs, traffic, links and actual content. I preserve some pages, merge, redirect or remove others. Migration must not be based on impressions. An unattractive page may have good links or bring relevant business; a highly visited page may attract people entirely outside the business.
For SEO, clear structure, linking and content for a real audience matter. Google summarises its questions about usefulness in the guide to people-first content. A practical SEO foundation is also in my SEO for beginners article.
A prototype should verify the journey, not impress the meeting
First I draw key journeys without detailed design. Can a person understand who the company is for? Can they find a service, evidence, price or contact method? Does the journey work on a narrow mobile screen and with only a keyboard?
I put real headings and approximately real text lengths into the prototype. Lorem ipsum hides a problem that magically reappears after content is delivered—usually on the Friday before launch.
Choose technology according to operation
A static site, WordPress, an ecommerce platform or a custom application can all be right. What matters is the required editing, integrations, permissions, speed of change, security, budget and the people who will manage the site after launch.
The brief should include at least:
- ownership of the domain, accounts, source code and analytics;
- editorial roles and the publishing process;
- forms, email delivery and connection to sales;
- redirects for old URLs and a custom error page;
- backups, updates, monitoring and incident responsibility;
- an operating budget, not only a production budget.
Speed and accessibility are not polish added at the end
A large image, external fonts and ten marketing scripts are easy to add. Every visitor then pays their cost. Core Web Vitals track main-content loading, responsiveness and visual stability; Google maintains current metrics and thresholds in its Web Vitals documentation.
I therefore set a performance budget before design: media dimensions and formats, number of font cuts, third-party script rules and target behaviour on an ordinary mobile. Analytics should load without blocking content and collect only data that supports decisions.
I address accessibility at the same time: semantic HTML, visible focus, keyboard operation, contrast, form labels and respect for reduced motion. This is not a special version of a website. It is a well-built website.
Design measurement before launch
After launch I do not want to debate what success means. I list events and their connection to decisions: a qualified enquiry sent, calculator used, key evidence opened or order completed. Not every click deserves an event.
Technical measurement is covered in the Google Analytics 4 guide. A broader checklist is in the online project checklist.
A website is not finished at launch
During the first weeks I monitor errors, speed, indexing, forms and real questions from people. Then I improve places where the website does not help a decision. Not after every comment or one metric, but according to a combination of data, feedback and business impact.
A new website is not the goal. It is a new operating system for the company. Without an owner, budget and change rules, it starts ageing on launch day.
If you already have a website and need to find weak points, start with How to speed up a website. If you need to align decisions before production, see how collaboration works.