Nielsen Norman Group has long argued that dropdown lists are one of the most overused patterns in form design — convenient for the designer, often costly for the user. I wanted to test that claim against a real, high-stakes form: an ASPCA pet insurance claim, where the dropdown in question isn't picking a shipping state. It's asking a worried, non-medical pet owner to correctly self-diagnose their animal from a wall of alphabetized conditions before they can even submit a claim.
The Claim Form
The "condition" field on the ASPCA claim form lists 326 total conditions, sorted strictly A–Z — including at least 8 outright duplicate entries. For a field this long, alphabetical order isn't neutral. It's a sequencing choice that only works if the user already knows the correct word for what's wrong with their pet.
Most people filing a claim aren't veterinarians. They know their dog is vomiting, or scratching, or limping — not that the billing code they need is filed under "G" for Gastroenteritis rather than "D" for Dietary Indiscretion. The form assumes clinical vocabulary the user doesn't have, then punishes them with 300+ rows for not having it.
Same Diagnosis, Different Name
Scattered across the alphabet — never adjacent, never cross-referenced — are pairs of entries that describe the same or overlapping condition. Because the list only sorts by spelling, a user scanning for one will likely never see the other.
Both routinely describe the same presenting symptoms at the vet. A pet owner reading two discharge papers with different wording has no way to know these aren't distinct claim categories — they're 218 alphabetical rows apart.
Both describe stomach inflammation — dietary indiscretion is usually the cause, gastroenteritis the resulting diagnosis. The form presents them as three unrelated, competing options with no indication one often produces the other.
Feel It Yourself
Same scenario, three patterns: a dog that won't stop scratching and has a hot, irritated patch of skin. You don't know the clinical term is "Hot Spot." Try each tab and notice where you get stuck.
Three Ways This Fails
NN/g's research on long dropdowns describes what users do when the option they're looking for isn't where they expect it. All three show up in claim-form behavior, just with insurance-specific consequences.
-
01
Exhaustive review
The user reads all 326 rows top to bottom, comparing near-duplicates by hand, to make sure they haven't missed the "right" one — turning a 30-second field into a multi-minute diagnostic exercise.
-
02
Settle for close enough
They pick the nearest-sounding term. If it's the wrong billing category, the claim can be flagged, under-reimbursed, or kicked back for correction — a delay entirely manufactured by the form, not the medical facts.
-
03
Abandon the field
They leave it blank and call the vet's office or ASPCA support to ask which category applies — converting a self-serve digital claim into a phone call, for both the pet owner and the support team.
When the List Itself Is the Problem
None of this means dropdowns are wrong. It means the pattern only fits certain conditions, and the ASPCA form picked the wrong one. Mapping list size against how familiar the user already is with the exact wording gives a clearer picture of what actually belongs where.
Classic dropdown
Finite, known options. Browsing the full list is itself useful — it can surface offerings the user didn't know existed.
e.g. Hy-Line Cruises' destination listText field or light combobox
The user already knows exactly what they'll type. Typing is faster than scrolling, and autocomplete just speeds confirmation.
e.g. booking travel, entering an addressDropdown + plain-language help
Short enough to scan, but options still need a definition or example the user can match against, not just a label.
e.g. saved payment method, language selectorGuided triage, search as shortcut
Recall is the failure point, not scroll length. Branch on a plain-language category first, then show a short list — keep search available for the minority who already know the term.
e.g. pet insurance claim conditionsA combobox alone doesn't fix synonym pairs like cystitis/UTI. Those need to be merged into one searchable entry before the interaction layer can help — the content problem has to be solved first.
The same logic applies to apparel sizing: showing what's in stock before the size is picked (not after "add to cart") removes a failure mode this form shares — discovering the real answer too late.
A Different Form for ASPCA
The fix isn't a redesign of the whole claims flow — it's a re-sequencing of one field, in this order:
Lead with guided triage, not a list. Ask where the issue is — digestive, skin & coat, mobility, breathing, and so on — before showing any conditions at all. This is recognition over recall: the user isn't generating a diagnosis from memory, they're picking from a handful of visible, plain-language buckets. It also caps the list they eventually see at 10–20 items instead of 326.
Offer search as a shortcut, not the default. Owners who already know the clinical term shouldn't be forced through two clicks to get there. A synonym-tagged combobox stays available as an explicit "search directly" option alongside the guided flow — it just isn't the first thing everyone sees.
Merge the duplicates at the data layer. Collapsing 8 synonym pairs into single entries with alternate terms attached (so "cystitis," "bladder infection," and "UTI" all resolve to one row) has to happen regardless of which interaction pattern sits on top of it.
Always leave a manual fallback. "Not sure — describe it and we'll categorize it" stays visible throughout, for the cases neither triage nor search resolves. Logged descriptions become the backlog for expanding the taxonomy over time.
A free-text box that matches natural language directly to a condition is worth building eventually — but as a layer added on top of guided triage, not a replacement for it. Symptom-checker tools that rely on free text alone tend to follow it with structured clarifying questions before committing to a category, for the same reason: an unscaffolded guess carries more risk here than in a typical product search bar, because a wrong match can misroute a real claim.
The goal isn't a shorter list. It's a sequence that never asks the user for a word they don't have.
This one field is a small piece of a much larger claims experience — but it's a clean example of how a pattern that works fine at 12 items can quietly become a support-ticket generator at 326.