Material Design: Google UI System, Tokens, Components and Accessibility

This page covers it as a design language: its principles, its component model, and how to use it or deliberately diverge from it. UX/UI design patterns covers interface patterns in general, and design systems covers building your own system from the ground up.

What this gets you:

a production-ready interface system, colour, type, shape, elevation, motion and components already decided and accessible by default, so a small team ships a coherent product without designing a system from zero.

Where it applies:

Android-first products, cross-platform apps built in Flutter, and any team whose design budget is better spent on the product than on inventing a system from scratch.

What to get right first:

decide how far you will customise before building a single screen. Retrofitting brand identity onto Material after launch costs far more than deciding it up front.

Where it comes from

Google introduced Material Design in 2014, under the internal codename Quantum Paper. The system’s founding idea was to treat digital surfaces as if they were paper and ink: surfaces have edges, cast shadows and move according to consistent physical rules, and content sits on them the way ink sits on a page.

It arrived as a direct response to flat design’s biggest usability complaint. Flat interfaces removed shadow and depth so thoroughly that users often could not tell a button from a label, and Material’s elevation and shadow restored that affordance cue.

Three founding principles shaped the first release: Material as the metaphor, bold and graphic intent borrowed from print design, and motion that communicates rather than decorates. Those three ideas have outlasted every visual revision since.

Material Design as a system

Material has moved through three major versions, each loosening what the last one fixed in place.

Each Material component, a card, a button, a navigation bar, a floating action button, reads its colour, shape and elevation from those tokens rather than from hardcoded values. Change a token and every component that references it updates together. That is the same token concept design systems teaches in general terms, and Material is one vendor’s implementation of it. The token hierarchy itself, and the component APIs built on it, belong to design systems architecture.

Material’s components ship with contrast, focus and touch-target defaults built in. Meeting a conformance level and testing for it is its own discipline, covered by accessibility standards.

Adoption cost, divergence cost and the brand consequence are the real decision. The table below is a starting point, not a substitute for the judgement.

How to apply it

You must decide, before you start, whether you are adopting Material or borrowing from it. Full adoption buys you a finished component library and an accessible baseline. Borrowing costs you the coherence Material provides.

If you adopt it, you must customise only through the token system. Set your palette, type and shape through Material Theming rather than overriding component styles directly, or you lose the ability to update the whole interface from one change.

You must pick your divergence points before launch, not during it. Colour, typography and shape carry most of the brand expression Material allows, so decide which of the three you will bend hardest and leave the others close to default.

Test on a real, low-powered device before you commit to heavy elevation and motion. Shadows and transitions are not free, and an interface that feels sharp on a design laptop can stutter on the hardware your users own.

Match platform conventions where they conflict with Material. An iOS user expects iOS navigation, and Material’s cross-platform consistency is a target for your product, not an obligation that overrides what your users already know.

A worked example

Consider a business-software product built for Android first, with a small design team and a tight timeline. Adopting Material in full gives the team a finished component library on day one: forms, navigation, cards, and dialogues that are already accessible and consistent with each other.

The team’s real decision is where to spend its two or three customisation moves. It sets a brand colour through Material Theming. Hence,o the primary palette reads as the company’s own, keeps the type scale close to default because reading speed matters more than personality in a data-heavy product, and leaves shape and elevation untouched because neither carries much of the brand.

Eighteen months later, the interface still reads as a considered use of Material rather than an unbranded one. That outcome depended on deciding the customisation budget before the first screen was built, not on any single component choice.

Where it goes wrong

I have watched teams adopt Material and then fight it for eighteen months once the product needed to feel like something other than a Google app. The fight is expensive because it happens component by component, after launch, under the same deadline pressure that led to adopting Material in the first place.

The failure is rarely the choice to adopt Material. It is overriding components one at a time instead of setting the tokens once. A button restyled here, a card restyled there, and within a few sprints there is no upgrade path left, because Material ships a new component version that no longer matches the overrides sitting on top of the old one.

The other failure is quieter. A team changes the primary colour and calls the rebrand done. Everything else- the type scale, the shape language, the motion- stays at Material’s defaults, and the product still reads as a Google product with a different accent colour. Colour alone is rarely enough divergence to read as its own brand.

Common questions

Is Material Design free to use?:

Yes. Google publishes it as an open specification, with free component libraries for Android, Flutter and the web.

Does adopting Material guarantee accessibility?:

No. Components ship with sensible defaults, but conformance testing, contrast ratios and legal deadlines are their own discipline, covered in accessibility standards.

Can I use Material without my product looking like a Google product? Yes, if you customise through the token system deliberately rather than overriding components one at a time. Colour alone is rarely enough; typography and shape carry more of the brand.

Is Material 3 the current version?:

Yes. Material 3, branded Material You, introduced dynamic colour derived from the user’s own device and is the version in current use.

Do I need Android tooling to use Material?:

No. Component libraries exist for Flutter and for the web, independent of Android development.

Key facts, current as of September 2026