frontend-ui-engineering

Frontend UI Engineering

Overview

Build user interfaces with component architecture, design system consistency, responsive design, and WCAG 2.1 AA accessibility as default requirements. Frontend work is not complete until it is accessible, responsive, and consistent.

When to Use

• Building new UI components or pages
• Modifying existing user-facing interfaces
• Implementing design system changes
• Adding interactive features or state management

Core Principles

Component Architecture

• Components should have a single responsibility
• Prefer composition over inheritance
• Keep components small: 200-400 lines typical, 800 max
• Extract shared logic into hooks or utilities
• Colocate styles, tests, and component code

Design System Consistency

• Use existing design tokens and variables
• Follow established naming conventions
• Maintain spacing, typography, and color consistency
• Extend the design system rather than one-off styles

State Management

• Keep state as local as possible
• Lift state only as high as needed
• Use the simplest state management that works
• Prefer immutable state updates

Responsive Design

• Design mobile-first by default
• Use relative units (rem, em, %) over fixed pixels
• Test at standard breakpoints (320px, 768px, 1024px, 1440px)
• Ensure touch targets meet minimum 44x44px

Accessibility (WCAG 2.1 AA)

• All interactive elements must be keyboard accessible
• Images must have alt text
• Color contrast must meet 4.5:1 for text, 3:1 for large text
• Forms must have associated labels
• Dynamic content must have appropriate ARIA attributes
• Focus management must follow logical order

Process

Step 1: Review Existing Patterns

• Check the component library for existing solutions
• Follow established file structure and naming
• Use existing design tokens

Step 2: Build Accessible First

• Start with semantic HTML
• Add ARIA attributes where semantic HTML is insufficient
• Verify keyboard navigation works
• Test with a screen reader if available

Step 3: Make It Responsive

• Implement mobile layout first
• Add breakpoints for larger screens
• Test at all standard widths

Step 4: Test

• Unit tests for component behavior
• Visual regression tests if available
• Accessibility audit with automated tools
• Manual keyboard navigation test

Common Rationalizations

Rationalization	Reality
"Accessibility can be added later"	Retrofitting accessibility is much more expensive than building it in.
"This is an internal tool, accessibility does not matter"	Internal tools benefit from keyboard navigation and screen reader support too.
"The design system is too restrictive"	Consistency speeds up both development and user comprehension.

Verification

• Component follows existing patterns and design tokens
• Keyboard navigation works for all interactive elements
• Color contrast meets WCAG 2.1 AA standards
• Responsive at standard breakpoints
• Automated accessibility audit passes