| name | google-frontend-design |
| description | Build production-grade frontend interfaces in Google's design language — Material Design 3 layered with the Google brand palette (Blue |
Google Frontend Design
This skill produces frontend interfaces that look and feel like they belong to Google's product ecosystem: built on Material Design 3 (the current Material spec, a.k.a. Material You), tinted with the Google brand palette, and set in Google Sans / Roboto. The output should be the kind of UI a Googler would recognize as on-brand — not a generic "blue buttons on white" approximation.
The user provides a UI to build: a component, page, dashboard, or app. They may name a framework, a Google product to emulate, or just say "make it look like Google." Your job is to pick the right stack, apply the design system faithfully, and execute the details that separate authentic Material from a hollow imitation.
The core tension to manage
Material Design is the most-copied design language on the web, which means lazy Material looks like AI slop: flat blue rectangles, no elevation, default Roboto at one weight, no state layers, no motion. Authentic Material is a system, and the system lives in the details. What makes a UI read as genuinely Google:
- Tonal color, not just brand hex. Google Blue
#4285F4 is the seed, but real Material derives a full tonal palette (primary, primary-container, on-primary, surface tints) from it. Buttons, chips, and surfaces use these roles, not raw brand colors splashed everywhere. The four brand colors appear as deliberate accents (the multi-color logo treatment, category coding, data viz), not as four competing fills on one screen.
- Elevation and surface tinting. M3 surfaces are tinted with the primary color at higher elevations, and shadows are soft and layered. A card is not a
box-shadow: 0 2px 4px #ccc afterthought.
- State layers. Hover, focus, and pressed states are semi-transparent overlays of the "on" color at 8% / 10% / 12% opacity. This is the single most-skipped detail and the most telling.
- The type scale. Material defines display / headline / title / body / label roles at specific sizes and weights. Use the scale; don't eyeball font sizes.
- Shape and motion. Rounded corners follow a shape scale (the pill-shaped buttons and 16–28px card radii are signature M3). Motion uses Material's emphasized easing, not linear or default ease.
- Generous, calm spacing. Google UIs breathe. 8px grid, clear hierarchy, restraint.
Commit to the system fully. A faithful, polished Material interface is the goal — refined and friendly, never sterile.
Step 1 — Choose the stack
Pick based on what the user said. When unspecified, default to Angular — Angular and Angular Material are both built by Google and are the most native expression of this design language.
| Signal from the user | Stack | Reference |
|---|
| "Angular", or nothing specified | Angular 21 + Angular Material (M3) | references/angular.md |
| "React", "Next", "MUI", "Material UI", or a React codebase | React + MUI v9 | references/react.md |
| "plain HTML", "no framework", "vanilla", a single-file artifact, or an email/static page | HTML + CSS custom properties | references/vanilla.md |
Read the chosen reference file before writing code — it has the current setup, the theming API (these change between versions), and copy-paste-ready patterns. Always read references/design-tokens.md regardless of stack — it defines the palette, type scale, elevation, shape, and spacing that every path shares.
If you're producing a self-contained artifact (claude.ai) and the user didn't demand a specific framework, prefer the vanilla path or a single-file React path — they render without a build step. Full Angular projects need a toolchain, so scaffold them as a project the user runs locally, and say so.
Step 2 — Apply the design system
- Read
references/design-tokens.md for the shared palette and scales.
- Read the stack reference for the theming mechanism.
- Use the bundled assets as your starting point rather than rewriting tokens from scratch:
assets/tokens.css — Google-tinted M3 system tokens as CSS custom properties (light + dark), ready for the vanilla path or any framework that reads CSS variables.assets/angular-theme.scss — a mat.theme() configuration seeded with Google Blue.assets/mui-theme.ts — a MUI createTheme config carrying the Google palette and type scale.
- Build the actual interface. Wire up real interactions, real state, real content. No lorem-ipsum-and-gray-boxes mockups unless the user explicitly wants a wireframe.
Step 3 — Get the signature details right
Before finishing, check the interface against the things that make Material Material. These are in references/design-tokens.md with exact values, but the headline checklist:
- Buttons: filled / tonal / outlined / text variants with correct shape (filled & tonal buttons are fully rounded pills in M3) and visible state layers on hover.
- Surfaces: cards and sheets use elevation tokens with primary surface tint, not gray drop shadows.
- Typography: the Material type scale, set in Google Sans / Roboto, with real weight contrast (e.g., 400 body vs 500 titles).
- Color: roles from the tonal palette; brand colors as intentional accents. Verify text/background pairs meet contrast (the "on-" tokens are designed for this).
- Motion: at least one well-considered transition using emphasized easing — a page-load reveal, a ripple, an expanding FAB.
- Density and spacing on an 8px grid, with the calm, confident whitespace Google products are known for.
Fonts
Google Sans is now available on Google Fonts (it became open-source in late 2025), but availability and exact family names can vary, so default to Roboto — it's guaranteed, it's the historical Android/Material font, and it reads as unmistakably Google. Use Google Sans / Google Sans Flex for display and brand moments when you can confirm it loads, and Google Sans Code (OFL) or Roboto Mono for code. Always include a robust fallback chain ending in system-ui, sans-serif. Exact import strings and fallbacks are in references/design-tokens.md.
On staying current
Framework versions move fast (Angular ships every 6 months; MUI yearly). The reference files capture the current APIs, but if the user is on a different version or something doesn't compile, prefer the framework's own current docs over hard-coded version numbers here. The design system (tokens, scales, the look) is stable; the theming API that delivers it is what drifts.
Quality bar
This skill is about consistency with an established system, not novelty — but consistency is not an excuse for blandness. Match implementation effort to the surface: a landing page wants atmosphere and a memorable hero; a data dashboard wants legible density and restraint; a settings panel wants calm clarity. Execute the vision well and sweat the details. A Google engineer should look at the result and see their own design language reflected back accurately.
