Opinion: How to turn legacy health software into a modern user experience

Written by Michael Trounce on 19 January 2017.

Does your software look like it belongs in the '90s? If it does, you’re not alone. Sure, maybe it still works. It's technically powerful and there are loyal customers, but for years the design has been driven by developers and it shows.

This happens a lot in the health industry. Why? Because health is complex. Software companies are working with limited resources, changing regulations, and a customer base that is highly resistant to change. This means that health software evolves sporadically over the course of many years. One feature after another is added to an already cluttered interface, and all of a sudden your once clean product looks like a mess.

So what? Does the user experience really matter?

While you might get away with it for a while, sticking with an old-fashioned interface can have serious long-term consequences:

Declining growth – It might not be easy for established customers to move to another product, particularly when it’s holding years of medical data, but it will almost certainly be easy for new customers to choose a modern experience over an outdated system. Over time, the competition who invest in their user experience will begin to erode your market share.

Increased development costs – Trying to do anything new or respond to a market change within an old code base and outdated interface will always take longer and cost more. And too often this technical knowledge sits with a few long-term staff members, which creates a huge problem if they move on.

Difficultly attracting talent – The fight to attract talented designers and developers in Australia is only going to intensify. Health has the advantage of offering people a more meaningful pursuit over many industries, but companies need to offer talented people an environment that feels innovative and modern. Nothing will turn a potential employee off more than a legacy product without an inspiring roadmap.

It’s not really a question of whether you should redesign, but when.

So when that time does come, how should you approach it? Bite the bullet and do a full redesign, hoping customers will embrace the new experience? Or incrementally redesign the existing software, piece by piece?

Maybe you should design a cloud-based version alongside the existing software and gradually move customers over? Or create a mobile version first and then eventually extend this design to a desktop version? Where should you start?

The answer is none of these places. The starting point shouldn’t be a new design solution, it should be a definition of the problem you’re trying to solve.

After a decision to redesign is made, people are quick to jump into solution mode, because people assume they know what needs to be changed. They’ve been hearing customers give them feedback for years. They’ve formed their own opinions. But decision-making that’s based predominately on anecdotal evidence and personal opinions is never a good place to start.

Here’s a framework we use that leads to much deeper understanding of how your customers are using your software – their understanding, their motives, their pains and their gains and most importantly, their perspective. The framework has three main parts:

Dissect – The purpose of this stage is to step back and take a holistic view of your software. The way to do this is to break apart each key component of workflow onto a card, then give this card a name based on its broad role (e.g. data entry) and a description (e.g. adding a new patient). Once you’ve done this for every aspect of your software, you’re ready to organise the cards into common themes and make connections between them. This exercise gives you a 10,000ft view of your software, and you’re now ready to create a plan to evaluate the whole experience.

Collect – The next stage involves gathering data from a broad set of sources. Generally, this data will come from two main areas. Firstly, you want qualitative data from observing people using your software, sometimes called user testing. This is all about acquiring deep insight from a small sample of users. You then combine this with a layer of quantitative data to see the larger scale usage patterns behind the behaviour you observed. When planning this stage, revisit your 10,000ft view to consider how you will gather data and evaluate each key area.

Analyse – After you’ve collected sufficient data it’s time to figure out what it all means. This analysis will usually be refined to a hierarchical set of information. At the top of the hierarchy will be some sort of phrase to describe the desired software experience (e.g. “our software is all about speed and accuracy”). You may also have a set of design principles that underpin this statement. Lower down in the hierarchy you’ll describe how the current experience is performing against these principles, and where changes need to be made, most likely at the component level you defined earlier.

The outcome of all this is the right design brief. A brief for how you want your users to experience your software, and a concrete plan of what needs to change to reach this state. And this will give your team the confidence and direction it needs to escape the '90s and transition your software into a modern user experience.

Michael Trounce is the general manager at Navy Design, a design consultancy focused on digital health projects.

Related articles

Comments

Hey Michael, I really liked your early point about "The starting point shouldn’t be a new design solution, it should be a definition of the problem you’re trying to solve." I'm trying to map that to the process you outline. I was expecting to see something about doing qualitative work with real users apart from evaluating the software. Like interviewing people to find out how they see the problem and what they want solved. Can you explain where this fits into the process you've described? Thanks