frontend-ui-engineering

작성자: addyosmani

프로덕션 품질의 접근 가능하고 반응형 사용자 인터페이스를 구축합니다. 인터페이스나 페이지를 만들거나 수정할 때, 컴포넌트를 생성할 때, 레이아웃을 구현할 때, WCAG 접근성 요구사항을 충족할 때, 상태를 관리할 때, 또는 결과물이 AI 생성물처럼 보이지 않고 프로덕션 품질처럼 보여야 할 때 사용하세요.

npx skills add https://github.com/addyosmani/agent-skills --skill frontend-ui-engineering

Frontend UI Engineering

Overview

Build production-quality user interfaces that are accessible, performant, and visually polished. The goal is UI that looks like it was built by a design-aware engineer at a top company — not like it was generated by an AI. This means real design system adherence, proper accessibility, thoughtful interaction patterns, and no generic "AI aesthetic."

When to Use

  • Building new UI components or pages
  • Modifying existing user-facing interfaces
  • Implementing responsive layouts
  • Adding interactivity or state management
  • Fixing visual or UX issues

Component Architecture

File Structure

Colocate everything related to a component:

src/components/
  TaskList/
    TaskList.tsx          # Component implementation
    TaskList.test.tsx     # Tests
    TaskList.stories.tsx  # Storybook stories (if using)
    use-task-list.ts      # Custom hook (if complex state)
    types.ts              # Component-specific types (if needed)

Component Patterns

Prefer composition over configuration:

// Good: Composable
<Card>
  <CardHeader>
    <CardTitle>Tasks</CardTitle>
  </CardHeader>
  <CardBody>
    <TaskList tasks={tasks} />
  </CardBody>
</Card>

// Avoid: Over-configured
<Card
  title="Tasks"
  headerVariant="large"
  bodyPadding="md"
  content={<TaskList tasks={tasks} />}
/>

Keep components focused:

// Good: Does one thing
export function TaskItem({ task, onToggle, onDelete }: TaskItemProps) {
  return (
    <li className="flex items-center gap-3 p-3">
      <Checkbox checked={task.done} onChange={() => onToggle(task.id)} />
      <span className={task.done ? 'line-through text-muted' : ''}>{task.title}</span>
      <Button variant="ghost" size="sm" onClick={() => onDelete(task.id)}>
        <TrashIcon />
      </Button>
    </li>
  );
}

Separate data fetching from presentation:

// Container: handles data
export function TaskListContainer() {
  const { tasks, isLoading, error } = useTasks();

  if (isLoading) return <TaskListSkeleton />;
  if (error) return <ErrorState message="Failed to load tasks" retry={refetch} />;
  if (tasks.length === 0) return <EmptyState message="No tasks yet" />;

  return <TaskList tasks={tasks} />;
}

// Presentation: handles rendering
export function TaskList({ tasks }: { tasks: Task[] }) {
  return (
    <ul role="list" className="divide-y">
      {tasks.map(task => <TaskItem key={task.id} task={task} />)}
    </ul>
  );
}

State Management

Choose the simplest approach that works:

Local state (useState)           → Component-specific UI state
Lifted state                     → Shared between 2-3 sibling components
Context                          → Theme, auth, locale (read-heavy, write-rare)
URL state (searchParams)         → Filters, pagination, shareable UI state
Server state (React Query, SWR)  → Remote data with caching
Global store (Zustand, Redux)    → Complex client state shared app-wide

Avoid prop drilling deeper than 3 levels. If you're passing props through components that don't use them, introduce context or restructure the component tree.

Design System Adherence

Avoid the AI Aesthetic

AI-generated UI has recognizable patterns. Avoid all of them:

AI DefaultWhy It Is a ProblemProduction Quality
Purple/indigo everythingModels default to visually "safe" palettes, making every app look identicalUse the project's actual color palette
Excessive gradientsGradients add visual noise and clash with most design systemsFlat or subtle gradients matching the design system
Rounded everything (rounded-2xl)Maximum rounding signals "friendly" but ignores the hierarchy of corner radii in real designsConsistent border-radius from the design system
Generic hero sectionsTemplate-driven layout with no connection to the actual content or user needContent-first layouts
Lorem ipsum-style copyPlaceholder text hides layout problems that real content reveals (length, wrapping, overflow)Realistic placeholder content
Oversized padding everywhereEqual generous padding destroys visual hierarchy and wastes screen spaceConsistent spacing scale
Stock card gridsUniform grids are a layout shortcut that ignores information priority and scanning patternsPurpose-driven layouts
Shadow-heavy designLayered shadows add depth that competes with content and slows rendering on low-end devicesSubtle or no shadows unless the design system specifies

Spacing and Layout

Use a consistent spacing scale. Don't invent values:

/* Use the scale: 0.25rem increments (or whatever the project uses) */
/* Good */  padding: 1rem;      /* 16px */
/* Good */  gap: 0.75rem;       /* 12px */
/* Bad */   padding: 13px;      /* Not on any scale */
/* Bad */   margin-top: 2.3rem; /* Not on any scale */

Typography

Respect the type hierarchy:

h1 → Page title (one per page)
h2 → Section title
h3 → Subsection title
body → Default text
small → Secondary/helper text

Don't skip heading levels. Don't use heading styles for non-heading content.

Color

  • Use semantic color tokens: text-primary, bg-surface, border-default — not raw hex values
  • Ensure sufficient contrast (4.5:1 for normal text, 3:1 for large text)
  • Don't rely solely on color to convey information (use icons, text, or patterns too)

Accessibility (WCAG 2.1 AA)

Every component must meet these standards:

Keyboard Navigation

// Every interactive element must be keyboard accessible
<button onClick={handleClick}>Click me</button>        // ✓ Focusable by default
<div onClick={handleClick}>Click me</div>               // ✗ Not focusable
<div role="button" tabIndex={0} onClick={handleClick}    // ✓ But prefer <button>
     onKeyDown={e => {
       if (e.key === 'Enter') handleClick();
       if (e.key === ' ') e.preventDefault();
     }}
     onKeyUp={e => {
       if (e.key === ' ') handleClick();
     }}>
  Click me
</div>

ARIA Labels

// Label interactive elements that lack visible text
<button aria-label="Close dialog"><XIcon /></button>

// Label form inputs
<label htmlFor="email">Email</label>
<input id="email" type="email" />

// Or use aria-label when no visible label exists
<input aria-label="Search tasks" type="search" />

Focus Management

// Move focus when content changes
function Dialog({ isOpen, onClose }: DialogProps) {
  const closeRef = useRef<HTMLButtonElement>(null);

  useEffect(() => {
    if (isOpen) closeRef.current?.focus();
  }, [isOpen]);

  // Trap focus inside dialog when open
  return (
    <dialog open={isOpen}>
      <button ref={closeRef} onClick={onClose}>Close</button>
      {/* dialog content */}
    </dialog>
  );
}

Meaningful Empty and Error States

// Don't show blank screens
function TaskList({ tasks }: { tasks: Task[] }) {
  if (tasks.length === 0) {
    return (
      <div role="status" className="text-center py-12">
        <TasksEmptyIcon className="mx-auto h-12 w-12 text-muted" />
        <h3 className="mt-2 text-sm font-medium">No tasks</h3>
        <p className="mt-1 text-sm text-muted">Get started by creating a new task.</p>
        <Button className="mt-4" onClick={onCreateTask}>Create Task</Button>
      </div>
    );
  }

  return <ul role="list">...</ul>;
}

Responsive Design

Design for mobile first, then expand:

// Tailwind: mobile-first responsive
<div className="
  grid grid-cols-1      /* Mobile: single column */
  sm:grid-cols-2        /* Small: 2 columns */
  lg:grid-cols-3        /* Large: 3 columns */
  gap-4
">

Test at these breakpoints: 320px, 768px, 1024px, 1440px.

Loading and Transitions

// Skeleton loading (not spinners for content)
function TaskListSkeleton() {
  return (
    <div className="space-y-3" aria-busy="true" aria-label="Loading tasks">
      {Array.from({ length: 3 }).map((_, i) => (
        <div key={i} className="h-12 bg-muted animate-pulse rounded" />
      ))}
    </div>
  );
}

// Optimistic updates for perceived speed
function useToggleTask() {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: toggleTask,
    onMutate: async (taskId) => {
      await queryClient.cancelQueries({ queryKey: ['tasks'] });
      const previous = queryClient.getQueryData(['tasks']);

      queryClient.setQueryData(['tasks'], (old: Task[]) =>
        old.map(t => t.id === taskId ? { ...t, done: !t.done } : t)
      );

      return { previous };
    },
    onError: (_err, _taskId, context) => {
      queryClient.setQueryData(['tasks'], context?.previous);
    },
  });
}

See Also

For detailed accessibility requirements and testing tools, see references/accessibility-checklist.md.

Common Rationalizations

RationalizationReality
"Accessibility is a nice-to-have"It's a legal requirement in many jurisdictions and an engineering quality standard.
"We'll make it responsive later"Retrofitting responsive design is 3x harder than building it from the start.
"The design isn't final, so I'll skip styling"Use the design system defaults. Unstyled UI creates a broken first impression for reviewers.
"This is just a prototype"Prototypes become production code. Build the foundation right.
"The AI aesthetic is fine for now"It signals low quality. Use the project's actual design system from the start.

Red Flags

  • Components with more than 200 lines (split them)
  • Inline styles or arbitrary pixel values
  • Missing error states, loading states, or empty states
  • No keyboard navigation testing
  • Color as the sole indicator of state (red/green without text or icons)
  • Generic "AI look" (purple gradients, oversized cards, stock layouts)

Verification

After building UI:

  • Component renders without console errors
  • All interactive elements are keyboard accessible (Tab through the page)
  • Screen reader can convey the page's content and structure
  • Responsive: works at 320px, 768px, 1024px, 1440px
  • Loading, error, and empty states all handled
  • Follows the project's design system (spacing, colors, typography)
  • No accessibility warnings in dev tools or axe-core

addyosmani의 다른 스킬

accessibility
addyosmani
WCAG 2.2 지침에 따라 웹 접근성을 감사하고 개선합니다. "접근성 개선", "a11y 감사", "WCAG 준수", "스크린 리더 지원", "키보드 탐색", "접근 가능하게 만들기"와 같은 요청이 있을 때 사용하세요.
developmenttestingcode-review
web-quality-audit
addyosmani
성능, 접근성, SEO 및 모범 사례를 포괄하는 종합적인 웹 품질 감사입니다. "내 사이트 감사", "웹 품질 검토", "라이트하우스 감사 실행", "페이지 품질 확인", "내 웹사이트 최적화" 요청 시 사용하세요.
developmenttestingresearch
seo
addyosmani
검색 엔진 가시성과 순위를 최적화합니다. "SEO 개선", "검색 최적화", "메타 태그 수정", "구조화된 데이터 추가", "사이트맵 최적화", 또는 "검색 엔진 최적화"를 요청받을 때 사용하세요.
marketingresearchdevelopment
performance
addyosmani
웹 성능을 최적화하여 더 빠른 로딩과 더 나은 사용자 경험을 제공합니다. "사이트 속도 높이기", "성능 최적화", "로딩 시간 줄이기", "느린 로딩 수정", "페이지 속도 개선", "성능 감사" 요청 시 사용하세요.
developmenttesting
code-review-and-quality
addyosmani
다축 코드 리뷰를 수행합니다. 변경 사항을 병합하기 전에 사용하세요. 자신, 다른 에이전트 또는 사람이 작성한 코드를 검토할 때 사용하세요. 코드가 메인 브랜치에 들어가기 전에 여러 차원에서 코드 품질을 평가해야 할 때 사용하세요.
developmentcode-review
security-and-hardening
addyosmani
코드를 취약점으로부터 강화합니다. 사용자 입력, 인증, 데이터 저장소 또는 외부 통합을 처리할 때 사용하세요. 신뢰할 수 없는 데이터를 받거나, 사용자 세션을 관리하거나, 타사 서비스와 상호작용하는 모든 기능을 구축할 때 사용하세요.
spec-driven-development
addyosmani
코딩 전에 명세를 작성합니다. 새 프로젝트, 기능 또는 중요한 변경을 시작할 때 아직 명세가 없는 경우 사용합니다. 요구사항이 불명확하거나, 모호하거나, 막연한 아이디어로만 존재할 때 사용합니다.
developmentdocumentproject-management
performance-optimization
addyosmani
프론트엔드, 백엔드, 쿼리, 데이터베이스 전반에 걸쳐 애플리케이션 성능을 최적화합니다. 성능 요구사항이 있거나, 성능 저하가 의심되거나, Core Web Vitals나 로드 시간 개선이 필요하거나, N+1 쿼리 패턴을 수정해야 하거나, 프로파일링에서 병목 현상이 발견된 경우 사용하세요.
developmentdatabasedata-analysis