Redesign

Redesign Workflow

This skill owns discovery, preservation, change planning, and migration safety for existing interfaces. It does not define a competing visual style: use frontend-design for shared design principles and taste for marketing-specific aesthetic guidance.

Apply skills in this order of precedence:

1. User requirements
2. Existing functionality, accessibility, brand constraints, and project conventions
3. This skill's preservation and migration rules
4. frontend-design implementation principles
5. taste marketing-specific heuristics, when applicable

How This Works

1. Scan: Read the codebase and identify the framework, styling method, component library, design tokens, routes, and tests.
2. Baseline: Record the incumbent visual truth from rendered surfaces, code, tokens, components, assets, and existing documentation. Also record information architecture, key journeys, responsive behavior, accessibility behavior, analytics hooks, and known defects.
3. Classify the requested scope before editing:
   • Refinement preserves the current identity and behavior while correcting specific defects or weak details.
   • Evolution preserves recognizable brand and product conventions while improving or extending the visual system.
   • Overhaul introduces a replacement visual language while preserving product truth, functionality, contracts, accessibility, and any other boundaries the user did not authorize changing.
4. Diagnose: Identify concrete usability, consistency, responsiveness, accessibility, and visual-system problems. Do not treat personal stylistic preference as a defect.
5. Plan: Match the changes to the approved classification and state which existing behaviors and identifiers must remain stable before editing.
6. Fix: Apply focused upgrades using the existing stack. Do not drift from refinement into evolution or from evolution into overhaul without approval.
7. Verify: Test affected journeys and compare the result against the recorded functional and visual baseline.

A missing design document does not make an existing interface greenfield. Treat coherent patterns already present in the rendered product and code as design authority unless the user approves replacing them.

Redesign Audit

Technical Context

• Identify the framework, rendering model, styling system, component library, theme strategy, and package versions.
• Reuse existing components, tokens, utilities, and dependencies before introducing alternatives.
• Locate tests, visual previews, screenshots, analytics bindings, and accessibility tooling that can establish a baseline.

Preservation Boundaries

Record what must remain stable:

• Brand assets, colors, typography, voice, and recognizable visual elements
• Information architecture, URLs, route slugs, anchor IDs, navigation labels, and conversion paths
• Functional behavior, data flows, API contracts, form field names, validation, and submission behavior
• Analytics event names, tracking attributes, experiment hooks, and automation selectors
• Keyboard behavior, focus order, semantic structure, alt text, contrast, and reduced-motion behavior
• Metadata, structured data, canonical URLs, and other established search behavior
• Legal, privacy, consent, and cookie text

Do not silently remove or rename preserved elements. Ask before changing a boundary when the redesign requires it.

Improvement Targets

Use frontend-design to evaluate shared implementation and design quality. For marketing surfaces, use taste for brief inference, anti-template heuristics, asset strategy, motion choices, content density, and visual preflight.

Look for evidence of:

• Inconsistent or undocumented visual tokens
• Weak hierarchy, spacing, alignment, readability, or responsive behavior
• Missing hover, focus, active, loading, empty, error, or disabled states
• Inaccessible interactions or regressions from the current experience
• Generic patterns that do not serve the product, audience, or brand
• Fragile CSS, duplicated styling, invalid imports, or unnecessary dependencies
• Images, fonts, or animation that create measurable performance problems

Classify each candidate change as preserve, evolve, or replace, and explain the evidence for that classification.

Change Strategy

Apply the smallest set of changes that satisfies the redesign goal:

1. Fix correctness, accessibility, and responsive defects.
2. Consolidate existing design tokens and inconsistent primitives.
3. Improve hierarchy, spacing, typography, color use, and interaction states through the existing system.
4. Recompose individual sections or components only when targeted refinements are insufficient.
5. Replace the visual language only when the user explicitly approves an overhaul.

Keep changes reviewable. Do not combine a visual redesign with unrelated architecture or business-logic refactoring.

Approval Boundaries

Ask before changing:

• URL structure, route slugs, information architecture, or primary navigation labels
• Form field names, field order, submission behavior, or analytics events
• Brand logos, wordmarks, core brand colors, established content voice, or the incumbent visual identity
• Existing legal, privacy, consent, or cookie copy
• Frameworks, styling systems, component libraries, or major dependencies
• The approved classification from refinement to evolution or from evolution to overhaul

Verification

Match the depth of verification to the approved classification. A Refinement touching one component needs that component's affected states and the journey containing it, not a full-surface re-verification. An Evolution or Overhaul needs the full list below.

• Run the project's relevant tests, linting, type checks, and build.
• Exercise every changed journey and interaction state.
• Check keyboard operation, focus visibility, semantic structure, contrast, and reduced motion.
• Confirm preserved routes, analytics hooks, form contracts, content, and behavior still match the baseline.
• When a rendered surface is available, capture or inspect representative before-state evidence.
• Inspect the completed desktop and mobile layouts together in one pass, including tablet or other shipped device classes when relevant.
• Batch the observed corrections, then perform at most one confirmation pass.
• Stop visual polishing after confirmation unless defects remain, required verification failed, or the user asks for another iteration.
• Use browser preview or existing visual-regression tooling when available.

Rules

• Work with the existing stack. Do not migrate frameworks or styling libraries without explicit approval.
• Preserve functionality and established accessibility behavior.
• Check the dependency manifest before importing any library.
• Verify framework and styling-library versions before using version-specific syntax.
• Do not make unsupported claims that a redesign improves conversion, accessibility, or performance; verify what can be measured.
• Report any requested improvement that conflicts with a preservation boundary before implementing it.