Inputs & forms

In a form, the number of fields is the drop-off rate. Asking now for things you could ask later costs you sign-ups. Sort required from optional during planning.

The width of a field is itself a hint. A postcode field as long as a name field confuses people. Size the width to the length of what you are collecting.

If there is a character limit, the remaining count has to be visible while typing. Finding out you are over 500 characters only after pressing submit is the worst possible version.

Clicking the label should put the cursor in the field (a for association in code). Without it, small targets like checkboxes become very hard to hit. Put it on the review checklist.

Never use a placeholder instead of a label. It vanishes as soon as someone types, leaving "wait, what was I filling in?". The faint grey also fails contrast. Label outside, placeholder for examples only.

Telling someone "at least 8 characters, must include a number" after the error is too late. The whole point of helper text is showing it before they type.

A native select can barely be styled. Draw a custom design in the mockup, then say "just use a select", and the developer has to build it from scratch — that is separate effort. With five or fewer options, radio buttons are often better.

Different from a select. Once there are dozens of options — banks, countries — a select is painful and a combobox is right. It is considerably harder to build than a select.

Firing a request on every keystroke hammers the server, so ask for debouncing (request only after a brief pause) at the same time. Leave it out and you get code that calls the server on every character.

A checkbox usually takes effect only when [Save] is pressed. If it should apply immediately, you want a switch. Skip this decision and you get support tickets saying "I ticked it but it did not save".

By convention, once selected you cannot return to nothing selected. If clearing must be possible, add a "None" option or use a select. Pre-selecting a sensible default reduces drop-off.

A switch applies immediately; a checkbox applies on save — that is the difference that matters. Notification settings that take effect at once are a switch; terms agreement submitted with the form is a checkbox. This comes up in QA constantly.

Easily confused with tabs because they look alike, but tabs switch content while a segmented control picks a value. Two to four items suits it; long labels get clipped.

In Korean practice, "slider" far more often means a carousel — the banner that slides left and right. "Add a main slider" is almost certainly about a banner carousel. Always confirm.

Native HTML gives you only one handle, so a two-handle version has to be built or pulled from a library. It looks simple but it costs real effort.

The name collides with the step indicator. If "stepper" comes up in a meeting, check which one. And typing must also work — nobody should press a button 50 times to order 50.

Choosing a span is separately called a range picker. The browser's built-in calendar cannot be styled and looks different in every browser — matching the mockup means building your own.

The spec must state allowed file types, maximum size, and whether multiple files are allowed. Leave it out and the developer picks, and later you get "files over 10MB will not upload".

Chips can be pressed; tags usually cannot. That is the difference. Filters as chips make the current selection visible at a glance.

Similar in appearance to a chip, but a tag is usually not a click target. If clicking should open a list for that tag, write that behaviour into the spec.

You have to decide when it runs: ① while typing ② when leaving the field ③ on submit. Red errors appearing mid-typing are irritating, so ② (on blur) is usually the safe default.

Rather than telling people "enter it without hyphens", a good form tidies up whatever they type. Apply it to phone numbers, card numbers, registration numbers and amounts.

Very common in client conversations. "What is the CTA for this section?" means "what do you actually want people to do on this screen?". Labels that state the action convert better than "OK".

As a rule, one primary per screen. Make everything solid because everything is important and nothing is. Destructive actions such as delete get red on their own.

Names differ by company. Material says Outlined/Text; some teams say Ghost/Tertiary. There is no right answer — what matters is picking one set and using it consistently within the project.

An icon alone often fails to convey meaning. Go text-free only for widely understood icons (X, search, cart) and label the rest. And even when nothing is visible, a screen-reader name is mandatory.