Forms & Input

Forms are where products win or lose money. Baymard Institute's running average across studies puts cart abandonment at ~70%; in its periodically updated US survey of reasons for abandoning during checkout, extra costs (shipping/taxes/fees) lead at ~48%, forced account creation ~24%, and too-long/complicated checkout ~22% (baymard.com, checked 2026). Form design is conversion design.

Try it — why placeholders can't be labels. Fill the fields, then try to review what each one asks for.

Structure

Ask less: every field must justify its existence; optional fields are candidates for deletion; you can ask later (progressive profiling). Baymard: the average checkout shows ~11.3 form fields over ~5 steps but can typically be cut to 7–8 — field count matters more than step count.
One column (for typical forms): multi-column layouts cause skipped fields and broken scanning (Baymard; Wroblewski). One decision per moment; group related fields with clear section labels.
Multi-step vs. single page: chunk long forms into logical steps with a progress indicator; keep steps coherent (shipping / payment / review).
Multi-step state saving: persist each completed step (server-side or local storage) so back/refresh/session-drop never destroys entries; never re-ask for data already provided in the same flow — WCAG 2.2 3.3.7 Redundant Entry makes this a formal requirement (auto-populate or make it selectable). Offer "save and return later" on long applications.
Label placement: top-aligned labels are fastest to scan and best for translation/mobile (Wroblewski's and subsequent eye-tracking work). Never placeholder-as-label: it vanishes on input, taxing memory, and harms accessibility (NN/g; WCAG).

Fields & interaction

Correct input types/keyboards (email, tel, number); autofill enabled (autocomplete attributes — also WCAG 1.3.5 Identify Input Purpose); autocapitalize/autocorrect off where they break input (emails, codes).
Field width hints expected content length (ZIP short, address long).
Formatting: accept ANY reasonable format (spaces in card numbers, parentheses in phones) — parse, don't punish; auto-format as they type.
Sensible defaults & smart inference (city from ZIP; country from locale); remember returning users.
Address autocomplete pitfalls: suggestions miss new builds, rural addresses, and unit/apartment numbers — always allow full manual entry and editing of an accepted suggestion; don't force selection from the list; re-validate but never hard-block "unrecognized" addresses the user insists are real (Baymard's checkout research repeatedly flags overly strict address validation as an abandonment cause).
International addresses & names: address formats vary by country — set country first and adapt fields; make region/state and postal code optional where the country doesn't use them; don't validate postal codes with US-shaped regexes. Prefer a single "full name" field over first/last (many cultures don't split that way; W3C i18n guidance on personal names); accept Unicode, single-character names, and long names.
Show password toggle; never disable paste in password/code fields.
Passkeys/WebAuthn: mainstream as of 2025–26 — FIDO Alliance's 2026 report counts billions of passkeys in active use, ~75% of consumers with passkeys on at least some accounts, and faster sign-ins than passwords; major platforms (Apple/Google/Microsoft) sync them, and Microsoft made new accounts passwordless-by-default in 2025. UX rules: offer passkeys alongside existing methods (not a forced switch), name the benefit plainly ("sign in with your face/fingerprint/PIN"), prompt enrollment right after a successful password login, and keep account recovery paths. WCAG 2.2 3.3.8 (Accessible Authentication) prohibits memory-only tests without alternatives — passkeys are the friendly compliance path.

Validation & errors

Inline validation on blur (after the user finishes a field), not on every keystroke (premature errors) and not only on submit (batch disappointment). Positive confirmation (checkmarks) helps on high-stakes fields.
Error messages: next to the field + summarized at top on submit; say what's wrong AND how to fix ("Card number should have 16 digits" not "Invalid input"); never clear the user's data on error; preserve everything on back/refresh where possible.
Error-summary pattern (GOV.UK Design System; maps to WCAG 3.3.1 Error Identification, 3.3.3 Error Suggestion): on failed submit, show a summary box at the top titled plainly ("There is a problem"), move keyboard focus to it, and list each error as a link that jumps to its field; tie each inline message to its input with aria-describedby and mark the field aria-invalid. Screen-reader users otherwise never learn the submit failed (also SC 4.1.3 Status Messages).
Accessible date entry: for known dates (birth date, expiry), three labeled text fields or one text input with an explicit format beat a calendar widget — pickers are slow for distant dates and hard to make keyboard/screen-reader clean (GOV.UK "memorable date" pattern; NN/g date-picker guidance). Use calendar pickers only when choosing among nearby dates with context (flights, bookings), and follow the ARIA APG dialog-datepicker keyboard model.
Don't disable the submit button as the only error signal (users can't tell why); allow submit and show errors, or pair disabled state with visible reasons.

Checkout/payment specifics (Baymard-backed)

Guest checkout prominently offered • total cost with shipping/taxes as early as possible • trust cues at card entry • Apple Pay/Google Pay/ PayPal express options • address autocomplete (with the caveats above) • order review step before final charge • explicit final-action button ("Pay $42.18").
Payment Request API / browser wallets: the W3C Payment Request API lets the browser sheet handle payment + contact details (Apple Pay in Safari, Google Pay in Chrome); support is solid in Safari and Chromium but absent in Firefox — feature-detect and fall back to the normal form. Secure Payment Confirmation (Chromium) adds WebAuthn-backed card authentication for 3DS-style step-ups. Express wallets collapse the entire address/card form for returning users — the single biggest field-count reduction available.

Sources

Wroblewski, L. (2008). Web Form Design: Filling in the Blanks. Rosenfeld Media.
Baymard Institute — cart-abandonment statistics list, "reasons for abandonments during checkout" survey, checkout form-field benchmark (baymard.com) — ongoing, large-scale; figures above checked 2026.
Nielsen Norman Group — "Placeholders in Form Fields Are Harmful"; date-picker and form-design article collections (nngroup.com).
W3C WCAG 2.2 — 3.3.1, 3.3.3, 3.3.7, 3.3.8, 1.3.5, 4.1.3; WAI form tutorials (w3.org/WAI/tutorials/forms); W3C i18n — "Personal names around the world."
GOV.UK Design System — error summary, dates, addresses patterns (design-system.service.gov.uk).
FIDO Alliance — State of Passkeys consumer/workforce reports (2025–26, fidoalliance.org); W3C WebAuthn / Payment Request API specs.
Jarrett, C. & Gaffney, G. (2008). Forms that Work. Morgan Kaufmann.