Use a spinbutton for a small incrementable numeric value where users may click or press keys by one step; use a slider for relative position, text input for exact arbitrary entry, and select for named finite choices.
Use a spinbutton for a small incrementable numeric value where users may click or press keys by one step; use a slider for relative position, text input for exact arbitrary entry, and select for named finite choices.
Practice the judgment: Imagine this situation: A customer ID is rendered with plus and minus buttons, so keyboard arrows can change the identifier. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Spinbutton / numeric stepper | Slider | Text input | Select |
|---|---|---|---|---|
| UI or UX | UI + UX - Bounded incrementable numeric-value control | UI + UX - Single-value bounded range control | UI + UX - Single-line freeform data-entry control | UI + UX - Single-choice dropdown control |
| UI guidance | Render a visible label, editable numeric value, unit, lower and upper bounds, plus and minus controls, focus state, and warning, error, disabled, and read-only states. | Render one thumb on a track with a persistent label, visible current value, unit, min and max labels, focus state, and disabled or read-only state. | Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field. | Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state. |
| UX guidance | Use a spinbutton when users adjust a small count or bounded quantity by one or a few steps and still may need to type the exact number. | Help users adjust one bounded value quickly when the relative position or intensity matters. | Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text. | Help the person reach a clear task outcome. |
| Good UI | A Guests control shows label, value 2, minus and plus buttons, range 0 to 9, and a clear unit beside the field. | A Brightness slider shows 55%, dim and bright endpoint labels, visible focus, and a paired number input. | A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty. | Persistent label, hint text, visible selected value, readable options, and clear required validation state. |
| Bad UI | An account ID field has plus and minus buttons, implying the identifier can be stepped. | A two-stop slider is styled like a switch but lacks on/off semantics. | The only instruction is placeholder text that disappears when the user starts typing. | Placeholder as the only label. |
| Good UX | A user enters -3 for guests, the value is repaired to 0, and the interface explains the lower bound before submit. | A user adjusts brightness with arrow keys, types 65 in the number field, sees both controls synchronize, and gets a warning near battery-heavy values. | A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error. | Users can open, scan, choose one value, and review the selected value after close. |
| Bad UX | A user scrolls a page while an account number field is focused and accidentally changes the stored account ID. | A user is asked to choose Small, Medium, or Large through a numeric rail with hidden labels. | Validation fires on the first focus event and blocks typing before the user has had a chance to answer. | Hiding two obvious critical choices in a dropdown. |
| Best fit | Users adjust a small bounded count such as guests, copies, items, seats, nights, minutes, retries, or quantity. | Users adjust one bounded value such as brightness, volume, opacity, zoom, intensity, cost tolerance, or preference strength. | The answer is short and user-authored. | The user chooses one option from a moderate known list. |
| Avoid when | The value is a numeric-looking identifier, code, account number, card number, phone number, postal code, date, or formatted string. | Users need to enter an exact, arbitrary, or high-stakes number. | The answer is a paragraph, comment, address block, or explanation requiring multiple lines. | The option set is short and comparison matters. |
| Required state | Initial state with visible label, default value, unit, min, max, and step. | Initial value state with visible label, min, max, current value, and unit. | Empty untouched state with persistent label and optional hint. | Closed state with empty option or current selected value. |
| Accessibility burden | Expose the editable value as a spinbutton or native number input with a visible label. | Prefer native range input where possible. | Associate every text input with a visible label or equivalent accessible name that matches the visible question. | Prefer native semantics or implement equivalent name, role, state, and keyboard behavior. |
| Common misuse | Using a spinbutton for numeric-looking identifiers or codes. | Using a slider for a binary on/off choice. | Using placeholder text as the only label or instruction. | Using select to hide two or three obvious choices that should be compared. |