To support the Phase 3 admin redesign initiative, we need a flexible, themeable, and accessible design system that can power a redesigned admin experience. It should serve as the foundation for the default admin interface while also enabling customization through user preferences and plugin extensibility. This issue outlines high-level requirements and current limitations, which will be used to guide more focused discussions.

This overview builds on and supports previous discussions:

• Admin Materials and Surfaces #70913
• Phase 3: WordPress admin redesign  #53322
• A themeable and scalable primitive system #42388
• "Admin Design" Make/Core post
• "Admin Design Kickoff" Make/Core post

The redesign presents an opportunity to formalize design primitives, close functional gaps, and provide plugin authors with a themeable, scalable, and accessible set of tools for building admin workflows.

Current limitations

The following limitations describe where we may encounter friction in using existing implementations to meet the needs of a redesign:

• Limited theming support: Current capabilities make it difficult to support the full range of redesign requirements, such as flexible color schemes, adjustable density, and user-customizable accents.
• Inconsistencies in APIs, styling, and composition: Components follow different patterns and approaches, making it harder to ensure consistent usage and meet common needs.
• Limited composability and bloated abstractions: Some components are hard to adapt or extend because they weren’t designed with composable patterns in mind, while others have grown overly complex due to scope creep and a lack of lower-level building blocks.
• Monolithic package structure: The current structure makes it difficult to use only a subset of components, which can impact performance and bundling flexibility for different projects.
• Global dependency (wp.components): Tightly coupling all components into a single shared dependency locks in historical decisions and limits how we can make decisions affecting individual components or the broader framework.
• Single-version limitation: There’s no way to run multiple versions of components side-by-side, preventing plugins that support older WordPress releases from benefiting from newer component features.
• CSS conflicts and style isolation: Lack of encapsulation increases the risk of overrides and inconsistencies, which can lead to visual inconsistencies and unpredictable results.
• Locked to specific implementation details: Current reliance on CSS-in-JS introduces runtime performance costs, and this cannot be easily removed.
• Editor-focused design: Components were primarily created to support the block and site editors, which can limit their suitability for the broader variety of admin screens.
• Maintenance cost: Managing low-level implementation details consumes significant time, leaving less capacity for decisions and improvements that have a higher impact on the user and developer experience.

High-level requirements

These are the broad capabilities the design system should support to meet the goals of the admin redesign project:

• Theming: Support for consistent, flexible color theming, adjustable density, and other appearance customizations. Allow room for expressive user personalization and plugin branding while preserving cohesion and accessibility.
• Tokens: A foundational set of design tokens (e.g., color, spacing, typography) for consistency and extensibility across components and interfaces.
• Layers of abstraction: Both low-level primitives and higher-level components to balance flexibility and ease of use for different types of interfaces.
• UI component library: A cohesive set of components that align with modern conventions, optimized for common workflows in the WordPress admin.
• Accessibility: Conformance with WordPress accessibility coding standards, including support for semantic markup, keyboard navigation, adequate color contrast, and other best practices for inclusive design.
• Responsiveness: Components or tools that support the ability for interfaces to adapt gracefully to different viewports and contexts.

Sub-issues

• Theme: Add support for density configuration #73360
• Theme: Add responsiveness support (tokens, value resolution) #73361

cc @WordPress/gutenberg-components