Improving legacy systems is often like restoring an old farmhouse
“Sorry, some of the screens look like they’re straight from the 90s.” The client said she showed me the project I’d be designing for. It wasn’t the first time I’d heard that, and it probably wouldn’t be the last.
Working for large organizations, especially those in the federal sector, means that sometimes you’re asked to work on projects that seemingly have been around since the 1970s.
When you see something without a GUI, your mind might be considering how you’d replace everything with a shiny new design. After all, a design following UX best practices must be better than something created before UX was a field, right?
That approach might have you run into a lot of resistance.
We tend to only think about two types of design approaches: either we’re designing something from scratch, or we’re redesigning an existing product. These approaches often look to scrap a lot of what exists to create something better. That doesn’t always work with legacy systems.
Sometimes, if you’re working on those, you need to take a different approach: You need to imagine that you’re restoring an old farmhouse.
In this case, you need to understand the restoration mindset.
Understanding the Restoration mindset
Why do some people spend time, effort, and money to restore an Aston Martin instead of buying a new car?
After all, the newer car probably has better gas mileage, is safer, and has 50 years of car safety technology behind it.
Whether it’s nostalgia, a fun hobby, or other reasons, many people are invested in making sure their old car looks pristine rather than just buying a new one. This same sort of approach applies to products.
Certain user groups or stakeholders may care about preserving what currently exists rather than rebuilding it from scratch. It’s not just rooted in nostalgia or personal investment: sometimes, the old system works better for them.
In one example, two programs did the same thing, which was fill in a particular form. We were trying to phase out the GUI-less program with the newer version but ran into resistance from a group of experts.
When we did user research, we uncovered two main reasons why:
- First, the newer program had many potential errors users could make.
- The older program had easy Access Keys.
The second point was crucial for our experts. Rather than hitting the “Next” button several times, these users had essentially memorized a sequence of keypresses to quickly fill out this form (pressing the “N” key →> “K” →> typing in the description → “S” → “P”).
There can still be things that users find helpful or prize highly with legacy products.
With re-designs, we might preserve a few features while otherwise completely rebuilding the website. This might be considered taking a few knickknacks from an old car and implementing those into the new one.
With restorations, though, you’re mainly keeping the older frame. Instead, there may be improvements that you make under the hood or incremental changes to the exterior.
You shouldn’t be discouraged by this much slower approach: thinking of it as a restoration project can allow you to frame how you approach a number of these challenges positively. So how do you start working on a restoration project?
By embracing the mess.
Embrace the mess
When you look at a legacy product, you’re often looking at a tangle of code, product decisions, and temporary solutions that might have become permanent.
It would be best to accept that perhaps not everything works logically, and simple things might have underlying reasons for not existing.
For example, the ability to allow users to print directly to their home printer (a helpful feature when working remotely) might be a security hazard if they’re printing government documents with an official government seal.
Sometimes these decisions make sense. Other times, they might not. You have to accept the mess for what it is to reach the next step: having conversations early about alignment.
Early alignment and research is key to a successful project
If you can’t get your stakeholders to care about what you’re trying to do, then perhaps you’re focusing on the wrong problem. Even if you do, you still might run into issues about the project’s focus.
It’s critical to get key players into one room and align what you intend to do with a project. However, this is where you may face one common roadblock: resistance towards user research.
Some of these stakeholders might have been through this process before, which is why you might have to defend the importance of user research. The most common reason why is that they might think, “Oh, we’ve already done the research.”
This might be surveys, project documents, or mostly unrelated data. On the other hand, this might be actual UX Research documents, like personas and interviews, but done five years ago.
In either case, while these documents might help, you ultimately still need to show them the value of user research.
This will be critical in making sure that we’re aligned through this early stage of the process. User research helps us validate early assumptions about the project, examine the problem and context as it currently stands, and ask research questions that we currently face.
Luckily, thinking from a restoration mindset gives us an additional tool to persuade our team: vision.
Conceptual sketches and product vision are persuasion tools
When we think about restoration efforts (especially of older buildings), one tool is always used: a sketch of what it could look like.
Architects use these conceptual renderings because it can be hard to see the potential of a run-down building. When we think about restoration efforts, this strong vision of what it might look like allows stakeholders to see the result, which allows them to get on board much more effortlessly.
If we’re only talking, some experts in the system might feel like we can’t improve it, while others may feel like it’s not worth the effort to try and salvage.
If we have design artifacts, conceptual sketches, and more that we can reference, it can be much easier to align stakeholders to what we intend to do.
This means, ultimately, that we need to invest additional time in thinking about how we might approach this early on to make sure that we align our team with how we might incrementally improve this legacy system.
Restorations are difficult
Restorations, on some level, are even more difficult than re-designs. For example, we may have limitations built from old architecture, or you may not change everything you want to.
However, if you’re working with legacy products, understanding how it was built can allow you to consider the best ways of improving them. The early choices of others, even if they seem strange, were a commitment to some vision of the future.
Taking work that people did in the past, and making it usable for those in the future, is a worthwhile task and a great responsibility for designers to undertake.
Kai Wong is a UX Specialist, Author, and Data Visualization advocate. His latest book, Data Persuasion, talks about learning Data Visualization from a Designer’s perspective and how UX can benefit Data Visualization.