Don't Reinvent the Checkbox

A portfolio piece: a beautiful circular date selector, the days arranged around a dial, dragging to pick a range. It took two weeks. In testing, four out of five people couldn't select next Tuesday, and the fifth managed it by accident.

The designer wasn't untalented — the thing is genuinely lovely. They spent the budget in the wrong place. Two weeks went into a control that a native date field solves for free, and the actual problem of that product, whatever it was, got whatever time was left.

Originality is a budget

Jakob's law said it already: people's expectations were built on other products. Every convention you break costs relearning, confusion and support tickets.

That's not an argument for having no ideas. It's an argument about allocation:

Be inventive where your product is different. Be boring everywhere else.

Your product presumably does one or two things nobody else does. That's where the invention belongs — in the core interaction that makes it worth using. The login, the settings, the date picker, the table, the tabs: these are solved problems, and every hour spent making them special is an hour subtracted from the thing you're actually selling.

There's a hidden benefit too. Conventional controls come with decades of accumulated handling of things you'll forget: keyboard access, screen readers, mobile keyboards, right-to-left languages, autofill, high contrast mode. A custom control starts at zero on all of them.

Choosing the right control

Half of interaction design is picking the correct standard control, and this is a decision table you can learn in one sitting.

Radio buttons — one choice from a few, all options visible, mutually exclusive. Under about five options. Always have a default selected.

Checkboxes — independent on/off choices; several can be true at once. A single checkbox is for a binary that takes effect when you save.

Select / dropdown — one from many, when the options are familiar and space matters. It costs a click and hides everything, so it's worse than radios for small sets — but far better than thirty radio buttons. Above roughly fifteen options, use a searchable combobox instead.

Toggle switch — a setting that takes effect immediately. This is the rule that gets broken constantly: if there's a Save button on the screen, you want a checkbox, not a switch. A switch that requires saving is a promise the interface didn't keep.

Segmented control — two to four mutually exclusive views, all visible, switching instantly. Great for "Day / Week / Month," bad for anything that needs five.

Slider — approximate values in a range where the exact number doesn't matter. If people need a specific figure, give them a number field, or both.

Stepper — small integer adjustments (quantity 1–10). Combine with a typable field so someone ordering forty doesn't tap forty times.

Date picker — always for dates. Also accept typing, because for a birthday nobody wants to page back thirty years.

The quick summary: under 5 options → radios; 5 to 15 → a select; over 15 → search. And: immediate effect → switch; applies on save → checkbox.

Forms, where most of the damage is

Forms are where products lose people, and the rules are well established and widely ignored.

One column. Multi-column forms break the reading path and get filled in the wrong order. The only fair exception is genuinely paired fields like city and postcode.

Labels above fields, always visible. Placeholder-as-label is the most persistent bad pattern in the industry: the label vanishes exactly when it's needed — while typing and when checking — it fails accessibility, and it makes filled and empty fields hard to tell apart.

Ask for less. Each field has a conversion cost. For every one, ask: can we derive it, default it, or ask later? The field you removed converts better than the field you shortened.

Mark the rare one. If most fields are required, mark the optional ones; if most are optional, mark the required ones. Marking every field with a star communicates nothing.

Validate at the right moment. Not on every keystroke — telling someone their email is invalid while they're on the third character is hostile. Validate when they leave the field, and re-validate as they fix it, so the error clears as soon as it's true.

Errors live next to the field. A summary at the top of a long form means scrolling to hunt. If you do have a summary, each item links to its field.

Don't split what people think of as one thing. Phone numbers, card numbers and dates in three boxes each break autofill, paste and every assistive technology. One field, and you parse it — Tesler's law says the code absorbs the complexity.

Let the browser help. Correct input types and autocomplete attributes give people autofill, the right mobile keyboard and password-manager support for free. Skipping them is a self-inflicted wound.

No reset button beside submit. It has no upside and one catastrophic downside.

Buttons say what they do

Label with the outcome, not the mechanism. "Create account," "Send invitation," "Delete 3 files" — never "Submit," "OK" or "Yes." A person should be able to read only the button and know what will happen. This matters most in dialogues, where "OK" next to a question of the form "Do you want to discard?" is genuinely ambiguous.

One primary per view. Everything else is secondary or a plain link. Two primaries mean the decision wasn't made.

Destructive actions look different and sit apart. Different treatment, physical distance from the common action, and ideally undo instead of confirmation.

Beware the disabled button. A greyed-out button with no explanation is a dead end: the person can't tell what's missing, and disabled controls are often invisible to screen readers and fail contrast. Usually better to leave it enabled and, on click, show exactly what's incomplete.

Navigation patterns worth knowing

Tabs — parallel views of the same object; you can switch freely, nothing is lost. Not for steps.

Steps / wizard — a sequence with an order, ideally with progress shown and back allowed. Use when the task genuinely has an order; don't split a five-field form into four steps to look friendly.

Accordion — a long list where people need one section at a time. Bad for content people compare, because you can't see two at once.

Modal dialogue — a decision that genuinely blocks everything else. Modals are also the standard escape hatch for a designer who couldn't fit something into the flow, and each one interrupts, traps keyboard focus if built badly, and behaves poorly on small screens. Before adding one, ask whether it could be inline.

Hidden menus. A single icon that conceals the whole navigation saves space and reliably reduces discovery — people use what they can see. On mobile, three to five destinations belong in a visible bottom bar; hide the rest, not the important ones.

When to break a convention

Not never. Three conditions, all of them:

The convention actively harms the core task — not "feels dated," but demonstrably slower or more error-prone for the thing your product exists to do.
You have tested the alternative with real people who don't work with you, and it won.
It's learnable once and then stays learned. A novelty that has to be re-figured-out every visit is a permanent tax.

Most genuinely great interface inventions — direct manipulation, pull-to-refresh, the swipe-to-delete row — meet all three. Circular date pickers meet none.

In practice

Audit your switches. Find every toggle on a screen that also has a Save button. Each one is either a checkbox in the wrong clothes or a missing instant save.

Kill your placeholder labels. Move every placeholder-as-label above its field. It takes an hour and fixes a real accessibility failure.

Remove one form field this week. Derive it, default it, or ask later. Measure if you can.

Rewrite every "Submit," "OK" and "Yes." Put the outcome on the button. Read the dialogue with only the buttons visible and check that it still makes sense.

Count the primary buttons per screen. More than one means an unmade decision.

Replace a modal with an inline panel. Pick the least justified one and see what breaks. Usually nothing does.

Check yourself

Close the article and answer in your own words:

Why is originality a budget, and where should it be spent?
What do you inherit free by using a standard control, and lose by building your own?
When do you use radios, a select, and a searchable field?
What is the rule that distinguishes a toggle switch from a checkbox?
Name three reasons placeholder-as-label is a bad pattern.
Why is a disabled button often worse than an enabled one that explains itself?
What three conditions justify breaking a convention?

In short

Originality is a fixed budget: spend it on what makes your product different, use conventions everywhere else.
Standard controls come with keyboard, screen reader, mobile and autofill support that a custom one starts without.
Under 5 options radios, 5–15 a select, 15+ search. Immediate effect is a switch; applies-on-save is a checkbox.
Forms: one column, visible labels above fields, fewer fields, mark the rare case, validate on blur, errors beside the field, never split one value into three inputs, let the browser autofill.
Buttons carry the outcome, not "Submit." One primary per view, destructive actions separated, disabled buttons usually replaced with an explanation.
Tabs for parallel views, steps for real sequences, accordions when one at a time is fine, modals only for genuinely blocking decisions.
Break a convention only when it demonstrably harms the core task, your alternative tested better, and it's learned once and stays learned.