Material Design

Before 2014, Android apps looked nothing like each other. One app put the back button at the top left, another put it at the bottom. Opening a menu worked differently in every app. Many screens had been designed for iPhone first and then carried over unchanged, so a single Android device held apps that looked like iPhone apps sitting next to apps that didn't.

For users, that meant relearning the controls with every install. Nothing picked up in one app transferred to the next, so the first few minutes went to hunting for where to tap, and some of those users simply closed the app instead.

The teams building those apps paid for it too. When a design review split over where a button should go, there was no reference to appeal to, so the loudest opinion won. Screens from the same company ended up with different margins. There was too much to decide and no basis for deciding it.

Material Design is a document that answers those questions in advance. It starts from a single idea: treat interface elements as sheets of paper. Stacked paper casts shadows, so shadow depth shows what sits on top of what. That's why a floating card and the sheet covering it read as separate layers at a glance, without a label explaining which one is active.

It pre-decides most of what a screen designer would otherwise settle case by case. Four areas in particular.

1. Default placement and behavior. The primary action is a round button floating at the bottom right; a short confirmation like "saved" appears as a bar that rises from the bottom edge and disappears. None of that has to be argued each time.
2. Units for values. Colors, text sizes, and spacing all carry names. Instead of choosing between 16 and 20 pixels of padding, you choose from a defined scale — and those values reach engineering as design tokens, named values shared by design and code so both refer to the same thing.
3. Build time. The system is not only a document. Buttons, text fields, and lists ship as UI components in code, so behavior like the ripple that spreads from a tap doesn't have to be written from scratch.
4. Baseline accessibility. Minimum tap target sizes and contrast ratios between text and background are already written into the rules, so following them clears the floor without extra work.

The larger effect lands on the user side. Someone opening your app for the first time can guess where to tap. In a mobile app that difference shows up immediately as whether people leave on the first screen.

Material started as an Android system, but it's open enough to use on the web, so plenty of products that aren't Android apps adopt it directly. Early teams without a designer often reach for it as the fastest way to stand up a usable interface.

Beyond adopting the platform's system, there are three routes.

• Build your own. The company defines its own colors, spacing, and parts and bundles them into a design system. The brand comes through and nothing is off-limits to change, but somebody has to build and maintain it — at a 45-person company, starting from zero consumes roughly one designer's full time.
• Keep the platform's structure and change only the surface. This is the common compromise. Layout and behavior follow the rules while brand colors and typefaces get swapped in, so the app feels familiar to use and still looks like your product.
• Use whatever parts a cross-platform framework provides. Tools that build once and ship to both operating systems bring their own widgets. It's the fastest path, and it also produces screens that sit slightly off the conventions of both platforms — close enough to look intentional, different enough that users hesitate.

Whichever route you take, collect the result in a component library — the shared set of parts screens are built from. Rules that live only in a document start drifting screen by screen, because each new screen is built by someone reading the rule again rather than reusing the part.

"By Material, that should be a bottom sheet, not a dialog."

Citing the document as the basis when a placement decision is contested.

"We'll go Material on Android and follow Apple's guidelines on iOS."

Ship each platform in that platform's own conventions rather than one design twice.

"Using the default palette makes it not look like our app. Let's swap the tokens."

Keep the structure of the system and replace only the color values with brand ones.

When Pagedeck shipped its first Android app, Noa designed the screens by shrinking the web layout. In usability testing, three of five participants couldn't work out how to create a new document from the list, because the small top-right button from the web had come along unchanged. Moving it to the floating bottom-right button the rules call for got all five to find it in the same test. The only change was the position of one button, and users had already learned that position in other apps.

Many people read the system as a set of rules for looking like a Google app. Screens using the default palette and typeface genuinely do resemble Google's own products, which makes the reading easy to arrive at. But the system marks off what to change and what to keep. Color, typeface, and corner radius are there to be replaced; layout and behavior are what you keep. Adopt the surface too and you get familiarity with no brand; change the layout and behavior as well and the familiarity goes, leaving users to hunt again.

The other misconception is that the documentation has to be read end to end. The volume is intimidating enough that teams keep postponing it. In practice it works like a dictionary: read the chapter for the feature before designing that screen, cite it in design review, and skim the changed entries when the operating system ships a new version. Treating it as a book to finish usually means never opening it at all, while five minutes in one chapter is a habit that survives.