Material Design 3 UI/UX Guide

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.

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 merely because space is available.

3. Choose adaptive structure

Read references/adaptive-design.md and references/navigation.md when multiple window sizes or navigation forms matter.

Prefer canonical patterns such as list-detail, supporting pane, feed, and adaptive navigation when they fit the content.

Wider space must improve context or productivity rather than merely stretch content.

4. Build the theme semantically

Read the relevant color, typography, shape/elevation, and spacing references.

Use the hierarchy:

reference/system tokens → semantic/system roles → component tokens

Screens should depend on semantic roles rather than scattered literal values.

5. Select components

Read references/component-selection.md plus specialized navigation/form/feedback references as needed.

For each important control, determine its semantic purpose, emphasis, immediate or transactional behavior, interaction states, accessibility behavior, and adaptive behavior.

6. Define states and feedback

Cover relevant loading, empty, error, success, disabled, selected, pressed, focus, hover, and busy/submitting states.

Error states must provide a recovery path.

7. Apply accessibility

Read references/accessibility.md.

Accessibility is a release requirement. Do not defer it to visual polish.