Moving away from a legacy system
When moving away from a legacy system, it’s okay to incrementally improve old systems, while not blocking the future
As part of one of our larger transformation projects, we’ve been exploring ways of moving away from a legacy system.
This is a big piece of work and we began with a discovery to better understand the problem, the technology, and the needs of people.
After evaluating different options with the client, we recommended running an alpha to explore and test the riskiest assumptions around what they needed to build to replace the old system.
Understanding what needs to be designed
Like a lot of legacy systems, this one kept growing organically, adding functionality over time as users encountered new problems. This meant that the system was doing a lot of different things for different teams and doing none of them well.
People had to adapt their work to what was possible with the tool, instead of the other way around. It was creating more work, costing more than it should and it was hard to use.
When unpacking the system, distinguishing between services (what the end user is trying to do) and products (tools that will help staff members deliver the service) became really important. Being clear and intentional on what we were designing early on helped us stay focused on delivery and not falling into rabbit holes during working sessions.
As a service designer, in this kind of work it’s tempting sometimes to question and rethink everything.
The project didn’t have the scope to be able to redesign the services, so we tested prototypes to understand what products and tools could be designed to help teams do their job better and how to safely migrate data and users.
When moving away from a legacy system, it’s okay to incrementally improve old systems, while not blocking the future. But digital products are rarely the whole solution to a problem.
Services need products
Even though it was important for this project to keep the focus at a product level, we also had to contextualise all those products and tools we were designing to account for the services they support. Whatever we changed was going to have an effect on the delivery of those services.
In practice this meant there were several aspects to this work.
Working with other organisations
We needed to work with the 4 organisations that were involved in the delivery of the different services, to understand their context, their constraints, and what worked and didn’t for them from the current system.
Connecting their day to day tasks with how people experience the service
We showed which steps in the journey the products were relevant to and what happened before and after. Highlighted assumptions and the biggest pain points, then unpicked this through design research.
While this was an internal system, showing evidence from research was helpful for the organisations to see their services from an end user perspective and move conversations away from ‘requirements for the new system’.
Involving them in the change
Changing the tools will change how staff members do their work and potentially the culture of the organisation. Involving people and being open about the things we were exploring made things easier and more constructive.
Designing better data flows
In discovery, we mapped the data available in the legacy system, why it was being collected, and who had access to it. We also assessed its quality.
We worked with different teams to understand where there was duplication and it made sense to access others’ data, and when it was right to give access to the data the new products would generate.
Finding common tasks shared between services
Common tasks included things like “requesting, sending, and receiving documents”, “tracking a case”, “finding someone”. We showed different ways for how those components could (and should) be reused.
None more important than the other
Change is hard. Even if it is to move away from an old (and bad) system.
It can be difficult for people especially when they are under pressure to do their day job, and they’re used to working their way through poorly designed manuals to use a new tool they’ve never seen before.
What we’re doing is different and bringing (and involving) them along the journey is important. Showing them enough about the future to build confidence and maintain it through the different iterations.
The constructive tension between product thinking and service design is helpful. For services to work for end users, staff members need good products.
And of course, end users don’t care about the distinction between products and services, they just want to get something done.
