A dropdown is the wrong control whenever it hides choices the user would be better off seeing all at once, which happens at both ends of the option count. When the set is small enough to display as radio buttons, a dropdown buries those few choices behind an extra tap for no reason. When the set is huge, a dropdown turns selection into a scrolling marathon and should give way to a searchable field. The dropdown fits the comfortable middle, a moderate, familiar list, and fails at the extremes. Matching the control to the option count and the user’s need to see the choices is the whole decision.
The reasoning is that a dropdown’s defining feature, hiding its options until clicked, is sometimes a benefit and sometimes a liability, and the option count tells you which. For a handful of choices, hiding them costs the user a click to reveal what could have been visible all along, and it prevents the at-a-glance comparison that radio buttons offer for free, so you have added friction and removed clarity in one move. For an enormous list, the dropdown does hide usefully, but it forces the user to scroll and hunt through dozens or hundreds of entries when what they actually need is to type a few letters and filter. The control only earns its place when the list is long enough that showing everything would clutter, yet short enough that scrolling stays tolerable.
Concrete cases make the extremes obvious. A “preferred contact method” field with three values, phone, email, and text, belongs as three radio buttons the user can read and pick in a single glance, not a dropdown that hides three items behind a click. A “yes or no” question as a dropdown is almost a parody of the mistake. At the other end, a country selector with roughly two hundred entries is miserable as a plain dropdown, because finding “United Kingdom” means scrolling past everything above it, whereas a search-as-you-type field lets the user filter to it in three keystrokes. A list of, say, twelve to twenty familiar states or categories is where the dropdown genuinely shines, compact without being unsearchable.
Worth flagging: count is the primary signal but not the only one, because visibility need and context matter too. A small set that the user must compare carefully, like shipping speeds with prices, argues for radios even at the lower edge of “moderate,” so the choices sit side by side. Mobile shifts the math as well, since the native dropdown picker is reasonably ergonomic on a phone and can justify a slightly shorter list than it would on desktop. And a long but truly standard list the user knows by heart, like a month selector, can survive as a dropdown because familiarity offsets the scrolling. Judge the count first, then let visibility and context adjust the call.
So when you find yourself defaulting to a dropdown to keep a form tidy, stop and count the options. If they are few, lay them out as radio buttons so the user sees and compares them at once. If they are many, give the field search so the user types instead of scrolls. Keep the dropdown for the moderate, familiar middle where hiding the list is a genuine convenience. Match the control to the count and the visibility the choice deserves, and you will stop forcing tidy-looking dropdowns onto choices that needed to be seen.