Use Design Thinking to Modernize Legacy Applications

Design Thinking has become very popular for tackling business problems, but there isn’t an obvious fit when modernizing legacy applications. Design Thinking is particularly user-centric, where legacy applications are greater than merely the people who use them.

Furthermore, an application that is so essential that it requires a “modernization effort” often spans the entire organization. In which case, it touches many layers of the organization from day to day users, across the disparate systems with which it interfaces, and up to the senior leaders who rely on it to navigate the business.

Understand

Following the Design Thinking model from Kelley, Brown, and Martin, we first attack the modernization problem by understanding it. That includes empathizing with users and defining where their problems exist. As we learn about the users and their problems, let’s also consider the problems that the organization itself is facing and ask, “can we ‘empathize’ with it? Somehow?”

We start by inviting senior leaders to enlighten us on the impact the modernization effort will have on the business. They illustrate the goals that modernization helps achieve and the additional value we get out of going through the effort. Why do we want to suffer through this? What pain points are we struggling with that are so pervasive that they are forcing us to bite the bullet and modernize this application?

Performance: Has the organization grown dramatically increasing scale and burden on the application? We need to understand the impact that poor performance has had on our business.

Maintenance Costs: Do we need to sunset the old infrastructure and move the application to the cloud? Beyond the O&M costs we should look for opportunity costs that we could recover.

Expansion: Are we solidifying the foundation for new functionality? What have we been missing all these years?!

Three “actors” in Design Thinking include organizational goals, business processes, as well as end-users

We must also stretch our Design Thinking to consider the business process that the legacy application facilitates for our end-users. Clunky or not, the legacy application was built to enable users to do business. To gain insight into the process, we confer with business-line leaders who know how valuable it is. They hold the key to a fundamental question: what problems with the business process can modernization solve?

Ultimately, as we define the problems that hinder users as well as the organization then we start to decouple them from the technology problems. Design Thinking enables us to envision solutions we never thought possible but only if we free ourselves from artificial constraints. If we’re updating the technology anyway, let’s remove it as a potential barrier.

Furthermore, we also identify different means for measuring success such as the junction of happy users and happy application analytics. This opens us up for innovation.

Explore

Now that we have a clear picture of the problems the modernization efforts should address for the users as well as for the organization, we begin to explore solutions. There are many methods for ideating and brainstorming solutions – from quick “How Might We” (HMWs) to more structured Design Studios.

The key here is to address the business problems alongside the user problems – let’s give our solution team carte blanche to explore a medley of possible solutions. Remember, not everything will fly. Some ideas fall to the floor but some may only work in combination with other unrelated ideas. But again, that’s innovation.

Once the team has mapped out a few solutions, it’s time to build prototypes to validate the solutions. By bringing tactile representations of the solutions to life, we can better assess how well the ideas meet the users’ needs, improve upon the legacy application’s process, and gets us to our modernization goals. Begin looking now for validation that we’ll get performance improvements or recover opportunity costs.

We start by focusing on a particular sub-process and do a simple A/B comparison between a paper version of the current application and a paper version of the proposed solution. For example, if we’re modernizing a case management system we create hand drawn depictions of the current screens used for entering case information (version A), submitting the information for processing, having it reviewed by a case manager, and interfacing with other systems. We then draw the proposed solution (version B) with refined layouts, auto-populated information, input field validation, and clear interactions. If possible, we also simulate micro-services for efficiently manipulating data.

Very quickly we gauge if a user is having an easier time entering the information, understanding where s/he is in the process, and having the application facilitate tasks. We also determine if the process is more efficient and whether we can eke out better results with the same effort. Finally, we start to get a sense whether or not this solution is good for business.

Without writing a line of code we gather deep broad into the solutions we’re proposing and the potential for success.

Materialize

Once we are comfortable with our prototype, we consult with the software engineers who will build the MVP and can determine how technically feasible the solution is. They also ascertain whether the solution team has opened the door for improving performance, removing infrastructure constraints, or taking advantage of advances in technology.

With the MVP, we also begin stringent testing with our users. As the solution materializes we see firsthand if we’re meeting their needs. We also start measuring improvements in the process and determining organizational success based on analytics. Within a few iterations we refine the solution by focusing on the details for a production-ready implementation.

As we move forward we know what it will take to truly transform the experience for the user, how to revitalize the process, and what’s needed to bestow real value on the business. We have laid the foundation for a solid, tested, justified solution because:

We have a clear picture of what success must look like from three distinct perspectives, not just the user’s

We have leveraged collective expertise and buy-in from throughout the organization

We have fostered innovation by exploring multiple avenues for solving the problems with the legacy application.

Now we move forward with confidence knowing we are building the right solution.