Ui Patterns

UI Patterns

Concrete, evidence-based patterns for building common UI components. This skill answers the question: "How should I build this specific component?"

For visual grouping theory, see gestalt-ui. For behavioural psychology laws, see laws-of-ux. For visual hierarchy and spacing systems, see refactoring-ui. For usability audits, see ux-heuristics.

Core Principle

Follow proven patterns. Innovate on value, not on interaction mechanics. Users spend most of their time on other sites (Jakob's Law). Every component you build should feel familiar unless you have strong evidence that a novel pattern is significantly better.

Scoring

Goal: 10/10. When reviewing or building components, rate 0-10 based on adherence to proven patterns.

• 9-10: Every component follows established patterns. Scanning flow is optimised. Decision reference followed for all pattern choices.
• 7-8: Most components are well-patterned. Minor issues: one unconventional choice, missing loading state.
• 5-6: Mixed adherence. Some components feel right, others require learning or cause confusion.
• 3-4: Significant pattern violations. Users struggle to predict behaviour.
• 1-2: Components invented from scratch. Nothing feels familiar or predictable.

The UI Patterns Framework

1. Scanning Patterns -- How Users Actually Look at Pages

Core concept: Users don't read pages linearly -- they scan in predictable patterns. Place content where the eye naturally goes.

Why it works: Eye-tracking research reveals consistent scanning behaviours driven by reading habits and cognitive efficiency.

Key insights:

F-Pattern (Text-Heavy Pages)

The eye moves:

1. Horizontal scan across the top (headline area)
2. Shorter horizontal scan slightly below (subheading / first paragraph)
3. Vertical scan down the left edge, looking for visual cues

Design rules for F-pattern pages:

• First two paragraphs carry the most important information
• Start headings and bullet points with information-carrying words ("Users" not "In the case of users")
• Left-aligned content gets 2-3x more fixation than right-aligned
• Break walls of text with bold keywords, headings, and bullet points
• The F-pattern is the default when no visual cues exist -- good design breaks it

Z-Pattern (Minimal-Text Pages)

The eye moves: top-left → top-right → diagonal to bottom-left → bottom-right.

Design rules for Z-pattern pages:

• Logo/brand: top-left
• CTA or key action: top-right
• Key message or value proposition: along the diagonal
• Primary CTA or conversion action: bottom-right

Best for: landing pages, hero sections, splash screens, marketing pages.

Visual Weight Factors

Elements attract attention based on (strongest to weakest):

1. Size -- larger elements dominate
2. Colour and contrast -- vivid/saturated over muted
3. Whitespace -- isolated elements gain prominence
4. Shape -- distinctive shapes among uniform ones
5. Position -- top-left dominance in LTR languages
6. Imagery -- photos of people naturally attract the eye

Product applications:

See: references/scanning-patterns.md

2. Navigation Patterns

Core concept: Every page must answer three questions: (1) Where am I? (2) Where can I go? (3) Where have I been?

Why it works: Users need orientation, options, and history. Most responsive navigation handles only "where can I go?" and forgets the other two.

Key insights:

Product applications:

Navigation rules:

• Always label hamburger icons with "Menu" text -- icons alone are ambiguous
• Show breadcrumbs at all viewport sizes, not just desktop
• Build navigation progressively -- it must work without JavaScript
• Current page indicator must remain visible in responsive navigation
• No mega-menus on mobile; no more than 3 levels of nesting

See: references/navigation-forms.md

3. Form Patterns

Core concept: Forms are the highest-friction UI pattern. Every unnecessary field, confusing label, or validation delay reduces completion rates.

Why it works: Research shows most forms can remove 20-60% of their fields without impacting data quality. Perceived complexity reduces completion rates more than actual complexity.

Key insights:

Layout

• Labels above fields -- always. Closest visual proximity.
• One column for forms -- multi-column increases completion time by 15-25%
• Group related fields with visible boundaries and tighter spacing within groups
• Auto-focus the first field to reduce interaction cost
• Size fields proportionally to expected input (postcode = short, address = long)

Input Optimisation

• Match keyboard to input type: type="email", type="tel", type="number", type="date"
• Use input masking for formatted data (phone, dates, credit cards)
• Enable browser autocomplete / autofill (30% faster completion per Google research)
• Show/hide password toggle instead of "confirm password" field
• Avoid dropdowns on mobile -- prefer radio buttons, segmented controls, or steppers

Validation

• Validate inline after the user leaves the field (on blur), not while typing
• Show errors next to the field, not only in a top summary
• Plain language: "Email must include @" not "Error: invalid format"
• Never rely on colour alone for error indication -- add icons and text
• Preserve user input when errors occur -- never clear fields on error
• Show all errors at once, not one at a time

Friction Reduction

• Remove every non-essential field
• Explain why sensitive data is needed ("We need your phone for delivery updates")
• Mark only optional fields (if most are required); use "Optional" text, not asterisks
• Persist form data across accidental page reloads

Product applications:

See: references/navigation-forms.md

4. Button Patterns

Core concept: Buttons must look clickable, communicate their action, and follow a clear visual hierarchy.

Key insights:

Visual Hierarchy

Rule: Never give "Cancel" the same visual weight as "Submit". The primary action must dominate.

Sizing and Touch Targets

• Minimum: 44x44 CSS pixels (10mm physical)
• Primary action: largest button in context
• Breathing room between adjacent buttons (minimum 8px, recommended 16px)
• Full-width on mobile for primary actions

Labeling

• Action verbs describing the outcome: "Create Account", "Send Message", "Download PDF"
• Must answer: "What happens when I click this?"
• Avoid: "OK", "Submit", "Yes/No", "Click Here"

Required States

• Default -- resting appearance
• Hover -- cursor feedback (desktop)
• Active/Pressed -- click confirmation
• Focused -- keyboard navigation indicator (never remove without replacement)
• Disabled -- muted with explanation (prefer enabled + validate on submit)
• Loading -- spinner or progress during async operations

5. Card Patterns

Core concept: Cards group heterogeneous content into discrete, scannable, often interactive units.

Key insights:

• One primary action per card; secondary actions in overflow menu
• Entire card clickable for the primary action (not just a "Read more" link)
• Consistent dimensions within a grid (same height per row minimum)
• Internal hierarchy: Image > Title > Description > Meta
• Maximum 3-4 pieces of information per card

6. Modal & Dialog Patterns

Core concept: Modals interrupt flow and demand immediate attention. Use only when interruption is justified.

When to use: Destructive action confirmation, short decision-required forms, critical alerts.

When NOT to use: Informational content, long forms, marketing/upsells, errors (use inline).

Rules:

• Always provide visible close button (X) AND Escape key
• Dim/blur the background (figure-ground separation)
• Focus trap: tab cycling stays within the modal
• Return focus to trigger element on close
• Never stack modals
• Mobile: consider full-screen or bottom sheet instead of centred modal

7. Loading State Patterns

Core concept: Every async operation needs appropriate feedback based on its duration.

Skeleton screens:

• Mirror the layout of the content being loaded
• Subtle shimmer/pulse animation
• Replace with real content progressively (no flash)
• Better than spinners for content-heavy pages

8. Notification Patterns

Rules:

• Success notifications auto-dismiss; errors persist until acknowledged
• Errors always colour-independent (icon + text, not just red colour)
• Stack multiple notifications vertically, don't overlap
• Include an action when recovery is possible ("Undo", "Retry")

Pattern Decision Reference

When choosing between competing patterns, use this table:

Common Mistakes

Quick Diagnostic

Reference Files

• references/scanning-patterns.md -- F-pattern, Z-pattern, visual weight, and content placement strategies
• references/navigation-forms.md -- Navigation patterns, form design rules, and validation strategies
• references/tables-search-loading.md -- Table design, search patterns, loading states, and notification patterns

Further Reading

• Smashing Magazine: Responsive Navigation Patterns
• Smashing Magazine: Mobile Form Design
• Smashing Magazine: Button Design
• Nielsen Norman Group: F-Shaped Reading Pattern