Interaction Design

Purpose

Design component interaction specs with all visual states, transitions, and accessibility requirements.

Inputs

• •Component name and purpose
• •Context where it appears (page, modal, sidebar, etc.)
• •User actions it must support
• •Existing design system or component library (if any)
• •Platform constraints (web, mobile, both)

Process

Step 1: Define Component Purpose

• •What job does this component do?
• •What user need does it serve?
• •Where does it appear in the UI hierarchy?
• •What is the minimal viable version?

Step 2: Enumerate All Visual States

Step 3: Define Transitions Between States

For each state change:

• •Trigger: What causes the transition (click, hover, data load, timer, keyboard)
• •Animation: Duration and easing (subtle and purposeful, not gratuitous)
  • •Micro-interactions: 100-200ms
  • •State changes: 200-300ms
  • •Layout shifts: 300-500ms
• •Feedback mechanism: Color change, icon swap, text update, motion

Step 4: Specify Accessibility Requirements

• •ARIA roles and labels:
  • •role attribute (button, dialog, alert, etc.)
  • •aria-label or aria-labelledby for non-text elements
  • •aria-describedby for supplementary descriptions
  • •aria-live regions for dynamic updates
• •Keyboard navigation:
  • •Tab order (logical, matches visual order)
  • •Enter/Space behavior (activate buttons, submit forms)
  • •Escape behavior (close modals, cancel operations)
  • •Arrow key behavior (navigate lists, tabs, menus)
• •Screen reader announcements:
  • •State changes announced (loading, success, error)
  • •Dynamic content updates via aria-live
• •Visual accessibility:
  • •Color contrast: WCAG AA minimum (4.5:1 text, 3:1 UI elements)
  • •Focus indicators visible and high contrast
  • •Information not conveyed by color alone

Step 5: Define Responsive Behavior

• •Desktop (1024px+):
  • •Full layout, hover interactions available
  • •Keyboard shortcuts active
• •Tablet (768px - 1023px):
  • •Adjusted spacing, simplified hover states
  • •Touch-friendly but more screen real estate than mobile
• •Mobile (< 768px):
  • •Touch targets minimum 44x44px
  • •Swipe gestures where appropriate
  • •Bottom-sheet instead of dropdown where needed
  • •Simplified layout, stacked elements

Step 6: Specify Content Constraints

• •Character limits for labels, descriptions, error messages
• •Truncation strategy (ellipsis, fade, wrap)
• •Internationalization considerations (text expansion 30-50% for translations)
• •Number formatting, date formatting

Output Format

State Matrix

Transition Diagram

[Default] ←→ [Hover] → [Active] → [Loading] → [Success]
    ↓                                    ↓
 [Focus]                             [Error]
    ↓
 [Active]

Accessibility Checklist

• • ARIA role assigned
• • ARIA label provided
• • Keyboard operable (tab, enter, escape)
• • Focus indicator visible
• • Screen reader announces state changes
• • Color contrast meets WCAG AA
• • Touch targets >= 44x44px

Component API

Props:
- variant: 'primary' | 'secondary' | 'ghost'
- size: 'sm' | 'md' | 'lg'
- disabled: boolean
- loading: boolean
- ...

Events:
- onClick / onPress
- onFocus / onBlur
- ...

Slots:
- icon (leading/trailing)
- children (content)
- ...

Quality Checks

• • All 8+ visual states defined (default, hover, focus, active, loading, success, error, disabled)
• • Keyboard navigation specified for all interactive elements
• • ARIA labels provided for all non-text elements
• • Touch targets meet 44px minimum
• • Loading and error states designed with recovery paths
• • Empty/placeholder state designed
• • Transitions are subtle and purposeful (not gratuitous)
• • Responsive behavior specified for mobile, tablet, desktop

Evolution Notes