What to know before developing a website

Start with the business outcome

“We need a modern website” does not explain what should change after launch. First define the result: qualified enquiries, online sales, clearer service information, fewer support requests or a better partner workflow.

Each goal needs different journeys and measurements. An online shop depends on discovery, basket and payment. A corporate site needs a clear proposition and useful enquiries. A service portal succeeds when people can complete a task without calling a manager.

Describe the audience through real journeys

A small set of realistic journeys is more useful than dozens of abstract personas. Record:

• why the person arrives;
• what they already know;
• what may create doubt;
• which action they need to complete;
• what should happen after that action.

The answers shape navigation, page content, forms and guidance. They also reveal which content must exist before design begins.

Plan the structure before visual layouts

A sitemap exposes the full scope. For every page, define its purpose, primary user question, main action and relationship to other pages.

Avoid creating near-duplicate pages only for search phrases. A page should offer independent value and answer a specific need. Repetition increases maintenance and can make pages compete with one another in search.

Content is part of the product

Copy, photography, specifications and documents affect layout. Adding them at the end usually forces redesign and creates inconsistent pages.

Use a content matrix with an owner, format, language, approval status and review date. On a bilingual site, each translation should be a reviewed editorial version rather than an unchecked machine copy.

Choose technology for the operating model

The stack should match update frequency, integrations and team capability. A static site is effective for fast informational pages. A CMS helps editors publish regularly. A web application is appropriate for complex personalised workflows.

Decide who will update dependencies, monitor backups and respond to failures. Technology without an owner quickly becomes operational risk.

Put quality into the requirements

Performance, accessibility and security cannot be left until the final week. A useful definition of done can include:

• complete keyboard operation and visible focus states;
• logical heading order and labelled form controls;
• reliable layouts on narrow screens;
• optimised images without layout shifts;
• HTTPS, defensive headers and server-side validation;
• backups with a tested recovery process;
• canonical URLs, a sitemap and language alternates;
• error logging that avoids exposing personal data.

Domain, hosting and analytics

The company should own its domain rather than leaving it in a supplier’s account. Registrar, DNS, hosting and analytics access should be stored in a company password manager with strong multi-factor authentication.

Build analytics around decisions you intend to make. Capture only useful events and review privacy settings. Excessive trackers slow pages and increase legal and security exposure.

Launch begins the operating phase

Before publication, verify redirects from old URLs, forms, metadata, language switching and the 404 page. After launch, the team needs documentation, named owners and an update schedule.

A focused first release is usually the best foundation. It can be measured with real data and expanded without accumulating accidental features.