design-systems-frontend-architecture

Design Systems Frontend Architecture

Purpose

Help an agent convert UI, UX, product, and brand decisions into a durable frontend system: reusable components, tokens, layout rules, state behavior, documentation, governance, and implementation guidance that can scale across screens, teams, devices, and time.

Optimize for actual product work. Do not merely describe design systems. Produce decisions, defaults, component contracts, implementation guidance, critiques, and next steps the user can act on.

When to use this skill

Use this skill when the user asks for any of the following:

• Design-system strategy, component libraries, pattern libraries, style guides, design tokens, UI kits, component audits, interface inventories, or governance.
• UI critique, redesign, frontend implementation plans, component decomposition, responsive layout guidance, CSS architecture, or frontend maintainability.
• Turning mockups, screenshots, UX flows, or product requirements into scalable frontend components.
• Documentation for components, tokens, accessibility states, usage guidance, or design-to-code handoff.
• Resolving inconsistency across UI surfaces, duplicated patterns, ad hoc styling, or component drift.

When not to use this skill

Do not use this skill as the primary lens when the task is mainly:

• Broad UX research planning, ethnography, discovery interviews, market research, or product strategy not yet connected to UI/system decisions.
• Visual art direction, illustration style, campaign creative, or brand identity creation unless the user is converting it into system rules.
• Pure backend architecture, API design, data modeling, or infrastructure.
• One-off static graphic design where reuse, accessibility, and frontend implementation do not matter.

Core principles

1. Design systems, not pages. Scope effort by components, templates, content types, states, integrations, and behaviors rather than by page count.
2. Think simultaneously in parts and wholes. Evaluate tokens, atoms, components, sections, templates, and real pages together. Do not design a component without checking how it works in realistic compositions and content.
3. Separate function from perception. Treat functional patterns as behavioral/interface modules and perceptual patterns as the style, tone, motion, spacing, color, and type treatments that create product character.
4. Start with purpose before abstraction. A component exists to solve a user or product problem. Do not create abstractions from visual similarity alone.
5. Use shared language as infrastructure. Names, definitions, usage rules, and examples are part of the system, not decoration around it.
6. Prefer reusable primitives, but preserve product distinctiveness. Consistency should reduce user effort and team waste; it should not erase useful brand expression or signature moments.
7. Make the system the source of truth. Changes to shipped UI should update the component, token, or guideline where appropriate; avoid isolated hotfixes.
8. Treat accessibility as a component contract. Semantics, keyboard behavior, focus, contrast, hit areas, error handling, and reduced-motion behavior must be specified with the pattern.
9. Choose frontend architecture early enough to prevent debt, but keep it adaptable. Establish conventions before implementation spreads, then revise them intentionally as the product evolves.
10. Document for use, not archival. Documentation must answer when to use a pattern, when not to use it, how it behaves, how it is implemented, and who owns it.