Material Design 3 UI/UX 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.