A Website Is Not a Service: What Government and Healthcare Organisations Need to Design Differently

Public services have fundamentally different demands than marketing websites. Explore how human-centred service design, rigorous accessibility standards, and end-to-end user journeys transform civic and healthcare experiences.

A government or healthcare website can look modern, polished and technically impressive and still deliver a poor service. That may sound slightly harsh, but it is an important distinction. When someone visits a commercial website, they might be comparing products, reading about a company or deciding whether to make an enquiry. If the experience is frustrating, they may simply leave and go somewhere else. Public services are different. People often arrive because they need something important, sometimes urgently, and the website is only one part of a much larger journey involving people, processes, policies, technology, organisations and physical environments.

That is why designing a government or healthcare website should not begin with the question, "What should the website look like?" A much better question is, "What service are we helping this person access, and what needs to happen for them to successfully complete their journey?" The distinction sounds subtle, but it changes almost everything. It changes what research you conduct, who you involve, what you measure, how you structure content, how you design interactions and even how you decide what belongs on the website in the first place.

At CreativeIyke, we see this as the difference between website design and service design. A website is an interface. A service is the complete experience surrounding a user's need. For government, local councils and healthcare organisations, that wider service might involve a website, an online form, a call centre, a hospital department, a council office, a GP practice, email communication, internal teams, third-party systems and decisions made by people behind the scenes. Designing only the website without understanding those connections can produce something visually excellent while leaving the underlying service just as difficult to navigate.

The Website Is Only the Front Door

Think about someone applying for a council service. They may begin with a Google search, arrive on the council website, read several pages, complete an eligibility check, start an online application, upload documents, receive an email, wait for a decision and eventually contact the council again because they are unsure what happens next. The website may technically have provided every piece of information required, but the overall service can still feel fragmented because the user's journey extends beyond the individual web pages.

The same principle applies to healthcare. A patient might search for information about a condition, find a hospital website, determine whether they need to contact a service, locate the correct department, understand referral requirements, prepare for an appointment, attend in person and then receive follow-up information through another channel. The website has an important role, but it does not own the entire experience. If the online information is clear but the appointment process is confusing, the service is still confusing. If the form is beautifully designed but the patient does not know what happens after submitting it, the service still contains friction.

This is why public-sector digital work requires a broader perspective. The website should be treated as one component within a service ecosystem rather than the entire service itself. A successful redesign therefore needs to understand what happens before a person reaches the website, what happens while they are using it and what happens after they leave it.

Service Ecosystem Architecture

Caption: The website is often one touchpoint within a much larger service journey. Good service design considers the entire experience, not just the interface.

Why Public Services Require a Different Design Mindset

Commercial digital products are usually designed around a relatively straightforward relationship between the organisation and the customer. There are certainly exceptions, but the commercial objective often involves attracting, converting, serving and retaining customers. Public services can involve considerably more complicated relationships. A council may be serving residents, businesses, visitors, vulnerable groups and internal teams simultaneously. A healthcare organisation may need to support patients, clinicians, carers, administrative staff and other healthcare professionals, each with different needs and responsibilities.

There is also an important issue of choice. A person may choose one online retailer over another, but they generally cannot choose which council provides their local services. Someone accessing a healthcare service may not have the option of simply switching provider because the experience is inconvenient. This places a greater responsibility on public organisations to make their services understandable, accessible and usable for the widest possible range of people.

The consequences of poor design can therefore extend beyond lost conversions. A confusing service can lead to missed appointments, incomplete applications, unnecessary calls, duplicated work, incorrect information, increased pressure on staff and people being unable to access something they are entitled to receive. Accessibility is not simply a compliance consideration in this environment. It is part of whether the service works at all.

Service Design Starts With the User's Need

One of the strongest principles in public-sector design is starting with the user's actual need rather than beginning with the organisation's internal structure. Organisations naturally tend to describe services through departments, policies and internal processes because that is how they are organised. Users experience none of those organisational boundaries in quite the same way. They simply have something they are trying to accomplish.

A resident does not necessarily think, "I need to access the council's waste management information architecture." They think, "I need to report that my bin hasn't been collected." A patient does not think in terms of a hospital's organisational structure. They may think, "I need to find out where I should go for this appointment," or "I need to understand what I should do before my procedure." Those differences in language and perspective matter because they influence how information should be structured and how journeys should be designed.

This is where user research becomes particularly valuable. Rather than assuming what people need based on internal knowledge, designers can observe behaviours, analyse existing journeys, speak with users and stakeholders, review support requests and identify where people encounter confusion. The resulting service can then be structured around real needs rather than assumptions.

The Difference Between UX Design and Service Design

UX design and service design overlap significantly, but they are not interchangeable. UX design tends to focus more closely on how a person interacts with a particular product, interface or digital journey. Service design takes a broader view, considering the relationship between the user, digital touchpoints, people, processes, systems and organisational operations that together make the service possible.

That distinction becomes particularly important when designing services for councils, government departments and healthcare organisations. Imagine redesigning an online appointment journey. A UX designer might improve the information architecture, form fields, error messages, confirmation screen and responsive experience. All of those things matter. A service designer, however, will also ask what happens when the appointment is submitted, who receives the information, how it enters the operational system, what the patient is told afterwards, what happens when something changes and how staff deal with exceptions.

Neither perspective replaces the other. Good public-sector digital work often requires both. The interface needs to be intuitive, but the service behind it needs to support the promise made by the interface. Otherwise, you end up polishing the front door while the rooms behind it remain difficult to navigate.

Comparative Overview

Accessibility Has to Be Designed Into the Service

Accessibility is sometimes treated as a checklist completed near the end of a website project. In public services, that approach is particularly dangerous because accessibility affects whether people can actually use the service. A beautifully designed interface that cannot be navigated effectively with assistive technology, contains unclear language, relies heavily on visual cues or creates unnecessary cognitive demands is not a successful service for everyone.

Accessibility also goes beyond technical implementation. Content, language, interaction design, navigation, forms, error handling and the wider journey all influence whether somebody can complete a task. A person may technically be able to access a webpage while still being unable to understand what they need to do next. Someone with limited digital confidence may become stuck at a stage that an experienced designer considers obvious. Someone using a mobile device may struggle with a process designed around large desktop screens.

For that reason, accessibility needs to be considered from the beginning of the design process, alongside user research and service architecture. It should influence the structure of the experience rather than simply being something checked against the finished interface.

Designing for Healthcare Requires Even More Context

Healthcare services introduce another layer of complexity because the consequences of misunderstanding can be significantly higher. A patient searching for information may already be worried, uncomfortable or overwhelmed. They may be navigating unfamiliar terminology, multiple departments or instructions they have never encountered before. The design therefore needs to reduce unnecessary cognitive load while communicating information accurately and responsibly.

Healthcare websites also have to serve multiple audiences. A patient may need information about an appointment, while a clinician may need access to professional resources and another user may need information about a particular service. Treating all of these audiences as if they have the same goals can produce an unnecessarily complicated experience.

The answer is not simply to create separate websites for everyone. It is to understand the different journeys, identify where they overlap and design the information and interactions around genuine user needs. Clear content, logical information architecture, accessible interaction patterns and careful consideration of sensitive information become particularly important when designing these services.

Patient Journey & Supporting Organisational Layer

Caption: Connecting lines show that the website is one component of the journey rather than the complete experience.

Government Digital Services Need to Work Across Organisational Boundaries

One of the most difficult aspects of government and local authority service design is that the organisation delivering the service may not be the only organisation involved in delivering the outcome. A digital journey can cross departments, systems, partner organisations and external service providers. A user does not necessarily care where one organisation's responsibility ends and another's begins. They simply care whether their problem has been resolved.

This makes service mapping particularly valuable. By mapping the journey from the user's perspective and then examining the systems, teams and processes supporting each stage, designers can identify gaps that would be difficult to see from the website alone. Perhaps users are receiving duplicate communications. Perhaps information is being manually transferred between systems. Perhaps a department has introduced a process that makes sense internally but creates confusion for residents.

A service blueprint can help make these relationships visible. It connects what the user experiences with the operational activity taking place behind the scenes. This gives design teams, product owners, technology teams and organisational stakeholders a shared view of where the real problems exist.

Four-Layer Service Blueprint

What the resident/patient sees and does.

Website, forms, emails, staff interactions and appointments.

Internal teams, processes, approvals and communications.

CMS, databases, APIs, CRM, booking systems and other technology.

Caption: Connect each stage vertically to demonstrate how a problem in one layer can affect the user's experience in another.

Content Is Part of the Service, Not Decoration

There is another reason public-sector websites require a different approach: content is often the primary mechanism through which people understand what they need to do. This means content strategy and UX cannot be treated as separate activities that happen at different ends of the project.

A page can have excellent visual design and still fail because the content is unclear, overly bureaucratic or organised around internal terminology. People should not need to understand the structure of a council department or healthcare organisation before they can find the service they need. Information architecture should reflect how people think about their problem and the language they are likely to use when trying to solve it.

This is particularly important for search. People often arrive at government and healthcare services through search engines rather than navigating from the homepage. That means individual service pages need to work as entry points into the wider journey. The user may arrive on a page with no understanding of the organisation's structure, so the content needs to immediately establish what the service is, who it is for, what the person needs to do and what will happen next.

Why Redesigning the Homepage Isn't Always the Answer

The homepage tends to receive an enormous amount of attention during website redesign projects. It is visible, politically sensitive and often the first thing stakeholders want to discuss. But a homepage can look fantastic while the service remains fundamentally difficult to use.

For public-sector organisations, the more valuable question is often what happens after the homepage. Can someone quickly find the service they need? Can they understand whether they are eligible? Can they complete the required task without unnecessary assistance? Do they know what will happen after submitting information? Can staff process the request efficiently? Can the organisation measure whether the service is actually working?

That shifts the success criteria from visual approval to service outcomes. A redesign should certainly improve the visual quality of the experience where necessary, but the bigger opportunity is to improve the underlying journey. In some cases, that may mean the homepage changes significantly. In others, the most valuable work may happen several levels deeper in the service architecture.

What a Strong Public Service Design Process Looks Like

At CreativeIyke, our approach to complex digital products and services follows four stages: Discover, Architect, Build and Optimise. The structure is deliberately straightforward, but the work within each stage can be substantial because complex services need to be understood before they are redesigned.

01. DISCOVER: Understand the Service

The process begins by auditing the existing experience and technical landscape. We look at stakeholder goals, user needs, existing journeys, content, systems, data, accessibility considerations and operational constraints. The objective is to understand what exists before deciding what should change. This is particularly important in government and healthcare environments where a seemingly simple digital journey may depend on several teams or systems behind the scenes.

02. ARCHITECT: Design the Journey

Once the problem is understood, we design the structure of the experience. This can include user journeys, information architecture, service blueprints, wireframes, component systems and interaction specifications. At this stage, we consider not only how the interface should work but also how it connects with the wider service. The goal is to create a logical, accessible experience that supports both users and the organisation delivering the service.

03. BUILD: Make the Service Work

Design then moves into implementation. Depending on the requirements, this might involve CMS development, frontend engineering, backend systems, APIs, integrations, forms, authentication or other digital infrastructure. The important point is that technology is selected and implemented around the service requirements rather than becoming the starting point for the project.

04. OPTIMISE: Learn From Real Usage

Once the service is live, the work continues. Analytics, user feedback, support data, performance monitoring and behavioural insights can reveal where further improvements are required. Public services should not be treated as finished simply because a new website has launched. The service needs to evolve as user needs, policies, technology and organisational circumstances change.

Four-Stage Visual Lifecycle

Research, user needs, systems, risks

Journeys, service structure, UX, accessibility

CMS, frontend, backend, integrations

Analytics, feedback, performance, iteration

Designing for the Organisation as Well as the User

One of the less visible challenges in service design is balancing user needs with organisational reality. A service can be beautifully designed from the user's perspective but impossible for staff to deliver effectively. Conversely, an internally efficient process can create unnecessary complexity for the people trying to access it. Good service design sits between these perspectives and looks for a sustainable way to improve both.

That requires collaboration with stakeholders beyond the immediate website team. Depending on the service, this could include policy teams, service managers, content specialists, developers, accessibility specialists, customer service teams, clinicians, operational staff, data teams and senior decision-makers. Each stakeholder sees a different part of the service, and bringing those perspectives together can reveal problems that no single team could identify on its own.

The designer's role is therefore not simply to produce attractive screens. It is to help make complexity understandable, create alignment between different stakeholders and turn evidence about user needs into a service that can actually operate. In complex public environments, that ability to connect people, processes and technology is often more valuable than visual polish alone.

What Does Good Public Service Design Actually Look Like?

A good government or healthcare digital service should feel surprisingly simple to the person using it, even when the organisation behind it is anything but simple. The user should not need to understand the organisational structure, technology stack or internal approval process. They should be able to identify what they need, understand what is expected of them, complete the relevant task and know what happens next.

Behind that simplicity, however, there may be considerable complexity. Multiple systems may need to exchange information. Different teams may need to perform specific actions. Content may need to be reviewed and maintained. Accessibility requirements may need to be continuously considered. Staff may need new tools or processes. Data may need to be handled securely. The service therefore succeeds not because complexity has disappeared, but because the complexity has been organised in a way that does not unnecessarily burden the user.

That is ultimately what separates a website redesign from service design. A website redesign asks how the digital interface can become better. Service design asks how the experience of accessing and delivering the service can become better. For government and healthcare organisations, that broader question is often where the greatest opportunity lies.

The Future of Government and Healthcare Digital Services Is Not Just Better Websites

The next generation of public services will not be defined simply by having cleaner websites or more modern interfaces. They will be defined by how effectively digital technology connects people, information, organisations and processes around genuine user needs. A resident should not have to understand which council department owns a service. A patient should not have to understand a hospital's internal structure to find the right information. A user should not have to repeat the same information because two parts of the service cannot communicate.

Design has an important role in solving those problems, but the solution is rarely just visual. It requires research, content, UX, accessibility, service architecture, technology and organisational collaboration working together. Sometimes the answer will be a redesigned website. Sometimes it will be a new digital service, a better form, an integrated system, an improved content model or a completely restructured journey.

At CreativeIyke, we approach these challenges from a Solution First perspective. We bring together human-centred UX/UI design, service design, full-stack engineering and intelligent technology to understand complex problems and build digital experiences that work for both the people using them and the organisations delivering them. Our experience across digital products, public services and complex web environments allows us to look beyond the interface and consider the wider system in which that interface has to operate.

Because a government or healthcare website is rarely just a website.

It is part of a service. And the service is what people actually experience.

EXPLORE SERVICE DESIGN WITH CREATIVEIYKE

If your organisation is dealing with a fragmented digital journey, outdated CMS, inaccessible content, complicated forms or disconnected systems, CreativeIyke can help you understand the problem before deciding on the solution.

Iyke Anselm

UX/UI designer and developer in Birmingham, UK. I design and build digital products for SaaS, fintech and public sector teams.