How to plan a website project

A website plan comes before screen design

To plan a website well, define the business goal, audience tasks, content and feature scope, team responsibilities, technical constraints and measurable acceptance criteria. The result should be a concise project brief and an organised backlog — not a collection of visual inspiration.

The plan does not have to predict every decision. It should remove the most expensive unknowns before wireframes and code exist. That way the team knows what it is creating in the first version, who supplies data and content, and how it will recognise that the website performs better than its predecessor.

1. Name the problem and business goal

“We need a modern website” is not a goal. Start with an observable problem: visitors do not understand the offer, valuable enquiries arrive by phone rather than the form, the team cannot update content independently, or the store requires orders to be re-entered manually.

Then record the desired change and how it will be measured. Example goals include:

• increasing the number of enquiries that meet sales criteria;
• reducing the time needed to find documentation or contact details;
• moving repetitive service into self-service;
• launching sales for a new group or market;
• shortening publication of a new offer from several days to an hour.

Every goal needs a baseline. Secure data from current analytics, CRM, internal search and customer conversations. Do not choose a metric merely because it is easy to read. Pageview count alone will not show whether the website attracts the right companies and helps them make a decision.

2. Describe audiences and their most important tasks

You do not need to invent a persona with a name, car and favourite coffee. You need information that affects the design: the audience's situation, knowledge, constraints, selection criteria and the task they want to complete.

For each key user type, record:

• where they arrive from and what they already know;
• the language they use to describe the problem;
• the information they need before acting;
• what creates risk or distrust;
• the typical device and conditions of use;
• what should happen after the visit.

Sources include sales conversations, support requests, search queries, usability research and behaviour on the current site. Separate customer needs from the wishes of internal stakeholders. A new section about the company's structure may matter to management, but it does not necessarily help a visitor choose a service.

3. Inventory the current website

When rebuilding, do not start from a blank page. Gather URLs, traffic, search queries, external links, content, files, forms, integrations and elements used by the team. Mark what should be retained, improved, combined or removed.

An inventory prevents the loss of valuable material and organic traffic. It also exposes technical debt: several logo versions, an unknown domain owner, a form sending data to an inactive mailbox, or an integration that nobody can test.

Before handing over access, put account ownership in order. The domain, hosting, analytics, repository, content system and licences should belong to the company, while suppliers receive individual permissions that can be revoked. Do not put passwords in the brief or a shared spreadsheet.

4. Set the first-version scope and priorities

Split requirements into user tasks, features and content. “CRM integration” is too broad; specify which data flows, in which direction, when, who handles an error and what happens when the connection is unavailable.

A simple classification helps:

Priority	Meaning	Control question
Essential	Without it, the site does not meet its main goal or a requirement.	Can the service be launched safely without it?
Important	It clearly improves the outcome, but has a workaround in the first version.	What is the cost of postponing it by one stage?
Later	An idea to verify after collecting data.	What signal will justify investment?
Out of scope	Deliberately not part of the project.	Who can reopen the decision, and when?

Recording out-of-scope items is as important as listing features. It protects the schedule from “small additions” that together become a new project.

5. Assign roles and decision rights

Even a small project needs one person on the company side accountable for the outcome. They gather information, resolve conflicting feedback and approve successive stages. They do not have to do all the work, but they cannot be a committee without an owner.

A project commonly includes these responsibilities:

• business owner — goal, budget and scope decisions;
• project lead — schedule, dependencies and information flow;
• subject-matter expert and editor — facts, content and language consistency;
• UX/UI — information architecture, journeys and visual system;
• development — technology, integrations, performance and deployment;
• SEO/analytics — visibility, URL migration and the measurement plan;
• QA — test scenarios, accessibility and acceptance criteria;
• maintenance — monitoring, updates, backups and outage response.

One person may hold several roles, but one decision should not have several equal owners. Also set feedback deadlines and a method for resolving comments. Consolidated feedback is faster than separate, conflicting comments from every department.

6. Design architecture and content together

A sitemap follows audience questions and the offer model, not the internal organisational chart. First map the essential journeys: where the user comes from, how they identify the right service, what they need to compare and what action they take.

For every planned URL, define:

• its main audience and intent;
• one job the page must do;
• its key message and required evidence;
• the content owner and delivery deadline;
• the next logical link or action;
• the way it will be evaluated after publication.

Draft real content before refining wireframes. Actual names, numbers, tables and caveats reveal problems invisible in placeholder text. The design should flex for shorter and longer versions; editing should retain the hierarchy rather than fit meaning into an arbitrary space.

7. Agree visual direction and accessibility

Collect the current logo, fonts, palette, photos, licences and brand rules. If the company has no system, establish minimum roles for typography, colour, icons and imagery. A moodboard can help name the direction, but it does not replace a design built with real content.

Put accessibility requirements in the brief, not in a final fixes list. Define the target level of conformance, keyboard support, heading structure, contrast, error messages, media alternatives and behaviour under zoom. The current W3C standard is WCAG 2.2; determine the legal scope for a specific organisation with a specialist.

8. Describe technology through requirements

Do not choose a system only because the team knows a tool's name. Technology should fit publishing frequency, permissions, integrations, performance requirements, maintenance capability and planned growth.

Include at least the following in the brief:

• who edits content and how often;
• which roles and publication approvals are needed;
• which systems exchange data with the site;
• localisation and language requirements;
• how backup, recovery and the contingency plan work;
• who monitors security, errors and service availability;
• how data can be exported and suppliers changed.

Evaluate hosting in the context of the chosen architecture and load. More important than a marketing number of “gigabytes” are stability, data region, scaling ability, monitoring, support and a tested recovery process.

9. Build the schedule from dependencies, not wishes

Break the launch date into decisions, content, design, implementation, integrations, migration, testing and fixes. Identify dependencies: you cannot approve a calculator without business rules or test sending without configuring a domain and mailbox.

The budget should cover more than building the site. Include research, editing, photography, licences, data migration, integrations, hosting, tools, testing, training and the first months of maintenance. Add a reserve for named risks that cannot yet be estimated precisely.

Instead of approving the entire project only at the end, set checkpoints: the brief, architecture, visual direction, key prototype, test version and launch readiness. Every stage should have an approver and a closed list of criteria.

10. Record acceptance criteria and the launch plan

“The website works” is not a sufficient criterion. For important features, prepare scenarios: a visitor submits a valid form, receives confirmation, the record reaches the right system and the team can handle an error. Test different devices, keyboard use, slow connections, empty data and extremely long content.

The launch plan should include the domain and DNS owner, a copy of the current version, a redirect map, analytics configuration, monitoring, people available on launch day and conditions for rolling back the change. During a migration, retain valuable URLs or redirect them to the closest equivalents; do not send everything to the home page.

Publication does not end the project. Set a stabilisation period, the way defects are reported, responsibility for content updates and the first results review. Some hypotheses can only be tested with real traffic.

What should a website brief contain?

Before sending an enquiry to a supplier, check that the document includes:

1. the problem, goal, metric and baseline;
2. audience groups and their key tasks;
3. first-version scope and deliberately excluded items;
4. a map of content, features, data and integrations;
5. available brand materials and accessibility requirements;
6. roles, decision owners and the feedback process;
7. technical, legal and organisational constraints;
8. budget, expected date and critical dependencies;
9. acceptance, migration and launch-readiness criteria;
10. the maintenance model after publication.

A good supplier will still ask questions. The difference is that the conversation begins with goals and risks rather than guessing the number of subpages. If you need to run this stage with a project team, see our digital-product design and planning. The next decisions are covered in the guide on how to create a website step by step.