A practical guide to planning a public sector website project

Why a structured approach matters

For public sector organisations, a website project is rarely just a website project. It is usually tied to service delivery, compliance, public trust, accessibility, procurement rules and internal governance. Decision-makers are often asked to approve budgets, set priorities and manage risk without needing to get into technical detail. That is exactly why a structured approach is useful.

A good public sector website does not begin with design mock-ups or a list of features. It begins with a clear understanding of what the organisation needs the website to do, who it is for and what constraints must be respected. From there, the project can move through vendor selection, design, content planning, testing and launch in a way that is practical and accountable.

This guide sets out those stages in plain terms for leaders, managers and procurement stakeholders. It is intended to help decision-makers ask the right questions, avoid common mistakes and create the conditions for a successful delivery.

1. Needs analysis: define the problem before the solution

The most common cause of difficulty in website projects is not poor technology. It is unclear objectives. If the organisation cannot explain what the new website is meant to achieve, every later decision becomes harder: budget, procurement, scope, design and content all become open to interpretation.

A needs analysis should establish a shared understanding of the current situation and the desired outcome. This does not need to be overly technical. It should focus on services, users, risks and organisational priorities.

Start with the purpose

Decision-makers should be able to answer a few basic questions clearly:

  • Why is a new website or redevelopment needed now? For example, the current site may be outdated, inaccessible, difficult to maintain, fragmented across departments or unable to support digital services.
  • What should improve as a result? This might include easier access to information, fewer phone enquiries, better completion of online tasks, stronger accessibility compliance or simpler content management.
  • What does success look like? Success measures should be practical and observable, such as reduced publishing time, improved user satisfaction, increased uptake of digital services or fewer abandoned forms.

Understand your users

Public sector websites usually serve a wide range of audiences: residents, businesses, partner organisations, elected representatives, journalists and internal staff. It is important not to treat these groups as a single generic audience.

At this stage, the aim is not to produce detailed technical user research outputs. It is to understand which groups matter most, what they come to the website to do and where they currently struggle. Useful evidence can come from service teams, analytics, search logs, contact centre feedback, complaints, accessibility reviews and stakeholder interviews.

Decision-makers should ask:

  • Which tasks are most important to users?
  • Which services generate the highest demand or the most confusion?
  • Where are users dropping out, calling for help or submitting avoidable enquiries?
  • What barriers exist for people using assistive technologies, mobile devices or low-bandwidth connections?

Audit the current estate

Many organisations underestimate the scale of what they already have. Before planning a replacement, review the current website and related digital estate. This includes content volumes, document libraries, forms, microsites, integrations and publishing workflows.

A simple audit should identify:

  • Outdated, duplicated or low-value content
  • Critical user journeys and service pages
  • Systems the website depends on, such as CRM, payments, forms or case management tools
  • Governance issues, such as too many publishers or unclear ownership
  • Compliance gaps, especially accessibility, privacy and records management

This stage often reveals that the problem is not only the platform. It may also involve content sprawl, weak governance or fragmented service ownership.

Set scope and constraints

Once needs are clearer, define the broad scope. Decision-makers do not need to specify every feature, but they should agree the boundaries of the project. For example: is this a full website replacement, a redesign of key sections, a migration to a new content management system, or a broader service improvement programme?

Constraints should also be explicit from the start:

  • Budget
  • Timescales, including political or operational deadlines
  • Procurement requirements
  • Accessibility and legal obligations
  • Internal capacity for content, approvals and ongoing maintenance

Clarity here makes later procurement and delivery far more realistic.

2. Vendor selection: choose for fit, not just price

Once the organisation understands its needs, it can approach the market more effectively. Vendor selection in the public sector must of course follow procurement rules, but good outcomes still depend on how requirements are framed and how suppliers are assessed.

A frequent mistake is to procure on the basis of a vague ambition such as “modern, user-friendly website” and then compare suppliers mainly on price. That approach often produces inconsistent bids and weak accountability. A better approach is to define the outcomes, the required capabilities and the evaluation criteria in practical terms.

Write a clear brief

The brief should explain the organisation, the context, the main objectives, the expected scope and the constraints. It should also make clear what the supplier is expected to do and what the organisation will provide internally.

A useful brief normally includes:

  • Project background and drivers
  • Target audiences and priority user tasks
  • Current challenges with the existing website
  • Required services, such as discovery, design, build, migration, accessibility support, testing and training
  • Technical or policy constraints
  • Indicative budget and timetable, where appropriate
  • Evaluation criteria and procurement process

Well-written briefs tend to produce better responses and reduce confusion later.

Assess relevant experience

Not all digital agencies are suited to public sector work. Decision-makers should look for suppliers that understand accessibility, governance, procurement realities and the complexity of public information. Experience with service-led, content-heavy and compliance-sensitive websites is usually more valuable than glossy visual portfolios.

Ask suppliers to demonstrate:

  • Experience delivering for public sector or similarly regulated organisations
  • Approach to accessibility and inclusive design
  • Ability to handle content strategy and migration, not just visual design
  • Project governance and risk management methods
  • Training and support for internal teams after launch

Look at how they work

For decision-makers, the supplier’s working style matters as much as the final output. A good vendor should be able to explain its process in a way that gives confidence: how decisions will be made, how risks will be escalated, how progress will be reported and how user needs will be reflected throughout the project.

It is worth testing whether the supplier can communicate clearly with non-technical stakeholders. If explanations are overly technical or vague during procurement, that may continue during delivery.

Do not separate delivery from ownership

A website cannot simply be handed over at the end like a finished brochure. The organisation will need to govern, maintain and improve it. Choose a vendor that recognises this and plans for internal capability, not just launch day.

3. Design: focus on clarity, structure and usability

For decision-makers, “design” is often assumed to mean colours, branding and page layouts. In practice, good website design for the public sector is primarily about helping people find what they need and complete tasks with minimal friction.

Prioritise structure before appearance

Before discussing visual direction, make sure the website structure is sensible. Navigation, page hierarchy and search all have a major impact on usability. If the structure reflects internal departments rather than public needs, users will struggle regardless of how polished the interface looks.

Key questions include:

  • Can users quickly identify where to start?
  • Are the most important services easy to reach?
  • Does the navigation use plain language?
  • Are pages designed around tasks and questions rather than organisational charts?

Accessibility is a design requirement, not an add-on

Accessibility should be built into decisions from the outset. It is not a final compliance check. Design choices affect readability, navigation, form completion and compatibility with assistive technologies. Decision-makers should expect accessibility to shape the project from discovery to testing.

This includes colour contrast, text sizing, keyboard navigation, form labels, heading structure and content patterns. It also includes broader usability for people with cognitive impairments, limited digital confidence or temporary constraints such as poor connectivity.

Keep branding in proportion

Brand identity matters, especially for public trust and consistency. But branding should support usability, not compete with it. Overly bespoke interfaces can make websites harder to use and maintain. In many public sector contexts, a clean, familiar and restrained design is more effective than a highly stylised one.

4. Content: the part most organisations underestimate

Content is often the largest and most difficult part of a website project. Yet it is frequently treated as something to tidy up near the end. For public sector organisations, this is a mistake. Content determines whether users can understand services, meet requirements and take action confidently.

Treat content as a workstream

Decision-makers should ensure content has clear ownership, time allocation and governance. If no one is responsible for reviewing, rewriting, approving and migrating content, delays are almost inevitable.

Content work usually includes:

  • Audit and prioritisation
  • Removal of outdated or duplicate material
  • Rewriting in plain English
  • Structuring content for the new website
  • Assigning ownership for future maintenance

Reduce before you migrate

Most organisations should publish less, not more. Legacy websites often contain years of accumulated pages, PDFs and notices that no longer serve users. Migrating everything into a new platform simply transfers the problem.

Ask a simple question of each content type: does this help a user complete a task, understand a service or meet a genuine need? If not, it may not belong on the new site.

Use plain language and clear accountability

Public sector content should be accurate, but accuracy does not require complexity. Plain language improves comprehension and reduces avoidable contact. It also supports accessibility.

Each important section should have a named owner responsible for keeping it current. Without this, websites quickly decline after launch.

5. Testing: reduce risk before the public sees it

Testing is where assumptions are checked. It should cover more than technical defects. A website can function correctly in a narrow technical sense and still fail users.

Test with real tasks in mind

Decision-makers should ask whether testing reflects actual user behaviour. Can people find information, complete forms, understand eligibility criteria and move between pages without confusion? Testing should focus on priority tasks, not only page templates.

Include accessibility and content checks

Accessibility testing should involve both automated and manual review. Content should also be checked for clarity, consistency and legal accuracy. Broken links, outdated documents and unclear calls to action can undermine confidence even if the platform itself is stable.

Plan for internal acceptance

Internal stakeholders need an organised way to review and sign off the website. Without a clear acceptance process, feedback can become fragmented and late-stage changes can create delay. Decision-makers should ensure that sign-off responsibilities are agreed early.

6. Launch: treat it as the start of a new operating model

Launch is important, but it should not be treated as the finish line. A public sector website needs active management after go-live: monitoring, content updates, issue resolution and continuous improvement.

Prepare for transition

Before launch, make sure the organisation is ready to operate the new website. This includes:

  • Training for editors and administrators
  • Support arrangements with the vendor
  • Clear governance and publishing workflows
  • Analytics and performance monitoring
  • A plan for handling post-launch issues

Communicate change sensibly

Not every launch needs a major publicity campaign. What matters is that users are not disrupted and staff know what has changed. If key journeys, URLs or processes are different, those changes should be communicated clearly to both internal teams and external audiences.

Measure what matters

After launch, return to the success measures defined at the start. Are users completing key tasks more easily? Has avoidable contact reduced? Are editors able to maintain content efficiently? Is the organisation in a better compliance position?

These questions matter more than whether the launch happened on a particular date.

Final thoughts for decision-makers

A successful public sector website project is not driven by technology alone. It depends on clear objectives, realistic scope, strong procurement, disciplined content work and a willingness to make decisions based on user needs rather than internal habits.

For decision-makers, the key role is not to manage technical details. It is to create clarity, set priorities, ensure proper governance and ask the right questions at the right time. If those foundations are in place, the project is far more likely to deliver a website that is useful, maintainable and fit for public service.

In practical terms, that means approaching the work in six connected stages: needs analysis, vendor selection, design, content, testing and launch. Each one reduces uncertainty and improves the quality of the final result. Skipping or compressing any of them usually creates cost and risk later.

For public sector organisations, a website is part of service delivery. Treating it with that level of seriousness is the most reliable route to a better outcome.

lt