/material-design-3-ui-skill

description: Design, redesign, review, or implement user interfaces using Google Material Design 3 (M3), Material You, and optional Material 3 Expressive principles. Use for UI/UX screens, app flows, design systems, component selection, theming, responsive/adaptive layouts, accessibility audits, Figma-ready specifications, or developer handoff where Material Design 3 is required.
metadata:
  updated: 2026-10-01
  version: 1.1.1
name: material-design-3-ui

Material Design 3 UI/UX

Purpose

Create interfaces that **behave like Material Design 3**, not interfaces that merely look rounded or “Google-like.”

Treat M3 as a system:

**user goal → information architecture → hierarchy → adaptive layout → semantic tokens → components → states → interaction → motion → accessibility → visual expression**

M3 Expressive is optional. Use it to strengthen hierarchy, usability, recognition, and emotional clarity; never use it as permission to make every element loud.

Source of truth

1. Prefer current official Material 3 guidance at `https://m3.material.io/`. 2. For Android implementation details, prefer `https://developer.android.com/`. 3. Treat design guidance separately from implementation-library/API status. 4. Verify current official guidance before asserting exact dimensions, dependency versions, experimental API names, or recently changed behavior. 5. Do not silently mix Material 2 rules into Material 3. 6. Pixel and Google-app screenshots are examples, not the specification.

Core rules

MUST

• Start from the user’s task, content, hierarchy, and platform before styling.
• Use semantic design tokens instead of scattered one-off values.
• Choose components by purpose and behavior, not visual resemblance.
• Prefer established M3/platform components when they solve the interaction.
• Define important states: default, pressed, focus, hover where applicable, selected, disabled, loading, error, empty, and success where relevant.
• Design for the available window rather than a guessed device category.
• Preserve accessible contrast, target size, focus, semantics, scaling, and non-color state communication.
• Respect system bars, safe areas, cutouts, keyboards/IME, foldable hinges, and edge-to-edge behavior where applicable.
• Keep primary actions distinguishable from secondary and destructive actions.
• Make custom components inherit the token, state, motion, and accessibility logic of the system.
• Explain deliberate departures from M3 when product requirements justify them.

MUST NOT

• Do not “Materialize” a screen by only adding large radii, pastel colors, shadows, or Material Symbols.
• Do not hardcode raw colors throughout screens when semantic roles can be used.
• Do not use color alone to communicate meaning or state.
• Do not wrap every section or list row in a card.
• Do not maximize corner radius on every component.
• Do not use FABs for minor, destructive, or ambiguous actions.
• Do not use chips as generic buttons or primary navigation.
• Do not use tabs for unrelated top-level destinations.
• Do not make all components equally expressive.
• Do not invent a new control when an established M3/platform control already solves the interaction.
• Do not sacrifice accessibility to preserve a visual composition.
• Do not stretch a compact/mobile layout unchanged across wide windows.

Progressive-disclosure references

Load only the references needed for the current task. Do not read every reference by default.

| Need | Read | |---------------------------------------------------------|---------------------------------------| | Color roles, surfaces, dark theme, dynamic color | `references/color-system.md` | | Type hierarchy, scaling, expressive typography | `references/typography.md` | | Shape, cards, containment, elevation | `references/shape-and-elevation.md` | | Spacing, alignment, readable widths, safe areas | `references/spacing-and-layout.md` | | Buttons, FAB, cards, chips, selection, inputs, feedback | `references/component-selection.md` | | Navigation bar/rail/drawer, tabs, app bars | `references/navigation.md` | | Forms, validation, settings, text input | `references/forms-and-input.md` | | Snackbar, dialog, sheet, loading, empty/error states | `references/feedback-and-overlays.md` | | Responsive, tablet, foldable, desktop, multi-pane | `references/adaptive-design.md` | | Accessibility audit or any final UI review | `references/accessibility.md` | | Transitions, feedback animation, shape morphing | `references/motion.md` | | Material 3 Expressive | `references/m3-expressive.md` | | Final audit / suspicious “Material-looking” UI | `references/anti-patterns.md` |

For a broad end-to-end design, load the references incrementally as decisions require them. Always include the accessibility reference before final approval.

Workflow

Follow this order unless the task explicitly scopes one stage.

1. Understand the product

Identify the platform, primary user goal and action, top-level destinations, content hierarchy, data density, input methods, brand constraints, required states and edge cases, target window sizes, and whether M3 Expressive is appropriate.

If missing information does not block the work, make a conservative M3-aligned assumption and state it. Ask only when the missing information materially changes architecture or interaction.

2. Establish information architecture

Before styling:

• Group related information and identify the primary task per screen.
• Separate navigation from actions and distinguish destructive actions.
• Remove duplicated controls and define progressive disclosure.
• Avoid showing information mere