Last updated: December 10, 2021.
Having signed a strict non-disclosure agreement, I am unable to disclose strategic information or design artifacts I did for this medical billing client.
A large medical billing company, who accounts for more than 1 billion procedures annually, acquired a 35-year old software application still used by thousands of medical facilities and hospitals. This recently-acquired software expanded their marketshare into middle markets. Five years had passed without a single new client subscribing to use the software - they were just coasting on pre-existing clients. In September, 2020, a software architect, product manager, and I (UX designer) began the groundwork for a replatform. It was time to modernize this software.
The software looked a lot like this (this is not the actual software). Amazingly, it accounted for millions of procedures every year:
Onboarding new clients to this software entails 40-100 hours of customer support training, kicked off by an entire-week, in-person training program. After this, customer support is still frequently needed. This green screen software is built on the legacy AS 400 tech stack and has been "maintained to death" - it has 3,700+ pages of product documentation.
Nothing about the application or the documentation is intuitive. It was built ground-up with little consideration to human usability. It originated in an era before people used a mouse and has a menu-based, green screen software. After decades of new functionality piled on top of old functionality, the structure of the application does not make sense.
Navigation within this application is horrendous. The top level navigation includes over 30 sections of the application. It technically consists of multiple, independently-run applications. Most of the typical biller workflows entailed hopping between separate modules and pages scattered throughout the software. Settings and configurations are set in several modules at completely different places scattered throughout the app.
Work queues of different formats are found in separate modules scattered throughout - and not all routine tasks the billers need to complete are designed for in the application. It requires all kinds of unintuitive work arounds. Biller work flows often entail manually running special reports first to know which accounts needed work to be done.
There are highly-problematic glitches that billing teams need to plan around so as not to disrupt their work. Accidental keystrokes can inactivate data sets, causing errors in other billing teammates's work. Trying to set up a system often consists of troubleshooting complex errors requiring hours of the customer support personnel's time.
Modernized, cloud-based re-platform.
Without a client-side Product Owner, we operated at 60-70% efficiency as the design process entailed constant requirements gathering. While I was the UX designer on the account, I acted simultaneously as a quasi-Product Owner as the design requirements were formulated by me and verified by the client-side stakeholders.
Very quickly during the discovery portion of the engagement we realized a "replatform" was not the right strategy to pursue. The client needed to create a new product with a reduced feature set and the old product needed to be sunset after onboarding the billers to either the new downmarket web-based solution or their core upper-market product.
After three months of research, discovery, strategy, and scoping, our three-person team added three engineers and a UI designer.
This is not the real thing, but it does display similar visualization technique I used.
I'm not allowed to share designs, but I can say it had a modern look somewhat like this:
Notes about our solution:
Here are a couple things I learned from this experience: