How to transform legacy health software into a modern user interface

Is your software looking like it belongs in the 90s or today? You’re not the only one who thinks so. It might still work. It is technically very powerful. There are also loyal customers. However, the design process has been driven for many years by developers.

This is a common occurrence in the healthcare industry. Why? Because health is complicated. Software companies have limited resources and are subject to changing regulations. They also have a resistant customer base. Health software has been subject to rapid change over many years. Your once-clean product suddenly looks messy as you add more features to it.

What does this mean? Is the user experience really important?

Although you may get away with it temporarily, sticking with an old-fashioned interface could have serious long-term consequences.

1. Slowing growth – While it might be difficult for customers using the product for years, it will be much easier for new customers to switch to a more modern system than an older one. Your market share will be eroded over time by competitors who invest in user experience.
2. Higher development costs – It will take more time to update or modify an outdated code base or interface. Too often, this technical knowledge is held by a small number of long-term employees. This creates a problem if they leave.
3. It’s hard to attract talent – The battle to find talented developers and designers in Australia will only intensify. The best thing about health is that it offers people a more fulfilling pursuit than many other industries. Companies must provide a modern and innovative environment for talented employees. A legacy product without an inspiring roadmap is what will make a potential employee turn away.

It is not a matter of whether or not you should redesign your website, but when.

How should you approach that moment? Do a complete redesign and hope customers love it. You could also incrementally update the software piece by piece. Perhaps you could design a cloud-based version alongside existing software and then gradually migrate customers to it? You could also create a mobile version and later extend it to a desktop one.

What should you do first?

None of these is the right place. It shouldn’t be a new design solution but rather a description of the problem that you are trying to solve.

People are quick to get into solution mode after deciding to redesign. Why? Because they assume that they are experts in what needs to change. For years, they have been listening to customers’ feedback. They have formed their own opinions. However, relying on personal opinions and anecdotal evidence is not a good place for decision-making.

This framework will help you gain a deeper understanding of your customers’ use of your software. It will allow you to understand their motivations, gains, and, most importantly, your perspective. There are three parts to the framework:

1. Dissect This stage allows you to take a holistic look at your software. This is done by separating each workflow component into a card and giving the card a name that reflects its broad role (e.g. data entry and a description (e.g. adding a patient. After you have completed this exercise for all aspects of your software, it’s time to organize the cards into common themes. You now have a 10,000ft view and can create a plan for evaluating the entire experience.
2. Collect– This is the next step in gathering data from many sources. These data generally come from two areas. First, qualitative data is obtained from observing users using your software. This is sometimes known as user testing. This allows you to gain deep insights from a small number of users. This is combined with quantitative data to show the wider usage patterns you have observed. Recall your 10,000ft perspective to plan this stage. Consider how you will collect data and assess each key area.
3. Analysis – Once you have enough data, it is time to determine what it all means. This analysis will often be refined into a hierarchical list of information. The top of the hierarchy will contain a phrase describing the desired software experience (e.g. “Our software is all about speed, accuracy“. Set design principles may support this statement. You will describe the recent experience against these principles and what needs to change, usually at the component level.

All of this leads to the right design brief. The brief describes how your users will experience your software and the plan for what changes are needed to get there. This will give your team the direction and confidence it needs to move your software forward from the 1990s.