Form Controls for B2B SaaS: Which Input to Use When
Which control to use when: checkboxes, radios, dropdowns, toggles, sliders and uploads, decided by list length, timing and precision.
Written ByVlad Hrynchuk
Pick a form control by how many options exist, whether the user can choose more than one, and whether the choice takes effect immediately. Radio buttons and checkboxes show every option at once and suit short lists; a dropdown trades visibility for space once a list runs past roughly seven items; a toggle is for a setting that applies the moment it is flipped, not for a choice the user will submit later.
Key takeaways
- Count the options before choosing the control. Under about seven, show them all; past that, the space a dropdown saves is worth more than the visibility it costs.
- A toggle means the change happens now. Putting one inside a form with a Save button tells the user two different things about when their choice takes effect.
- Sliders are for approximate values a user can judge by eye. Any field where someone knows the exact number they want should let them type it.
- Most upload failures are state failures: no progress, no file-size rule until after the attempt, no way to remove the wrong file.
Forms are where B2B products spend their users' patience. Someone configuring a billing rule or filing a claim is not admiring the interface; they want the task finished and their attention back. The control you put in front of them decides how quickly that happens, and how often they finish with the wrong answer recorded.
Most of the decisions below are settled by three questions: how many options exist, whether more than one can be chosen, and whether the choice takes effect immediately or on submit.
Here's what this guide covers:
- Choosing between controls that show every option and controls that hide them
- The difference a toggle makes that a checkbox does not
- Numeric input, where sliders help and where they get in the way
- File upload, and the states teams forget to design
- What to check before the form ships
Show every option, or hide them
Radio buttons and checkboxes put the whole set in front of the user. Radios take one answer, checkboxes take several. Both let someone compare options without a click, which is why they work so well for short lists and so badly for long ones.
A dropdown reverses the trade. It costs a click and hides the options until then, and in exchange it takes one line of space no matter how long the list runs. The working threshold sits around seven options, which is where the visible list starts to dominate a dense screen. Past twenty, a plain dropdown stops working on its own and needs search: a combobox lets someone type to filter, which is the only sane way to pick a country, a currency, or an account from a list of four hundred.
A segmented control is worth reaching for when two to four options are mutually exclusive and the user will switch between them often. It reads as one object rather than a list, and the current state is visible without opening anything.
Nielsen Norman Group has been giving the same answer since 2004: checkboxes are for independent choices, radio buttons for one out of many. The rule is not in dispute. What teams get wrong is not the rule but the list length they apply it to.
| What you have | Control | Why |
|---|---|---|
| 2–5 options, one answer | Radio buttons | Every option readable without a click |
| 2–4 options the user switches between often | Segmented control | Reads as one object; current state always visible |
| Any number of options, several answers | Checkboxes | The only control that takes more than one |
| Roughly 7–20 options, one answer | Dropdown | One line of space beats seeing them all |
| More than 20 options | Combobox | Typing to filter is faster than scrolling a list |
| One setting that applies on the spot | Toggle | The flip is the action, so no save step |
| One yes-or-no with consequences | Two radio buttons | Both outcomes stay visible and nothing is implied |
Two smaller traps. A single checkbox for a yes-or-no question hides the second option, so the user never sees what "unchecked" means; two radio buttons make both states explicit, which matters for anything consequential. And a set of radios with no default forces a deliberate choice, which is right for a legal consent and wrong for a preference where most users want the obvious answer.
The toggle is a promise about timing
A toggle says the change happens now. It belongs in settings, where flipping it is the action. A checkbox says the choice is recorded and applied when the user submits.
This is the distinction teams collapse most often, usually by putting toggles in a form with a Save button. The interface then tells the user two different things: the toggle says done, the button says not yet. People leave the page believing the change stuck.
If the setting needs a save step, use a checkbox. If it applies immediately, use a toggle and confirm it did, with a toast or an inline state change that names what just happened.
Dub's notification settings. Two toggles, no save button: the flip is the action. Source: mobbin.com
Loom's default video settings. Four toggles above a Save defaults button, and the release note tells users to toggle their preferences and then click save. Defensible here, because these are defaults for future recordings rather than a live setting, but the control now means something different from the same toggle elsewhere in the product. Source: mobbin.com
Numbers: type, drag, or step
A slider works when the value is approximate and the user judges it by eye: a price ceiling, a volume, an opacity. It stops working the moment precision matters. Someone who knows they need 250 GB should not be dragging toward it, and on a touch screen the drag is a fine-motor task that WCAG target-size guidance exists to protect people from.
The usual fix is to pair the two: a slider for the rough position and an input field that accepts a typed number, each reflecting the other.
A stepper suits small integers with a natural unit, like seats or quantity. Once the plausible range runs past about twenty, the buttons become a chore and typing wins.
File upload is mostly states
File upload fails in the same four places in most products, and none of them is the upload itself.
The rules arrive too late. Size limits and accepted formats belong next to the control before the user picks a file, not in an error after a two-minute wait. Progress is missing or fake: a real progress bar needs a percentage tied to bytes transferred, and when the number is genuinely unknown a loading spinner is the honest control. There is no way back, because the user picked the wrong file and the interface offers no remove. And the error state says "upload failed" without saying whether to try again, use a different format, or split the file.
OpenPhone states what to attach and the 10MB ceiling before the user opens a file picker. Source: mobbin.com
ClassPass ships the browser default. No formats, no size limit, nothing to read until something fails. Source: mobbin.com
| Failure | What the user gets | What it should do |
|---|---|---|
| Rules stated late | An error after the upload finishes | Formats and size limit beside the control, before the picker opens |
| No real progress | A spinner that says nothing about time | A progress bar tied to bytes, or an honest spinner when the total is unknown |
| No way back | The wrong file attached and stuck | Remove and replace on every uploaded item |
| Unhelpful error | "Upload failed" | The reason and the next step: retry, convert, or split |
Drag-and-drop is a convenience layered on top, never the only route. GOV.UK's guidance on file upload keeps the native control underneath for exactly this reason: it already works with a keyboard and a screen reader.
What to check before it ships
Run the form once with the mouse unplugged. Every control should be reachable with Tab, operable with Space or Enter, and its label should be read out with it. Custom controls assembled from generic elements are where this breaks, and the ARIA Authoring Practices Guide documents the keyboard behaviour each pattern owes the user.
Then check the boring states. What the form looks like empty, what a validation message says and when it appears, and whether an error names the fix rather than the failure. Baymard's research on form usability found that validation shown at the moment of the mistake outperforms validation shown on submit, which is the difference between a user correcting one field and a user rereading a form.
The controls in this guide are the ones a design system should settle once, so every team stops re-deciding them. If yours is still an inconsistent set of one-off components, our design system service exists for that, and our guide to choosing a design system covers what to build before you need one. For the broader picture of how these decisions add up across a product, the SaaS UI/UX design guide is the place to start.
