← Back to Course

Module -11

Form Design Patterns

Forms are where users give you data. Get validation, error handling, labels, and input types right — or lose users forever.

Native HTML5 validation, form libraries (React Hook Form, Formik), validation schemas (Zod, Yup). The platform has powerful built-in features most designers don't know about.

Inline validation replaced submit-then-show-errors. Multi-step forms reduce cognitive load. Autofill-friendly markup improves mobile UX. Progressive disclosure hides complexity.

Forms are conversations. Ask one thing at a time. Validate early, guide clearly. Every field you add reduces completion rate. Simplify ruthlessly.

Part A

Core Concepts

01

Form Anatomy

Every form has the same parts: labels, inputs, help text, validation, and submission. Get the structure right before styling.

*
We'll never share your email with anyone else.
Label
Required *
Input
Help text
The Parts of a Form Field

Every form field needs: a label (what is this?), the input (where they type), required indicator (is this optional?), and optionally help text (additional context).

Top (Recommended)
Left (Takes space)
Placeholder only (Bad)
Name
Label Placement

Top labels are fastest to scan and work best on mobile. Left labels save vertical space but slow scanning. Placeholder-only labels disappear on focus — users forget what field they're filling out.

Bad: No association
<label>Email</label>
<input type="email" />

// Label click doesn't focus input
Good: for + id
<label for="email">Email</label>
<input type="email" id="email" />

// Click label → focuses input
Labels Must Be Associated

Labels must be programmatically associated with inputs using for="id". This makes the label clickable (bigger tap target on mobile) and announces correctly to screen readers.

Shipping Address
<fieldset> + <legend> groups related fields
Fieldsets and Legends

<fieldset> groups related inputs. <legend> provides the group label. Essential for radio/checkbox groups and address blocks. Screen readers announce the legend with each field.

Completion Rate

Every field you add reduces form completion by ~10%. Ask only what you absolutely need.

02

Input Types

HTML5 provides specialized input types. Using the right type improves mobile keyboards, validation, and autofill.

email
@ keyboard, email validation
tel
Number pad on mobile
url
.com shortcut, URL validation
number
Numeric keyboard, min/max
password
Masked input, browser autofill
date
Native date picker
search
Clear button, search keyboard
hidden
Invisible data (CSRF tokens)
Common Input Types

Use the right input type: email shows @ keyboard, tel shows number pad, date shows native picker. This improves mobile UX dramatically and enables browser validation.

<input autocomplete="name" />
<input autocomplete="email" />
<input autocomplete="tel" />
<input autocomplete="street-address" />
<input autocomplete="cc-number" />
<input autocomplete="new-password" />
Browser autofill saves users from typing. Use standard autocomplete values for addresses, payments, and credentials.
Autofill Attributes

The autocomplete attribute tells browsers what data to autofill. This is HUGE for mobile — users can fill entire forms with one tap. Use standard values like "email", "street-address", "cc-number".

Radio Buttons (2-5 options)
Option A
Option B
All options visible
Select/Dropdown (5+ options)
Select country...▼
Options hidden until clicked
Choosing the Right Control

Radio buttons for 2-5 options — all choices visible, faster selection. Dropdowns for 5+ options — saves space but requires extra click. Avoid dropdowns for simple yes/no choices.

Checkboxes: Multiple selection
✓
Email updates
SMS alerts
Toggle: Immediate on/off
Dark mode
Checkboxes vs Toggles

Checkboxes for selecting multiple options from a list, or confirming agreement. Toggles for settings that take effect immediately (no submit button). Don't use toggles in forms with a submit button.

inputmode

Use inputmode="numeric" for numeric-only input that isn't a 'number' (like credit card numbers). It shows number pad without spinner.

03

Validation Patterns

Validate early, validate clearly. Good validation guides users; bad validation frustrates them.

✕
On Submit Only
User fills entire form, hits submit, sees wall of errors
~
On Change (Too Aggressive)
"Invalid email" appears after typing first character
✓
On Blur (Recommended)
Validate when user leaves field — they've finished typing
When to Validate

Validate on blur (when user leaves field) for the best balance. They've finished typing, and errors appear before they submit. Once a field shows an error, validate on change so they see it clear.

⚠Please enter a valid email address
Red border
Error icon
Below input
Error Message Placement

Show errors inline, below the input. Use red border, error icon, and clear message. Don't just say "Invalid" — say what's wrong and how to fix it. Associate errors with inputs using aria-describedby.

<input type="email" required />
<input type="text" minlength="3" maxlength="50" />
<input type="number" min="0" max="100" />
<input type="text" pattern="[0-9]{5}" />
Native validation: required, minlength, maxlength, min, max, pattern. Browser shows built-in error messages.
HTML5 Native Validation

HTML5 provides built-in validation: required, minlength, maxlength, min, max, pattern (regex). Browser shows native error messages. Good baseline, but often needs custom styling.

••••••••
Password must have:
✓At least 8 characters
✓One uppercase letter
○One number
○One special character
Password Requirements

For passwords with multiple requirements, show a checklist that updates in real-time as they type. Each requirement shows ✓ when met. Much better than "Password invalid" after submission.

Accessibility

Use aria-invalid="true" on invalid inputs and aria-describedby to link error messages. Announce errors to screen readers.

04

Error Handling

Errors are inevitable. Good error handling reduces frustration and guides users to success.

Bad error messages
"Error"
"Invalid input"
"Required field"
"Validation failed"
Good error messages
"Please enter your email"
"Email should look like [email protected]"
"Password needs at least 8 characters"
"Phone number should be 10 digits"
Writing Helpful Error Messages

Good errors are specific (what's wrong), helpful (how to fix it), and human (not technical jargon). Say "Enter your email" not "Required field". Say "Password needs 8 characters" not "Validation failed".

Summary at top of form, linked to each field. Focus moves here on submit.
Error Summary Pattern

For forms with multiple errors, show a summary at the top that links to each invalid field. Move focus to the summary on submit so screen reader users hear the errors immediately. Each error links to its field.

Preserve Input on Error
Don't clear fields when validation fails. Users shouldn't have to retype everything.
Save Drafts Automatically
For long forms, save to localStorage. Restore if user returns.
Warn Before Navigation
"You have unsaved changes" before closing tab or navigating away.
Prevent Data Loss

Never clear form fields when validation fails — users lose their work. For long forms, auto-save drafts. Warn before navigation if there are unsaved changes. Respect user effort.

Announcement

Use role="alert" or aria-live="polite" to announce errors to screen readers without moving focus.

05

Multi-Step Forms

Long forms can be broken into steps to reduce cognitive load. But do it thoughtfully.

Good for multi-step
• Checkout (Shipping → Payment → Review)
• Onboarding (Profile → Preferences → Confirm)
• Applications (Personal → Work → Submit)
• Surveys (Topic groups)
Keep as single page
• Login (2 fields)
• Contact forms (4-5 fields)
• Search filters
• Simple signups
When to Use Multi-Step

Multi-step forms work when there are logical groupings (shipping vs payment) or when all fields at once would overwhelm. For short forms (< 7 fields), single page is usually better. Each step adds friction.

✓
Shipping
2
Payment
3
Review
Show where user is, what's completed, what's ahead
Progress Indicators

Progress indicators reduce anxiety: "How much more?" Show completed steps (✓), current step (highlighted), and remaining steps. Let users go back to previous steps to edit.

✓Back button always available
✓Validate current step before continuing
✓Save progress between steps
✓Allow editing completed steps
Step Navigation

Back button should always be available (users make mistakes). Validate each step before allowing Continue. Save progress so browser back button doesn't lose data. Allow editing completed steps.

Step Count

3-5 steps is ideal. More than 7 steps feels like a marathon. Consider if you really need all that data.

Part H

Self-Assessment

15

Self-Assessment

Test your understanding of Form Design Patterns. Click each question to reveal the answer.

Q1

Why shouldn't you use placeholder text as the only label?

Click to reveal
Q2

When is the best time to validate a form field?

Click to reveal
Q3

What does the autocomplete attribute do?

Click to reveal
Q4

Which is better for 3 options: radio buttons or a dropdown?

Click to reveal
Q5

What makes a good error message?

Click to reveal
Q6

How should labels be associated with inputs for accessibility?

Click to reveal

Key Takeaways

Every input needs a visible label
placeholder only → label + for="id"

Never use placeholder as the only label — it disappears on focus. Use label element with for attribute pointing to input id. Labels must be visible.

Use the right input type
emailteldate

Input types improve mobile keyboards, enable browser validation, and support autofill. email shows @ keyboard, tel shows number pad, date shows picker.

Use autocomplete attributes
autocomplete="email"

autocomplete tells browsers what to autofill. One tap fills entire forms on mobile. Use standard values: name, email, tel, street-address, cc-number.

Validate on blur, not on change
User leaves field → check validity → show error

Validate when user leaves the field (blur), not while typing. Once showing an error, then validate on change so they see it clear.

Errors explain how to fix
"Invalid" → "Email should be [email protected]"

Error messages should be specific (what's wrong) and actionable (how to fix). Show inline below the field. Never just say 'Error' or 'Invalid input'.

Never clear fields on error
Don't erase user's work!

When validation fails, keep the entered data. For long forms, auto-save drafts. Warn before navigation with unsaved changes.