How to use Service Design to move away from legacy systems
Planning a move from legacy tech provides an opportunity to rethink how products and services are delivered
Many public services are delivered in spite of the technology infrastructure in government, not because of it. Powered by a tangled web of different teams, processes, products and data, these services are also often held up by shadow systems and workarounds filling the gaps. Spreadsheets are the norm.
No-one intended it to be this way. But this is how many services have evolved as needs and policies have changed. It feels much easier, quicker and safer to add in new products and tools rather than remove or replace anything that’s no longer doing quite what it needs to.
These legacy systems are holding back the potential for great services. Civil servants and the public waste precious time navigating various products to complete their tasks. Data is duplicated and moved manually from system to system. Sometimes tech can become so clunky it creates additional risk and work for teams who are mandated to use it.
The number of times I’ve heard users say “I wish everything was in one place…” None of this is good value for money for taxpayers.
Government needs to bite the bullet and do the work to move away from their legacy systems if they want to improve service efficiency, data quality and – ultimately – outcomes for citizens.
To avoid the risk of simply lifting and shifting existing problems into a slightly shinier architecture, organisations must take the time to reflect on how the current system is working. My colleagues Nicky and Tim have written some great technical blog posts on managing digital legacy transformation, and how we’ve approached decommissioning legacy tech. In this post, I offer 3 Service Design-inspired steps to help teams create a strategy for moving away from legacy technology.
1. Find common ground
Planning a move from legacy tech provides an opportunity to rethink how products and services are delivered. Understanding your service ecosystem enables organisations to find efficiencies and improve the user experience.
There are 2 ways we can think about finding common ground:
- What overlaps are there between product and policy areas in terms of objectives and outcomes?
- Where are we solving the same problem or user need, even if it’s in different contexts or with different users?
Product and policy overlaps
Zooming out from your service and mapping how your processes connect, depend on or support others can be really helpful in identifying opportunities to align and simplify experiences.
Understanding what has gone on before your service starts helps reduce the risk of replicating tasks. It identifies, for example, if the data we need might already exist. It helps us understand what a user might have already done before they reach us.
Knowing what happens after or alongside your service helps us find opportunities to join up and simplify.
There is no right or wrong way to do this kind of thinking other than to make sure your team is working in the open and communicating regularly. You could start with:
- mapping the different policy areas and activities within them to see how they connect e.g. for people in prison or on probation, education is related to finding work which supports successful rehabilitation
- thinking about the different types of services that might influence your desired outcomes e.g. living well for longer is influenced by our choices and experiences across work, education, community, access to health services and more
- your user journey(s) and how other products, services and policy areas relate to it e.g. how planning policy affects how a piece of land becomes a building (or not)
Image shows the ecosystem for a rehabilitation service
Solving the same problem or user need as others
Delivery teams are usually set up around individual policy areas. This often means they focus on their specific user journeys in isolation of the other things a person may be doing, even within the same government department. Rehabilitation is a great example of where there are overlapping and complementary policies – there are needs for accommodation, behavioural support, education and work support, health and wellbeing or financial support.
Thinking about our services in stages can help teams identify common patterns and user needs. It helps them build off each other’s work, and sometimes benefit from it directly.
In our work for the Ministry of Justice on rehabilitation, this approach highlighted that another team had already resolved a lot of the user needs for managing attendance but in a different context. Instead of starting from scratch, we tested the hypothesis that our users could use this solution too. This helped us deliver more, more quickly. It also meant there was greater consistency between services, which are largely used by the same users.
There’s already lots of good conversations about service patterns out there, like this blog post series from MoJ Design. With the new “Mission Driven Government” in place it feels like momentum is building to think about how we approach building and delivering services.
“Mission driven government is another huge opportunity to catapult ourselves out of our silos and start real collaboration.” – Nikola Goger, Head of Design, Ministry of Justice
2. Prioritise your system components
Moving away from legacy tech means we need to prioritise what happens first. This can be really difficult when there are so many moving parts and intertwined services. In past projects we’ve found it helps to visualise dependencies and use different lenses to make sense of them. In our work on the planning system with MHCLG, we used several methods to help stakeholders make informed decisions.
Building a house
Image shows a miro template that can be used to think through components of a system
Think about elements of your system as the levels of a building. What is the foundation of your services that you absolutely need to function at the most basic level? In planning this might be core processes like the Local Plan process, or the Integrated Assessment process that underpin many planning decisions.
From here, think about the first floor of the building. If we have the foundation established, what does that then support? This is likely to be products and services that make the process better or more efficient, like Design Codes and Net Zero tests.
For the second floor, we may have additional value-add services that visibly improve the system, but aren’t critical to its functioning. Things like digital citizen engagement strategies or first home policies.
Thinking through complexity in this way helps us prioritise and consider the knock on effects of any changes so we can plan for and mitigate risks.
Mapping common traits
Mapping common traits is useful when there are limited resources and you want to make sure you’re addressing the most impactful need first. You might look at the number of people using a service, total time spent completing a task, or other metrics. Visualising these options can help stakeholders align and agree on priorities.
Our work with MHLCG on planning policy used this approach to explore the potential for different policy areas across the country.
Image shows a map of rural, urban and mixed populations across England from the MHCLG planning reform project
Visualising timelines
Moving away from legacy systems and processes takes time and will have knock-on effects on other areas. Speaking with and roadmapping each policy or service area can help us see the collective impact of plans on our users. We can use this information to identify risks, speed things up, slow things down or move things around. This allows everyone to see the full picture and scale of intended change, which fosters better communication and alignment.
3. Make decisions as a whole service
“It’s no longer enough to just hope it’s all managed sensibly” – Kate Tarling, The Service Organisation
In Kate’s book “The Service Organisation”, she dedicates a whole chapter to “Establishing whole-service leadership” and I couldn’t agree more. It’s too easy for individual product teams to default to making decisions in isolation of the bigger picture. They have deadlines to meet and stakeholders to satisfy. What that means however is that we miss opportunities to prioritise work that would have more impact as a whole.
An API for example, might be sitting on a central system backlog and could be fundamental to the experience of a user on another service. The affected product team is powerless to influence that decision, so they create a temporary work around, adding greater complexity to the system. And there’s a real risk that teams might never go back and remove that workaround when the API is ready.
This brings me back to my earlier point about the importance of working in the open and communicating regularly. Service Designers should work with Product Managers, Service Owners and product teams to help join the dots between their priorities and user needs so they can make informed decisions.
Using different perspectives to think about our services can help us:
- identify opportunities for improving how we deliver value to citizens
- think about implementing those changes in a way that will deliver the most value
- consider the knock-on effect of any change on our users or other teams
- establish a roadmap based on improving the critical elements first
Moving away from legacy systems is about more than just the tech
Moving away from legacy systems is a great opportunity for us to reflect on the service as a whole and look for ways to improve the experience and outcomes for the citizens, service providers and organisations involved.
Getting there is about more than just the tech.