Go Back

Practical Application of Multi-Select Inputs

More than two million lives depend on Machinify's Portal to pay, process, and verify insurance claims. A key feature of Machinify's Portal is the ability to add multiple diagnoses to a single request, record, or healthcare insurance claim.


After reviewing the current user experience, it became clear that improvements were needed to streamline the process and increase clarity.

But what exactly needed to change, and how would we achieve that? This case study breaks down how to identify text entry issues in your UI and select the appropriate solutions.

Take a look at the three images below. In the first screen, the question "What's the diagnosis?" is problematic because it doesn't differentiate between a primary diagnosis and additional diagnoses.

The second screen asks the provider if they want to add another diagnosis. While this is acceptable, it introduces unnecessary friction.

In the third screen, there's a form field allowing the healthcare provider to enter a secondary diagnosis. The issue here is that the concept of a primary diagnosis was never properly explained.

When users reach this screen, they can loop back to the second screen, which restarts the process, asking if they'd like to add another diagnosis. This repetition creates inefficiency.

Currently, users enter each diagnosis one at a time into a text field. This approach was functional, but users couldn't view the entire list of diagnoses simultaneously. Providers expressed concern about potentially missing entries. Another key issue was the lack of clarity between the primary and secondary diagnoses, as the distinction was not well communicated.

Once I understood the problem, it was easier to define new requirements for it. Here's a list of new items needed to enhance this experience.

This allowed me to adjust the diagram above. The new diagram can be seen below.

Before I could design the visual output of the UI, I needed to determine which type of text input would best suit the new requirements. Here’s a breakdown of each option.

View Text Fields Spec

Based on the requirements, I need to chose a multi-select text input. In addition, elements from dropdowns and search inputs were incorporated into the new design. Let’s break down the anatomy of the current input to see what elements we retained in the redesign.

The current design features a container and a label, which I kept. However, the binary buttons from Screen 2 were removed.

In addition to the container and label I added chips to a stackable list with designated 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 I made 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.