How to incrementally do transition from large legacy system with poor UX?

Question

I am sure many of us have faced this problem before. As the only UX designer in a mid-size organization, I am facing a few challenges while executing projects. The organization has a legacy web based system for internal and external (End) customers in order to sell products. There is very little thinking/rationale behind the existing design and usability.

While for new projects we are trying to take care of the essential aspects of usability and user experience, there seems to be 'Chicken or Egg' type of situation. If I use something in one project, it does not suit in other project. So, if something is being newly designed (on feature level or new product level), I have to consider what already exists. The difference between my design and existing design can be observed right from fonts, button styles, using popups or inpage components, confirmation, feedback message type styles, color schemes and more. But until and unless we stop using it, we cannot use new ones and this breaks consistency. The users are mostly non-tech-web-savy above 35+ type of users, so the transition from existing interfaces might matter and we may lose business if not done properly. There are 3 type of solutions I can think of:

1. Continue using current system (but Its useless, non-appealing, non-scalable and will not serve for more time. Moreover I won’t enjoy like this as this is not what I am getting paid off)
2. Build a new fresh system (though I will love this, it will be expensive and more over time consuming. Its very hard and next to impossible to convenience team for this)
3. Have a mix (but then experience will not be consistent. On the same page it will have two buttons with two different styles and many things like this. It will a chaos rather than good mix)

Considering all this, how to have smooth transition from old interfaces to better (expecting strategic point of view here)

Answer 1

First, there's no easy answer here. Second, from your list of solutions, number 1 isn't really a solution, and number 2 sounds like a non-starter.

The question is really about how to incrementally replace a large legacy system, for the purposes of improving experience, and with the minimum possible impact.

The Problem of Power and Budget

If you don't have the backing of whichever department(s) hold the roadmap and the budget strings, all the best UX intent in the world isn't getting you anywhere with this. An undertaking of this size is complicated and expensive, and without significant backing, your only option is to get out a rag and start polishing that turd.

If you don't have backing, you should step back a bit and make your question about how to convince potential backers that you need to do take on this rebuild.

The Problem of Legacy System Architecture

The next biggest hurdle to this the legacy system architecture, and its inflexibility. Unless that is changed/upgraded, you’ll be building these new interfaces on a weak foundation, which will cause you lots more work and trouble in the long run. In an ideal situation, your new UI would be a reflection a simpler and more scalable system, and designing for an architecture that’s been straightened out is going be easier than solving the problem of just making things work. If the system isn’t changing, your work is really cut out for you.

Transition by Product/Platform Segment

(this assumes that you’re actually working towards rebuilding the system from the ground up) One approach is to take the smallest complete slice of your platform that’s capable of functioning independently, ideally something relevant but not critically important, and rebuild just that to begin with. Not knowing anything about your platform, it’s hard to suggest what this might be, perhaps some secondary service, but the idea is to break out a section that will let you prove your concepts and solve the problems as they relate to the system as a whole. You launch this as a new environment that sits alongside your old one, and then move larger and larger slices of the platform into it as you redevelop them.

Transition by Feature/Function

(this might be more realistic in your case, and doesn’t necessarily assume you’re rebuilding everything) You segment the platform by feature/function e.g. authentication, user management, ordering, navigation, etc. and take them on one at a time. Assuming you get it right, this approach is least disruptive for users, but a lot more work for you.

Technical note: I’ve worked on a system update (not a complete rebuild) that took this approach. To make the feature-by-feature transition possible, the engineering team ended up building a new internal API that was more lightweight and flexible than the legacy architecture, and gave us the freedom to isolate the features for improvement.

Collaborate with System Builders

You really should be talking about this with the people who build the system. The approach you eventually take will ultimately depend on their resources. They’re little point imagineering at perfect migration strategy only to find it’s something they’re not capable of achieving.

Bottom line: All this is barely the starting point. You’re asking about hugely complex process. Good luck.