frontend-ui-engineering

Frontend UI Engineering

Decide how to structure a UI unit before writing it, so the choices your audits would otherwise catch late (accessibility, i18n, bundle cost, missing states) are made up front. This is the frontend counterpart to codebase-design: treat a component as a deep module — a lot of behaviour behind a small prop surface.

It is a knowledge/decision skill, not a code generator. It resolves the design questions, then hands the actual implementation to tdd/build and verification to the audit skills. Framework-agnostic; examples in React.

Boundaries:

• vs tdd / build — they implement; this decides the UI shape and hands off.
• vs codebase-design — that is generic module depth; this applies the lens to components (prop surface = public API).
• vs prototype — that explores throwaway directions; this is for code that stays.
• vs a11y-audit / i18n / perf-audit / visual-validate — they verify after; this builds it right up front. It references their standards, never re-copies their checklists.

Workflow

Phase 1 — Classify the work

Name the unit and pick the emphasis:

Kind	Emphasis
Design-system primitive (Button, Input)	prop API, variants via props, tokens, a11y contract
Composite component	composition, state placement, the required states
Page / route	data fetching boundary, layout, loading/error at the route
Refactor of existing UI	shrink prop surface, extract states, remove magic values

Phase 2 — Decision pass (resolve before coding)

Work through each; state the decision explicitly.

1. Boundary & prop API. Smallest surface that serves callers. Prefer composition (children/slots) over configuration. A growing set of boolean flags (isPrimary, isSmall, isLoading…) is a smell — reach for a variant/size union or composition instead.
2. Where state lives. The lowest owner that still works: local → lifted to parent → server state → URL. No derived state stored twice; compute from source.
3. Data & async. Decide where data is fetched (route/loader boundary vs. inside the component) and who owns caching. Keep components that render data separate from components that fetch it where practical.
4. Required UI states. Enumerate and design them now, not later: loading, empty, error, disabled, and partial/optimistic where relevant. A component that only handles the happy path is unfinished.
5. Styling. Use design-system tokens (no magic colors/spacing). Express variants through props, not one-off class overrides.
6. Responsive / adaptive. Mobile-first; intentional breakpoints; no fixed widths that break small screens.
7. Accessibility by construction. Semantic HTML first, ARIA only as a last resort; keyboard + focus order; a label for every control; visible focus. (Defers to a11y-audit for the full WCAG pass.)
8. User-facing strings. Route them through the project's i18n path from the start rather than hardcoding. (Defers to i18n.)