Practical Application of Multi-Select Inputs

More than two million lives rely on Machinify's Portal to pay, process, and verify insurance claims. A big part of Machinify's Portal is adding multiple diagnoses to a single request, record, or claim.

After seeing the current experience, it was clear something needed to be done to help speed up the process and make things a bit clearer.

But what exactly did we need to do, and how would we get there? This case study breaks down how to identify text entry problems in your UI and how to choose a proper solution for them.

Look at the three images below. You'll notice that the first screen asks the question, "What's the diagnosis?". This is problematic because there is a distinction between a primary diagnosis and all other diagnoses.

The second screen asks the provider if they want to add an additional diagnosis. This is acceptable, but it creates unnecessary friction.

The last screen shows the field in the form that allows a provider to enter the secondary diagnosis. The issue here is that the concept of a primary diagnosis was never explained.

When you land here, you can loop back to the second screen, as shown in the diagram below. This restarts the loop, asking you if you'd like to add another diagnosis.

The current method of entering a diagnosis in the form is to enter a diagnosis into a text field one at a-time. This was okay; however, you could not see the entire list of all your entries simultaneously. This was important because providers wanted to make sure they didn't miss anything.

Another issue is clarity around the distinction between primary and secondary diagnoses. There was no clear understanding of the difference between the two.

Now that we understood the problem, it was easy to start laying out some new requirements for the experience.

Here's a list of what we knew we wanted: a text input that meets the following requirements:

This means we can adjust the diagram above to look something like the updated diagram below.

Before we can understand the visual output of the UI, we need to understand which text input type works based on the new requirements we laid out above. Here's a list of each type.

View Text Fields Spec

Based on our requirements, we need a multi-select text input. In addition to the multi-select text input, you will need to combine some elements, as seen in the dropdown and search inputs. Let's breakdown the anatomy of the current input to see what elements carry over to the new design.

The current design shows a container and a label. These are both elements we will need. Screen 2 has binary buttons. We won't need those.

In addition to the container and label, we are adding chips to a stackable list with slots for the primary diagnosis and the secondary diagnosis.

View Chips Spec

The result is an experience that worked the way the provider needed it to. The way providers entered information was fast, and it required an easy way to do this in one single view.

Look at the images below to see how the flow changed.

One improvement was using the right placeholder text that helps explain the difference between a primary and secondary diagnosis. Using a badge for the primary diagnosis also helped ground the concept that the first entry was the primary diagnosis.

As designers, we tend to not see that a good majority of the skills required are things like analytical thinking and problem solving.

Being able to analyze the problem and break down the root cause allowed me to move faster and come up with a fix that met the goals of the user and the requirements of the business. That's why design is so challenging and rewarding.