Don’t Rewrite Your Legacy App, Reimagine It

Let’s say your business is sunsetting a legacy application and replacing it with something new. You begin user testing of the new solution and hear the following statement:

“It’s the same but, different.”

The tone of that statement can be taken two different ways: It can be a cheerful and enthusiastic proposal, or a deflated and stoic response. Can you guess which one is the Product Owner and which one is the user? In this context, the hopeful enthusiasm comes from the Product Owner and the ominous response comes from the user.
 

Confusing Perspectives: Product Owners and Users

Often times Product Owners make decisions out of fear – and with completely good intentions. They’re responsible for the budget and scope of a project, but want the new technology to be accepted by users. So, they will try to re-incorporate as much of the legacy application into the new solution because it’s familiar.

Who can blame them? After all, the users likely have intimate knowledge of it – and no matter how much it frustrates them, that familiarity bares gravity. Through repetition they’ve become accustomed to the system’s user journeys and have committed relevant interactions to memory. But if we look back at the aforementioned statements made during user testing – the user’s response was a warning sign. It tells us that user acceptance and friction may be an issue right out of the gate because they see it as “more of the same”.

In other words, The very problem the Product Owner wants to avoid is what might occur anyway.

So here we have users that want the cozy feeling of learned behavior from the legacy application, but they also see those very experiences as less than compelling when reintroduced. Sounds like a losing battle, huh?

Stay with me, we can break this down…
 

Uncover What Users Really Want

When you map out user journeys, you’re highlighting key steps users take to complete a specific goal. We do this to understand the current path of the user, whether it’s a manual process or has some level of automation in an existing system. In those steps, we leverage data output from Empathy Mapping to give context to the current mood and behaviors as indicated by the users.

An example of Empathy Mapping looks something like this:

If we take this Empathy Map and apply what we’ve learned through it, we can then bring proper context to the user’s journey. For example, consider the below columns tracking the mood of the user throughout the journey using the previously procured empathy mapping data.

This is Journey Mapping 101. However, what we want to do is take these maps and move a step further and look at the journey from another angle. As we transition from empathizing with the user and defining what we’ve learned, we can start to surface ideas and opportunities from the maps alone. It could look something like this: 

In this example we identify the current journey and categorize each step as they relate to a decision-making process. Looking back at our past blog post about Decision-Making in UX, we can split steps out into System 1 and System 2. This will allow us to understand which steps are intuitive or automatic for the user and which steps require thought and effort. The overall objective is to commit as much as possible to System 1, subsequently minimizing the amount of thought and effort we’re asking the user to undertake. This will effectively reduce cognitive depletion and allow the user to focus more energy on important effortful tasks.

As you can see on the right side of the example, we’re trying to manage that decision-making balance using opportunity modeling. In this opportunity model we’ve identified specific steps where we can utilize automation (which can be seen in the bottom left of Journey Mapping), subsequently taking this task off the user’s plate. What we’re left with is a top-level view of the user journey that feels far more simplified. 

Why Early Journey Mapping Is Important

In plain terms, we’re making a very pointed effort to provide solutions without ever putting a design on a screen. There’s no comparing of visual designs from a legacy application with what’s being proposed for a new solution. The conversation begins with a top-level view of a journey while clearly identifying where opportunities for improvement exist.

Categorizing these opportunities through cognitive science defines where we’re trying to design for intuition, which is what we are striving for. This helps give further clarity to Product Owners and stakeholders when they’re deliberating the value of proposed solutions.

We want to empathize and design for users, but it’s very counter-productive to submissively appease them. A good user experience is most noticeable when it’s absent. Try looking at the user’s journey from a different angle and consider the benefits.

To loosely quote Emerson – it’s about the journey not the destination.