Legacy systems power much of the public sector. Often these systems were put in place as ‘fit and forget’ and are maintained by a single supplier who employs the only person this side of Mars who knows how to make any changes.

But technology moves fast and these systems represent a snapshot in time of what was once considered cutting edge.

While modern software development is characterised by agile ways of working and easy integration with web services to accommodate changes in policy or process, legacy systems were often the culmination of monolithic IT projects that now feel cumbersome and ineffective.

Not modern, sexy or exciting, but still critical for many of the services we rely on.

These systems are so prevalent across the sector that Alison Pritchard, director general of Government Digital Service, prioritised their replacement as one of the five pillars for digital government for the next decade.

On the face of it, unless you are scrapping the system and starting from scratch, it might feel premature to start thinking about a more user-centred approach to a service powered by legacy systems.

But using service design tools and techniques, based on the GDS Service Standard, will uncover and distill evidence so you can make objective and strategic decisions about the future of the system and the service based on the needs of the people who will be using it.
‍

Mapping the as-is experience

One frontline service can be powered by a multitude of different systems, for example: CRM, notifications, payments, web front-end, and numerous databases.

There are probably different people responsible inside or outside your organisation for managing each element and issues arise when those components are treated in isolation rather than as part of an end-to-end experience.

Getting those people together in a room and mapping out on a wall the way users interact with the service and the associated technologies will help you visualise the big picture. Are there components that you already know are broken, what is slowing people down or causing them to drop out?

Staff are critical users too, so it’s also important to understand their experience. Systems that make it hard for them to do their jobs have a knock on effect for end-users.

When we led the design of an apprenticeship scheme for local authorities, a service mapping workshop with stakeholders and staff helped people to see the big picture and identified key areas to hone in on to improve the experience for students and employers, despite the fact that the technology wasn’t due to be replaced for two years.
‍

Technology changes quickly but human needs stay the same

When systems have been in place for a long time, it’s easy to assume we know what the problems are and if we might be starting from scratch, why waste time understanding the detail of the way people are using the system now?

Rigorous user research with staff as well as end-users means we gather a clear understanding of the needs the system has been built to meet. But we also gather evidence around the way specific tasks are working or not working right now.

This insight can be layered over the experience map as evidence of pain points and opportunities, providing a clear view of the as-is experience.

When we redesigned the most detailed application process in government, user research with frontline service delivery staff uncovered numerous work-arounds that people had put in place to make their jobs easier. These work-arounds weren’t part of the system but gave us valuable insight into the way people needed the system to work.
‍

What if the problem isn’t the technology?

Legacy systems come with baggage and associated problems, but often experiences can be improved by streamlining processes or hacking the way things work. Good research will identify the problems worth solving, which of those require technology changes and which can be solved in other ways.

By deeply understanding what the experience of using a service is like for staff and end users you are able to build a business case for the changes needed. You will know what needs to happen to reduce errors, frustration, wasted time, drop-outs and significantly increase the effectiveness of the service.

You can build a business case around the impact you want to have on the users, as well as your organisational or policy goals.
‍

Envisaging the future

One of the questions researchers like to ask at the end of an interview with a user is: “If this service was magic, what would it do differently, how would it work?” This opens up the conversation for the user to think about how their needs would be met if there were no constraints.

We’ve reached a point where technology can, at times, feel synonymous with magic. With a clear understanding of the needs of the users, you will be able to create a vision for the future that doesn’t just replicate old functionality in new code. And in the meantime, you can work with what you’ve got and incrementally improve the existing service despite the fact that the technology might be a bit painful for just a few more years.