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.

Current Flow

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 Problem

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.

New Requirements

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:

1Searchable text inputBecause of the vast amounts of items to choose from, we need to be able to type the diagnosis and see matching results as we type.
2Compounding listAs content is added we need to see the list grow.
3DeletableAny item in the list needs to be deletable.
4Single questionThe diagnosis question should be confined to one text input and one question.
5Primary vs. secondaryWe need a way to inform the user of primary vs. secondary diagnoses.

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

Text Input Types

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.

TypeDescriptionMeets Requirements?
Text An input that allows plain text entry.No
Search An input that searches across a list of existing items.~
DateAn input that uses numbers only and is formatted as a date. No
PhoneAn input that uses numbers only and is formatted as a phone number. No
Number StepperAn input that has stepped controls that allows for adding or subtracting a number by single digits.No
PasswordAn input that masks its contents to remain private. No
Credit CardAn input that allows users, to enter a credit card number.No
Multi-selectAn input that allows users, to enter multiple items in a single text area.Yes
Dropdown SelectorAn input that presents a list of choices that users can choose from. ~
Text AreaAn input that allows for free-form paragraph type text. No
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.

Current Input Field Anatomy

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.

Multi-Select Anatomy

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
Updated Experience

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.