Designing with legacy
Designing new products is easy. Designing brand new web-based user interfaces from scratch is not even a work — it’s fun. I mean, it’s a tough job to get it right, but at the end of the day, what could go so horribly wrong, that it can’t be improved it in the next iteration?
Dealing with decades old product legacy is a common challenge in enterprise and professional software design. There is no single correct approach, but being aware of a few common patterns can help the team to make the right decisions.
Origins
A 10-year's old product without a major UX improvement does not just happen accidentally. Main reasons often attributes to:
- Acquisition. A product left in sustaining mode too long after the acquisition.
- Reorganization aka Team tetris. Canceling the Washington development site and moving all the development to Hawaii over-night.
- Features driven. Only new additive features are accepted as a proper product backlog item. Chasing the competition, profit margin, or anything else than user satisfaction.
Rip-and-Replace scale
How to deal with the legacy products? Basic options can be evaluated on the rip-and-replace scale.
When the legacy spans across technology backend, user interface, competition landscape and product market fit, an obvious solution might pop-up to completely re-design the product. This is where a brand new product is born in parallel to existing application.
The continuous improvements approach represents the other side of the spectrum. It is mostly known from the web-design world as Conversion Rate Optimization (CRO), but the iterative improvements can be applied also to a non-conversion product design processes.
In reality, product teams need to find a balance between the two extreme approaches.
Re-design
This is a popular approach found in IT Enterprises and often seen as the only option for on-premise or acquired products. But this is also the approach that often fails. But not in a startup kind of fail-and-learn way. This is the creepy agony that could slowly kill a product that was once a market leader.
Product re-design often includes external wisdom from Design agency or business consultants. It is done in a right way, funded with a proper user & market research, defining the right problem. A product solution is designed to address the problem in an ideal way, taking into account all known technological constraints. The sweet spot MVP is defined and the new product is shipped — in parallel.
The problem is, that the original legacy product does not exist in a vacuum. It lives in a decade old eco-system that includes everything from tribal technical knowledge, customization deliverables or learning resources. Users have no motivation to throw away something that works — they only might check it out, and the real adoption lacks behind the expectations. As the New App often overlaps with the existing one, re-designed product falls into an endless spiral of feature comparisons and feature requests.
For a complex professional software, this means that the total cost of ownership is now higher than it was before. Customers need to administrate and maintain two systems, with two UIs, that needs to be customized twice using two documentation resources. Software vendor encourages the customer that this is a temporary situation, but it only fuels the frustration. Even that the original feature set took 10 years to develop and polish, subjectively it now takes too long for the New App to take over. Mixed unclear messages about the original product being suddenly old or that it will be discontinued puts the customer into an unclear position. This uncertainty often leads to competitive evaluation and leaning towards a competitive product, even if its benefits might not match the original legacy product. Humans are driven by their emotions, and they don't like to feel being tricked or part of an experiment.
A rip-and-replace re-design does not take into account years of building the internal know-how of what works and what not. Over countless escalations, fixes and improvements, small missteps and big victories, the people of the product team built a shared knowledge of how to steer the product in a right way. This know-how cannot be documented or transferred. It is bounded to the most precious resource that any company can have — the people.
Continuous improvements
This is the approach that is positioned on the other side of the extreme rip-and-replace scale. The company would not even attempt to come up with a complete product replacement. Instead, the team relentlessly improves existing UI patterns, technology stack and features in rapid and repetitive iterative cycles — this is called Agile these days :).
The biggest problem with this approach in an Enterprise environment is missing success metrics that can clearly and immediately measure the overall product User Experience. Product UX is not a single number (not even NPS) and it is virtually impossible to describe or predict human behaviour with a single score. Continuous improvements work in environments with fast feedback loops evaluated with paired metrics of usability testing and business value. Business value evaluation is relatively simple for an e-commerce website (CLV, Revenue) and it enables great techniques such as A/B testing. A large user base makes it simpler to execute repetitive usability testing studies. On the other hand, enterprise selling is difficult, it takes time, and so is upgrading or license renewal process. Product teams do not have immediate data available to know, which little user experience improvement had a direct and measurable impact on the user satisfaction, task efficiency or how it impacts the revenue. Product teams often depend on the field proxies — pre-sales, sales or support. And the job of a good salesman is to sell and the job of a good consultant is to overcome the issues. This mediated indirect feedback never accurately reflects the reality and makes the continuous improvement design process ineffective, often steering the product to a wrong path.
Another continuous improvements blocker is the technological agony caused by beating a dead horse for too long. Imagine that your product uses Flash for dashboards in 2017. There is nothing you can do to continuously improve your Flash UI in 2017 — it is already dead. But what happened before this wake-up moment? Wasn't it obvious from usability testing, that people struggle to use the product in their natural environment, using the browser and device of their choice? This is the kind of feedback, that will never reach the product team without contextual inquiry usability testing, as these issues are promptly solved by the services team.
Conclusions
I was dealing with the legacy in all my major career assignments, and I still can't say that I found the right answers. It is not obvious even in retrospect. I can recall proposing a complete re-design for a professional product. Based on all the data I had, it was lagging behind users expectations, struggle to significantly grow new markets, and it used ancient technology stack. Now almost 10 years later, that product still exists in its original form, it is still making millions and it has thousands of satisfied users. There was clearly something missing in my original evaluation.
As a designer, maker, and engineer, I don't like working on parallel reality design projects with unclear adoption that might get canceled at any point. I don't see a point of re-creating something that already exists with the executive objectives that it looks old. This is something that can be improved iteratively or with a new UI Design System.
The knowledge base built over the years is incarnated in the current product and it cannot be just replaced by a brand new brilliant design concept. Systematically influencing the eco-system and understanding of the evolving user goals are the challenges to be solved with successful product design process.
When a complete re-design is inevitable, I would recommend to always reserve a design capacity to continuously improve the original app. The existing user base needs you, and no successful product legacy deserve to die in agony. People tend to emotionally attach to products, and until you figure out what is the secret eco-system essence missing in your New App, just forcing people to replace their professional toolset might fuel the frustration and negatively affect your product adoption.
