Designing software to help claims managers process claims faster
Our company was designing and building claims management software for a large health insurance company that would help their claims managers overcome challenges with their current workflow. My job was to research and design our software solution so our company could use my prototypes to secure more funding.
Our business need
My company was a mid-sized startup spending its current investment money on two software products—a patient billing system and claims management software. The company had already hired a handful of engineers, product managers and designers, so that meant we were making progress but also running out of money. The product managers and I felt a lot of pressure to secure a customer for our claims management software in order to keep ourselves in business.
The most promising strategy we were working on was based on a relationship we had with a large insurance company in California. Our immediate goal was to create a real-as-possible prototype to convince the insurance company to commit further to our team. I was the lead designer on the project and my job was to do what research I could, then design a thoughtful prototype that would impress the insurance company.
The research
I had to push hard for research, insurance companies are secretive and hard to get access to, but after convincing my two product managers to help, we were able to have four remote chair-side visits and one on-site visit.
Four remote chair-sides
During the remote chair-sides the product managers and myself would hop on a video call with a claims manager for an hour or two. During the call we would ask the claims manager to share their computer screen with us and walk us through their daily tasks. During the call we would ask a lot of questions about their work.
I realized very quickly that claims management was way over my head. Claims management was so complex and specialized that it was difficult to understand at first, but as the chair-sides went on my understanding increased more and more.
During the chair-sides we got to see the software that the claims managers currently used to manage claims and we learned the short-comings of that software. We’d often ask the claims manager to deep dive into specific areas of their workflow we didn’t understand and the claims manager would show us, helping us see problems we could solve for them.
One on-site visit
In addition to the remote chair-sides I was able to physically visit the claims managers at the insurance company on one occasion. The people who went on-site were myself, our VP of design and one of our product managers. During the on-site visit we were able to walk through the offices where our claim managers worked every day and sit with them while they showed us how they worked.
During the on-site visit we got to see what our users saw every day, what motivated them and we got to learn about them as people. All that knowledge and experience gave us empathy for them that we didn’t have before. Later, when I went to design the claims management software I could easily summon the claims managers in my mind and imagine how they would use what I was designing.
Understanding the user’s needs
Claims management was a very complex process that took claims managers months of training to be able to do, and more, it took them several more months after that to actually get good at it. But after that initial training period the claims managers would then spend many years managing claims. Those initial months of getting used to our software was a fraction of the time they would spend actually using our software. That meant I needed to design the software for advanced users, not beginners, because it was the advanced users who would be spending the most time in the software.
Designing for advanced users is very different than designing for beginning users. It meant I needed to design for the hundredth day of use, not the first day of use. In fact, advanced users were going to be spending so much time in my designs that they’d start to memorize where everything was, making them more and more irritated by every little thing that made them take more time on task then they absolutely needed to. I’ll be pointing out specific design decisions I made for advanced users later in this article.
The claims manager’s setup
The claims managers had a nice cubicle in an open office with other claims managers. On their desk they had a large monitor attached to a strong and capable Windows PC. The claims managers used their computer eight hours a day, five days a week for years and years. That meant they were very familiar with their computer and it also meant they were unafraid to personally change their computer settings to make their job easier.
One specific setting they changed on their computer was turning up the resolution of their monitors really high, that way they could squeeze as many windows on the screen as possible. Having multiple windows open and viewable at the same time helped the claims managers jump back and forth between several pages, documents, and applications to compare, contrast and find what they were looking for. My designs needed take advantage of that larger screen real estate since it mattered so much to my users.
What a claims manager does
Put simply, a claims manager decided if a medical claim would get paid or not. The insurance company they worked for processed thousands of claims a day and the insurance company had software in place to automate the payment of many of those claims. But some claims were too complex for the automation software to process and so those complex claims would need to be processed by a real person. It was claims manager’s job to manually process those complex claims to decide if they should get paid or not.
Problem 1 — Scrolling and switching applications
The first problem our software needed to solve was that our user’s current software didn’t have all the information they needed to see on the same screen at the same time. The claims managers had to constantly scroll and switch between applications to see important information about the claim they were reviewing. Because our users were advanced users all that scrolling and window switching created a lot of frustration and time wasted.
When the claims managers were reviewing a claim they needed to be able to switch back and forth between the following information:
- General claim information
- Claim lines
- Medical policies
- Medical records
All this information helped the claims managers understand everything in the claim as well as review the insurance company’s medical policy to decide whether the claim should get paid or not. The claim information they were reviewing was dense, long and complicated. But the claims manager still needed to read and process all of it, so they had to jump back and forth between the information constantly.
The wireframe below depicts how the claims manager’s current software was forcing them to do a lot of scrolling and application switching to review all the information they needed to see.
Solution — All in one application
My design solution was simple in concept, just put all the information the user needed to see in one application, on one screen, all at the same time.
With everything the user needed to see on one screen at the same time, the time it took for them to jump back and forth between information dramatically decreased making their workflow faster and easier.
Designing so much information on the screen at the same time required getting the information architecture right to keep everything from becoming too overwhelming.
Getting the information architecture right
One of the challenges with putting all the information on the same screen at the same time was to make it simple enough to read and understand.
Our users were all based in the United States and read left to right and top to bottom, so that meant I could lay out the interface assuming the user understood that pattern. Things on the left were parent to things on the right and also parent to things below it.
I designed the new interface to show clear parent-child relationships between the claim header, general claim info, claim lines, medical records and medical policies as shown in the wireframe below.
Reducing the visual noise
When you put so much information on the screen at the same time it’s critical to keep the number of visual variations to a minimum so the user doesn’t get overwhelmed by everything they are looking at. To help the user not get overwhelmed I limited all the visuals on the screen from color to font to imagery.
As a general target I aimed to keep every visual attribute in the interface down to five variations or less:
- Only one font — Every piece of text in the interface is the one font “Inter,” except for the logo which was “Poppins.” I was ok with the logo being a different font because it’s the one piece of text that needs to convey our brand whereas all the other text needed to focus on noise reduction through uniformity.
- Primarily one font size — Because the majority of the interface is text it’s better to have all the text be uniform in size, that way the user stays focused on the text and is not distracted by the different sizes. I also made the general text size smaller than usual because this user was an advanced user who was willing to adjust their eyes to the smaller size in order to see more information on the screen at the same time.
- Four other text sizes, used sparingly — I reduced all the other font sizes on the screen to just four sizes: 12, 14, 18 and 24. These larger sizes were used only when they helped the user navigate the information faster and easier. I used these other sizes on elements like headers, tabs and navigation.
- Background completely white and empty—When you have so much text on the screen at the same time any other color than white in the background will become a major distraction. The reasons to typically put other colors in the background have to do with alignment and grouping which I was able to solve through other methods.
- Borders and lines used sparingly — Having borders and lines to separate parts of the interface can become just as distracting as using background colors. It’s best to remove all borders and lines until you discover the borders and lines that you absolutely can’t live without. In this interface I was able to reduce borders and lines down to only four locations: (1) Between the application header and the main body of the interface, (2) Between the sub navigation rows in the claim, (3) Between the sub-tabs and their content, and (4) Between the claim line details and the medical policy.
- Colors reduced to only five specific instances — Color is more distracting than any other visual attribute in an interface, so color needs to be reduced to the bare minimum. In my interface I was able to reduce color to the following: (1) The logo needed color to establish the brand for the application, especially since I wasn’t using branding anywhere else, (2) Interactive elements used blue to show what could be clicked on, (3) Colored icons gave weight to individual objects that the user needed to quickly recognize, and (4) The medical records and medical policies used color because they were special to the user and their workflow so they needed to stand out.
- Limited icons and imagery— Icons and images are often the second most distracting visual attributes in an interface after color. In this interface I was able to reduce icon and imagery to the following: (1) The logo because it needed to establish our brand, (2) An icon for a claim and a claim line, (3) An icon for medical records that were added, and (4) An icon for the medical policy because of its importance.
What was new and specific to our application
In addition to combining all the things the claims manager needed to see on the screen at the same time, our software also gave users new functionality to improve their workflow.
Problem 2—Finding the correct medical policy
The insurance company had detailed medical policies that outlined what specific procedures on a claim needed to be in order to get paid. For example, if a provider amputated a limp on a patient there are hundreds of complicated steps that have to occur for that operation. When the provider wanted to get paid for the amputation the insurance company’s medical policy outlined the rules and standards for every step the provider performed during the amputation. If the claim says the provider didn’t perform a specific procedure exactly how the medical policy outlined then the provider didn’t get paid for that item.
When a claim went to the claims managers it was their job to know the applicable medical policies and manually verify that the provider followed every step of the policy. If parts of the claim did not follow the medical policy it was then the claims manager’s job to reject that part of the claim.
Using their current software the claims managers was forced to leave their claim software and navigate the company’s file server to try and find the correct medical policy.
Solution — Automatically find and show the correct medical policy
Our solution was to import all the medical policies into our software and automatically display them along with the claim. To show the correct medical policy we needed to import all the medical policies into our database and then program our software to automatically determine which policies went with which claims.
With this new functionality the claims manager no longer had to figure out what policy applied, go find the policy themselves, and switch between applications to read the policy while reviewing the claim.
Problem 3 — Necessary medical records weren’t included
A standard medical claim is basically just an itemized bill for a specific set of procedures, the claim does not contain other medical history for the patient. The problem was that the medical policies the claims managers used often included rules about the medical history of the patient, not just rules for the procedures in the claim. That meant the claims manager had to also get access to the medical history of the patient.
The patient’s other medical history was typically in the the provider’s other medical software and the provider’s physical records. The claims managers had no direct access to the that information so they had to call the provider to get them to send the additional medical history they needed.
The providers would eventually send the additional medical history, because they knew it was necessary to get paid, but it often took a long time and sometimes the information would be in a form that was hard to read and understand.
Solution — Automatically find and store other medical records
Our software had functionality that would automatically pull additional medical records from the provider’s software before the claims manager even looked at the claim. That way when the claims manager first opened the claim to review it, it already had all the additional medical information they needed to process the claim.
Problem 4—No patient facesheet
A patient facesheet is a common medical document that centralizes all the medical history about a single patient on one screen. In their current software our users could only see the medical history for a patient one claim at a time. In order to see the full medical history for a patient the claims manager had to painstakingly navigate back and forth between all the claims for that patient.
Solution—Automatically generate a patient facesheet
Our software was already adding medical records to claims so we decided to also aggregate those medical records into a single patient facesheet. Our patient facesheet would show all the medical history we had for a patient in one place rather then having it spread out in different claims. With the new patient facesheet the claims manager could easily switch back and forth between a single screen with the patient’s full medical history and the individual claim line they were reviewing.
Summary
I was tasked with designing claims management software to help a large insurance company’s claims managers process complex medical claims more efficiently. Based on my research I designed an interface that consolidated all the relevant information onto a single screen, reducing the need for claims managers to scroll and switch between applications.
Our software also introduced new functionality that automatically displayed the correct medical policy and pulled in necessary medical records and patient history. This eliminated the need for the case managers to manually search for them and it helped claims managers make more informed decisions quickly.
The end result was a tool that not only addressed their immediate workflow frustrations but also empowered them with more comprehensive and efficient access to the data they needed to process claims faster and more efficiently.
To read more about my design work also take a look at Aloe budget app — a case study
