This is Google Material Design 3 (abbreviated M3, also called Material You), the specific design system’s internal principles distilled. Material Design is Google’s full official UI design language for Android / Web / cross-platform — it tells you how to match colors, set type, how large corners should be, how to apply shadows, how fast animations should be, and what size buttons need to be to be tappable. M1 (2014) was skeuomorphic paper-style; M2 (2018) was more restrained;M3 (from 2021 onward)’s biggest revolution is "Dynamic Color": UI color schemes can be automatically generated from the user’s phone wallpaper, so everyone’s App looks different, yet still meets accessibility requirements.
This article ≠ a component API manual. The official M3 website has hundreds of components (buttons/cards/dialogs…); this article does not copy the component list, but instead distills "M3’s design philosophy + core rules for each foundational dimension + signature numeric values" so PMs can use it when building products / reviewing design drafts.
First, let’s explain in plain language a few recurring concepts that are most likely to scare people off with jargon:
- Design Token: Give values like "color/font size/corner radius" a semantic name to use as a variable, instead of hardcoding specific values. For example, instead of saying "use this purple #6750A4", you say "use
primarythis role". The benefit: when changing skins / switching dark mode / changing brand colors, change one variable and the whole App updates accordingly. This is the engineering foundation of all of M3.- Color Role: Instead of thinking about colors as "red/green/blue", think about "what this patch of color is used for" —
primary(primary emphasis),surface(background),error(error),on-primary(text on top of primary color). Designers only need to assign roles to elements; the specific color is automatically calculated by the system based on theme/contrast. This is "semantic color".- dp (density-independent pixel): Android’s size unit, which automatically adapts to different screen densities; 1dp = 1 physical pixel on a standard screen. All M3 sizes (48dp touch targets, 24dp icons) use dp, so they "look the same size" on high-density and normal-density screens.
- HCT / Tone: M3’s own color model (Hue + Chroma + Tone), where Tone = lightness/darkness, 0 is pure black, 100 is pure white. M3 uses "how far apart two tones are" to guarantee contrast, which is the mathematical basis for its ability to automatically calculate accessible color schemes.
The full text covers nine dimensions plus two application layers: ① Design philosophy (Dynamic Color + personalization) → ② Color system (HCT + color roles + contrast) → ③ Type Scale → ④ Shape → ⑤ Elevation → ⑥ Layout (window size classes + density) → ⑦ Adaptive → ⑧ Motion → ⑨ Interaction states → ⑩ Accessibility → ⑪ Content design → ⑫ For PMs: when to copy directly vs when to deviate. Each section includes core principle / Why / counterexamples.
1. M3 Design Philosophy: Dynamic Color & Personalization
Source: Color system / Dynamic Color Schemes / Content design “Dynamic color makes personal devices feel personal”
Core principle: The soul of M3 is not a specific color, but "a color generation machine". Imagine every UI element is numbered (like the cells in a paint-by-numbers picture), each number tied to a "color role"; starting from a single source color, the system automatically fills in the entire color scheme. When the source color changes, the whole App’s color scheme changes with it — and it always meets accessibility contrast requirements.
The complete Dynamic Color generation process (M3’s signature 6 steps):
| Step | What it does | Key values / details |
|---|---|---|
| 1 Select source color | Three sources: ① User wallpaper (quantitative analysis to select a dominant color) ② In-app content (thumbnails/images/video previews) ③ Manually specified by designer (e.g., the purple in M3’s base static color scheme) | Starts from a single source color |
| 2 Feed to algorithm | Processed using Google’s open-source Material Color Utilities algorithm | Three algorithms: user-generated color / content-based color (matches image dominant color while preserving contrast) / custom brand color |
| 3 Generate 5 key colors | The algorithm expands the source color into 5 key colors | Primary / Secondary / Tertiary / Neutral / Neutral Variant |
| 4 Build tonal palette | Each key color produces a complete light-to-dark gradient | Tone range 0 (pure black) to 100 (pure white), including steps 10/20/…/95/98/99 etc.; the smaller the number, the darker the shade |
| 5 Assign tones to roles | The algorithm pins specific tones to 26 color roles based on "whether contrast is sufficient" | Light / dark themes use the same set of role names, only the underlying tones are inverted |
| 6 Apply to UI | 26 roles are pre-assigned to UI elements; when the source color changes, the whole App updates automatically | Automatic dark mode + user-controllable contrast |
4 things Dynamic Color delivers to users(selling points M3 repeatedly emphasizes): ① Personalized UI; ② Automatically meets accessibility contrast; ③ Users can manually adjust contrast; ④ Automatic dark theme (no need for designers to create two separate sets).
Three dynamic color sources(which to choose in practice):
- User-generated: Extracted from wallpaper, "my phone, my colors", strongest personalization (Android system-level).
- Content-based: The App changes color with the current image/video, looking "very smart" (music App changes color with album cover).
- Multiple: Uses both wallpaper + content at the same time.
Why: What M3 wants to solve is "personalized for everyone without going out of control" — in the past, personalization was either absent (everyone got the same look) or unconstrained (users picked random color combinations that made text unreadable). Dynamic Color uses algorithms as a safety net: no matter how strange the source color, the generated scheme meets 3:1 / 7:1 contrast.Implications for PMs: This is a differentiator for native Android Apps; but if you are building a strongly brand-bound product (banking, luxury), you should instead turn off Dynamic Color and use fixed brand colors — see Section 12.
2. Color System: HCT Model + Color Roles + Three Contrast Levels (Color)
Source: Color system / Color Roles / Choosing a Scheme / Static & Dynamic schemes / Advanced customizations
2.1 Foundation: HCT color model (why not HSL)
Core principle: M3 created its own HCT model —Hue (0–360°, red/orange/yellow… cyclic) + Chroma (0 completely neutral gray to ~120 most vivid) + Tone (0 pure black to 100 pure white = lightness).
Why use HCT instead of traditional HSL/HSV: HCT is closer to actual human visual perception. The key point is Tone directly determines contrast — the farther apart two colors’ Tones are, the higher the contrast. This turns "is it accessible?" into a purely mathematical problem (calculating Tone difference), so the system can automatically generate compliant colors. Default button: container uses a dark tone, text uses a light tone, Tone difference pulled to 3:1; when the user turns on high contrast, the algorithm pulls the two Tones farther apart to reach 7:1.
2.2 Color Roles: think by "purpose" not by "hue" (Color Roles)
Core principle: Color roles = "the numbers in paint-by-numbers", connecting UI elements to the color they should use.M3 has a total of 26 standard roles, named by combining 5 root words; remember the roots and you understand the system:
| Root | Meaning | Example |
|---|---|---|
| Surface | Large-area, low-emphasis background | Screen background, card background |
| Primary / Secondary / Tertiary | Foreground emphasis colors (primary/secondary/tertiary), used to highlight or de-emphasize | FAB uses primary, filter chips use secondary |
| Container | of foreground elements such as buttons fill color(Note:must not be used as text/icon color) | primary container = background of primary-colored buttons |
| On (prefix) | text/icon color "on top of"the paired parent color" text/icon color | on-primary = text on a primary background |
| Variant (suffix) | lower-emphasis version of the same color | outline variant = divider lighter than outline |
Core pairing rule: when a container is used as the background, the text must use the corresponding on-xxx——this paired combination is guaranteed by the system to provide at least 3:1 contrast ratio. Arbitrary mismatches (e.g., primary background + surface text) will blur when contrast is switched.
Several practical role families:
- Surface family:
surface(default background) +on-surface(text on background) +on-surface-variant(faint text for secondary information). Plus 5 levels of containerssurface-container-lowest/low/(default)/high/highestto create hierarchy in expanded layouts (most common combination: main content area usessurface, navigation area usessurface-container). - Error family:
error/on-error/error-container/on-error-container, dedicated to communicating errors (wrong password, form validation).Do not hardcode ordinary red; use the error role so it flips correctly in dark mode. - Outline family:
outline(primary borders/dividers) vsoutline-variant(low-emphasis dividers). Counterexample: using outline for dividers inside cards is too prominent; outline-variant should be used instead. Conversely, using outline-variant between adjacent buttons is too faint; outline should be used. - Inverse family:
inverse-surfaceetc., used for high-contrast color blocks such as Snackbar. - Fixed family / Bright·Dim: advanced,unnecessary for most products——fixed colors do not change across themes (use when you want a color to stay the same in both light and dark mode); Bright/Dim are permanently bright/permanently dark surfaces. M3 explicitly says "ignore them if you are unsure".
Why: Semantic colors = defined once, reused globally, automatically adapted to themes and contrast. Designers assign roles instead of color values; developers use tokens instead of hardcoding; dark mode / high-contrast mode are obtained "for free".
2.3 Three contrast levels (Standard / Medium / High)
In addition to light/dark themes, M3 color roles also have built-in three contrast levels that automatically adapt to both light and dark themes:
| Level | Contrast | Applicable to |
|---|---|---|
| Standard (default) | Mix of high and low contrast to reduce visual load; meets 3:1 minimum contrast | Most users |
| Medium | 3:1 | Requiring higher readability; meets 4.5:1 minimum contrast |
| High | 7:1 | Users with visual impairments, emphasizing key points; meets 7:1 minimum contrast |
Why: Turns "accessibility" from a manual designer task into a system toggle——when users adjust system settings, all components that use color roles correctly respond automatically, so designers do not need to create a third set of mockups.
III. Typography: Type Scale + 4 Variable Font Axes (Typography)
Source: Type scale & tokens / Default typefaces / Applying type
Core principle:Type Scale = a set of preset application-level text styles (tokenized) to ensure consistent typography across the entire app. Based on Roboto, M3 provides 15 styles, divided into 5 categories(each with Large/Medium/Small levels):
| Category | Usage |
|---|---|
| Display | Largest display headlines (marketing/launch pages) |
| Headline | Page/section titles |
| Title | Medium titles such as card titles, dialog titles |
| Body | Body paragraphs |
| Label | Button text, labels, auxiliary small text |
Custom rules: Default uses "Major Second" ratio = 1.125 scaling factor(each level is 12.5% larger than the previous), based on 14sp body text.
Counterexamples / practical suggestions:
- Most products do not need all 15 styles——picking 5 classic levels is enough.
- Maintain contrast: Do not use two adjacent font sizes that are nearly identical (e.g., 15 and 16), as visual hierarchy will blur; there must be clear jumps between sizes.
4 Variable Font Axes——one font file steplessly adjusts 4 properties:
| Axis | What it is | Key points |
|---|---|---|
| Weight | Stroke thickness (Regular→Bold, stepless) | Counterexample: overly thin text is illegible at small sizes; titles can be lighter, body text should be slightly thicker |
| Grade | Also adjusts thickness, but more subtle, does not change character width | The same weight appears thicker in dark mode; use negative grade to restore balance (Roboto Flex provides +150/-200); adjusts visual emphasis without reflow |
| Width | Horizontal footprint (narrow→wide) | Use narrow widths for tight spaces on labels/toolbars to save space; overly wide text will overflow |
| Optical Size | Versions of the same character optimized for different font sizes | Small text needs clearer strokes; large text can show details; use optical size matching the font size |
Why: Tokenized Type Scale makes "changing site-wide title font size" = changing one token; variable fonts let one file cover all weights/widths, reducing download size while allowing fine-tuning of appearance in light/dark mode.For PMs: When reviewing designs, count "how many font sizes are used on this screen"——more than 4–5 usually means hierarchy is not thought through.
IV. Shape: 7-level corner radius + rounded/cut corner families (Shape)
Source: Shape scale & Tokens
Core principle: M3 tokenizes corner radii into 7 levels, each bound to a group of components to ensure "components of the same category have consistent corner radii":
| Level | Typical components |
|---|---|
| 1 None (no rounding) | Banners, bottom app bars, full-screen dialogs, lists, navigation bars/rails, progress indicators, tabs, top app bars |
| 2 Extra small | Menus, dropdown selects, Snackbars, text fields |
| 3 Small | Chips, rich text tooltips |
| 4 Medium | Cards, small FABs |
| 5 Large | Extended FABs, FABs, navigation drawers |
| 6 Extra large | Bottom sheets, dialogs, floating sheets, large FABs, time pickers |
| 7 Full (fully rounded, pill-shaped) | Badges, buttons, icon buttons, sliders, switches, search bars |
Two dimensions:① Symmetry——symmetric (all four corners same radius) vs asymmetric (top/bottom/start/end set separately); ② Shape family——Rounded vs Cut corner (45° bevel).
Customization granularity: You can adjust the whole style (change all Medium-level components together), or adjust a single component.
Counterexamples:① Cut corners encroach on the content area, affecting text alignment / image cropping (rounded corners generally do not); ② overly large corner radii eat into content and harm readability.
Why: Corner radius is a low-cost lever for brand tone (rounded = friendly and approachable, square/cut = crisp and professional). Tokenization lets you change style by only changing tokens.For PMs: Corner radius is a "deviation-allowed item"; changing it does not harm usability, and is the safest place to express brand personality.
V. Elevation: Tonal Elevation (Elevation)
Source: Elevation visual hierarchy-height
Core principle: Elevation = the distance between two surfaces on the z-axis (unit dp), expressing "who is above whom".M3's biggest shift: moving from "expressing elevation with shadows" to "expressing elevation with Tonal Elevation (color-tone differences)"——higher surfaces have lighter tones (a layer of semi-transparent primary color overlaid on the base), with shadows taking a secondary role.
Elevation levels: All surfaces/components have default Elevation values,0~+3 for normal states, +4/+5 reserved for the moment of "floating up" during hover or drag. Example: FAB defaults to +3, temporarily rises to +4 on hover; all Material buttons rise 1 level on hover.Default values are not recommended to be changed, and elevation changes for similar elements must be consistent.
3 ways to distinguish hierarchy(for two overlapping surfaces of the same color): ① tonal difference (M3 default) ② shadow ③ scrim (semi-transparent overlay).
Shadows: M3 prefers tonal differences; shadows are used only when necessary. Rule:Small, sharp shadows = close to the background; large, soft shadows = more "floating". When to use visible shadows: ① protect elements (prevent FAB from blending with background) ② guide interaction (elevate on hover to enhance feedback).
Scrim: Darkens the background and focuses the foreground during modal popups,default opacity 32%.
Hard constraint on interactive components: Edge contrast between adjacent surfaces must meet/exceed accessibility contrast requirements (otherwise it is impossible to tell there are two layers).
Why: Shadows are nearly invisible in dark mode, while tonal differences work in both light and dark modes——this is the fundamental choice M3 made for native dark mode support.For PMs: Do not let mockups pile on heavy shadows to look "premium"; M3 hierarchy is created through tonal differences and container roles (surface-container-*).
VI. Layout: Window Size Classes + Density + Touch Targets (Layout)
Source: Window Size Classes / Density / Layout basics / Spacing / Pane layouts (list-detail/supporting pane/feed)
6.1 Window Size Class (responsive breakpoints)
Core principle: Do not adapt for "specific device models"; adapt for "window size classes"——this is the core abstraction of M3 responsiveness. Divided by width (dp):
| Class | Width (dp) | Common devices |
|---|---|---|
| Compact | <600 | <600dp; portrait phones |
| Medium | 600–840 | 600–839dp; portrait small tablets, unfolded foldables |
| Expanded | 840–1200 | 840–1199dp; landscape phones, landscape tablets, desktop |
| Large (Web/desktop) | 1200–1600 | 1200–1599dp; desktop |
| Extra-large | ≥1600 | ≥1600dp; ultra-wide desktop |
Why classify by size class instead of device: The same device in portrait and landscape belongs to different classes; split-screen / unfolded foldables dynamically change available width. Watch breakpoints, not models.
Key design actions——when the window becomes larger:
- What to reveal: Small windows collapse UI by default (e.g., retract navigation); large windows show multiple panes side by side (list + detail, reducing page transitions).
- Maintain consistency: Different sizes should be "the same experience scaled", not two completely different apps.
- Adjustable elements: Cards, feeds, lists, panels——horizontal cards on phones become square on tablets;text lists should keep 40–60 characters per line for optimal readability; expanded screens can add a second column/masonry layout/more whitespace.
- FAB remains center-aligned across sizes, with consistent relative position.
Three canonical pane layouts(ready-made templates provided by M3):List-detail(email/chat), Supporting Pane(main content + supporting information), Feed(grid/masonry).
6.2 Density + Touch Targets (Density)
Core principle:Information density = how much content fits per unit of screen space. Can be controlled by adjusting spacing.
- Desktop prefers high density, mobile prefers low density;Unless the user actively changes it, density does not automatically change with window/orientation.
- High density suits information-dense products (news, financial portals); low density suits aesthetics-focused/key-point-emphasis products.
- Component scaling: Density levels start at 0; space decreases into negative values (-1 to -3), with each level reducing padding/height by 4dp.
Iron rule: minimum accessible touch target = 48×48 dp(same for CSS pixels). No matter how dense component scaling becomes,targets must not be smaller than 48×48. Provide users with a high-density option + a simple way to reset.
Counterexamples: Month options in date pickers are squeezed to have tiny click areas; connection timeout prompts are compressed with truncated text.
Why: 48dp comes from the physical size of human finger touch, and is a hard accessibility constraint that must not be deviated from. For PMs: The first check when reviewing designs is to measure "whether the smallest clickable element is at least 48dp"——this is the most common issue that should be sent back.
VII. Adaptivity: Three Layout Strategies (Adaptive Design)
Source: Adaptive design
Core principle: Adaptivity = the interface automatically adjusts according to context (device / window size / input method). Adapts to three conditions:Device(full-screen/split-screen/foldable), window size, Input method(touch/stylus/external keyboard & mouse/eye tracking).
Three layout strategies:
- Hide and show: Show/hide content based on available space (reveal more when space allows, e.g., expanding a collapsed navigation bar).
- Levitate: Elements adjust to fit different devices/inputs (FAB changes form with window size).
- Reflow: Rearrange components to make content easier to read/operate (single column → double column).
Three component adaptations: ① Resizing (buttons adapt to the interface) ② Hiding/showing (large-screen list items reveal more content) ③ Presentation changes (color/typography/size change, FAB changes with the window).
Why: One set of designs covers phones, desktops, and foldables, reducing multi-platform maintenance costs.For PMs: Cross-platform products must clearly define "which content is hidden on small screens, and where to tap to bring it up" — don’t let small screens lose functionality.
VIII. Motion: Easing × Duration (Motion / Animation & Transitions)
Source: Easing and duration / Easing and duration Specs / Transition patterns / Applying transitions
Core principle: Motion relies on two parameters —Easing(speed rhythm curve) × Duration(in milliseconds). Objects in the real world do not start or stop instantly; they accelerate and decelerate; transitions without easing feel stiff and mechanical.M3’s easing is more expressive than iOS: fast at the start, soft at the end.
M3 recommended easing × duration pairings:
| Easing | Duration | Transition type |
|---|---|---|
| Emphasized | 500ms | 200–500ms; enter + exit screen |
| Emphasized decelerate | 400ms | 200–500ms; enter screen |
| Emphasized accelerate | 200ms | 200–500ms; exit screen |
| Standard | 300ms | 200–500ms; enter + exit |
| Standard decelerate | 250ms | 200–500ms; enter |
| 200–500ms; exit | 200ms | Exit |
Choosing an easing set:Emphasized → primary animations(more distinctly Material in style);Standard → secondary animations(faster and more concise).
Choosing an easing type(based on how the element moves relative to the screen): starts and ends on screen = Emphasized (fast in, slow stop, emphasizes the end) / entering = Emphasized decelerate (starts at peak speed, eases to a stop) / permanently exiting = Emphasized accelerate (starts from rest, ends at peak speed, "leaves and doesn’t come back") / temporarily exiting = Emphasized (ends smoothly, leaves a sense of recoverability).
3 standards for choosing duration: ① Small transition range → short (200ms), large → long (500ms); ② Exits are shorter than enters(exit 200ms, as user attention has already shifted; enter 500ms, to let users clearly see new content); ③ Don’t make it too short (stiff) or too long (dragging).
Why: Motion is "speaking through movement" — delivering feedback, indicating state changes, preventing loss of orientation, but any irrelevant motion is a distraction(the human eye is inherently sensitive to movement).For PMs: These values can serve as a review yardstick — main transitions ~300–500ms, microinteractions ~200ms; longer feels dragging, shorter feels jumpy. (For the 6 uses of motion and its misuse in dark mode, see NNGroup Design Systems · Icons · Visual Style · Motion · Visual Testing (19 articles · Design system vs style guide · 4 icon usability standards/recognizability vs explainability · Skeuomorphism/glassmorphism/flat/neumorphism · Clickable element recognition + banner blindness · 6 uses of animation/motion · Visual testing attitude vs behavior/Desirability Toolkit/mood boards) Section 5.)
IX. Interaction States: State Layer Overlay (Interaction States)
Source: Interaction / States / Gestures / Inputs / Selection
Core principle: M3 uses "State Layer" to express interaction states uniformly — overlaying components with a translucent layer of fixed opacity using the content color to transform the default state into an interactive state. Three-layer structure (bottom to top): Container → State layer → Content.
Key values — how much opacity to add for different states:
| State | Opacity | Trigger |
|---|---|---|
| Hover | +8% | +8% opacity; cursor resting over the element |
| Focus | +10% | +10% opacity; keyboard Tab / voice input (displays ring-shaped keyboard focus indicator) |
| Press | +10% | +10% opacity; click and hold |
| Drag | +16% | +16% opacity; press and move |
Size: State layer is 40dp, while the interaction target is 48dp (echoing the touch constraints in Section 6).
A few rules: ① States can be combined (selected + hover) ② Remain consistent across all components ③ A layout can have only one hover / one pressed / one dragged state at a time ④ States must have two visual indicators(don’t rely on color alone; add borders/underlines/icons — for color-blind users).
Enabled/Disabled: Disabled state = desaturated color + no hover + no contrast requirement; and disabled states cannot receive focus/be dragged/be pressed. Counterexample:An unavailable FAB should not be disabled; it should not appear at all. Each state has a clear "applicable/non-applicable component list" (e.g., App Bars / dialogs as a whole do not inherit hover/press).
Why: The state layer standardizes "what hover/focus/press look like" into a few percentage values, enabling zero-thought consistency across components; the "two visual indicators" rule is a hard accessibility requirement.For PMs: When reviewing, check "is there a focus ring when navigating with keyboard Tab" — many drafts omit the focus state, leaving keyboard/screen reader users lost.
X. Accessibility: Contrast Is the Baseline (Accessible)
Source: Color & contrast / Structure / Text resizing / Text truncation
Core principle: Contrast = the luminance difference between two colors,from 1:1 to 21:1. M3 treats W3C/WCAG standards as hard constraints:
| Content | Minimum contrast |
|---|---|
| ≥3:1; large text (14pt bold / 18pt regular and above) + graphics/icons | 3:1 |
| ≥4.5:1; small text (regular body text) | 4.5:1 |
| Disabled-state elements | No requirement |
Non-text elements: Button containers etc. require ≥3:1 contrast against the background;when multiple components are grouped together, each must individually meet 3:1. Exception:The FAB itself is prominent enough and does not need to meet 3:1.
Other accessibility dimensions:Structure(semantic hierarchy, screen reader order),Text resizing(layout does not break when users enlarge text),Text truncation(how to apply ellipses to overlong text, what should not be truncated).
Why: Contrast is a legal/compliance-level requirement (many markets mandate WCAG), and directly determines usability for people with low vision / in bright light.For PMs: This is an absolute non-negotiable item. When reviewing, use a contrast checker (e.g., coolors contrast checker) to sample and verify; don’t rely on the naked eye to "feel it’s enough". M3’s color role system is designed so that "using the right role = automatically meeting the standard", so the ironclad role pairing rules in Section 2 are essentially an accessibility tool.
XI. Content Design: 20 Rules for UI Copy (Content Design)
Source: Style guide / Global writing / Notifications / Dynamic color... (this section is primarily targeted at English UI copy; some rules require localized adaptation for Chinese-language products)
Core principle: Copy is also part of design. M3’s content guidelines (largely following AP Associated Press style) provide around 20 rules for English UI writing; several core ones are also transferable to Chinese products:
- State consequences clearly; don’t threaten or lecture: The first sentence of a confirmation dialog should directly ask "Move to trash?", and the second sentence should only give key information (deleted after 30 days); don’t add unnecessary "Are you sure?" that increases cognitive load.
- Scannable: Layered headings + concise text let users locate information quickly.
- Sentence case: All UI text (headings/labels/menus/buttons) uses sentence case (only the first letter capitalized), not Title Case — more modern and readable.No all-caps CAPS blocks.
- Use the second person "you/your": Creates a more conversational feel ("Your mail isn't available" is friendlier than "Mail not available");don’t mix first/second person(be consistent with "Your photos" or omit pronouns entirely; don’t use "My photos");Use "I/we" cautiously(sounds stiff for large companies).
- Punctuation: Don’t add periods to single-line sentences; use exclamation marks sparingly (only for celebratory moments), ellipses sparingly (only to indicate in-progress, don’t use on menus/buttons); use the Oxford comma to eliminate ambiguity; don’t use colons in headings (acceptable in body lists); use parentheses only to define terms/abbreviations.
- Abbreviations: Use cautiously (spell out if space allows); but use colloquial contractions to keep tone natural (use "don't / can't" not "do not / cannot").
- Use italics cautiously(hard to read; use bold instead), use long dashes cautiously (breaks sentence flow).
Why: Consistent, humanized copy reduces cognitive load and unifies brand voice.For PMs: This is a ready-made copy checklist when building English-language products for overseas markets; for Chinese products, adapt the core principles of "state consequences clearly without lecturing / conversational second-person feel / no all-caps blocks / restrained punctuation".
XII. For PMs: When to Copy M3 As-Is, When to Deviate
This section condenses the nine dimensions above into a "decision table", answering "when building/reviewing a product, which M3 rules must be followed, which can be changed".
| Dimension | Copy as-is (hard constraints, non-negotiable) | Can deviate (stylistic choices, to express brand) |
|---|---|---|
| Accessibility contrast | Must follow 3:1 / 4.5:1 / 7:1 (legal regulation + usability baseline) | —— |
| Touch targets | Must follow Minimum 48×48 dp | —— |
| Interaction states | Focus state is mandatory (keyboard accessible), states require two visual indicators (not solid color alone) | Specific opacity values for hover/press can be fine-tuned |
| Color role system | Recommended to follow Semantic structure + role pairing (otherwise automatic theming/contrast is lost) | Specific source colors, whether to enable dynamic color |
| Dynamic color | —— | Depends on brand: Enable it for native Android products seeking personalization; disable it and use fixed brand colors for strongly brand-bound products (banks/luxury/explicit VI). |
| Type scale | Follow "clear contrast between adjacent sizes" "≤5 styles" | Specific typeface, scaling factor, which size steps to use |
| Shape / corner radius | —— | The safest brand lever(rounded = friendly, square/cut corners = rugged); can be changed freely without harming usability |
| Elevation / shadows | Contrast between adjacent interactive layers must be sufficient (layering must be visible) | Whether to use tonal difference or shadows, shadow intensity |
| Motion duration | Follow "exits shorter than enters" "don’t be too short or too long" | Specific ms values, easing curve style |
| Window size classes | Follow "class-based not device-based" "text 40–60 characters per line" "FAB centered" | Specific layout forms at each breakpoint |
One-sentence review core principle for PMs: First check the red lines(is contrast sufficient / minimum tappable element ≥48dp / is there a keyboard focus state / are color role pairings correct); reject immediately if these fail. Then look at brand items(dynamic color toggle / corner radius / typography); these are areas to discuss tone with designers, not matters of right or wrong. The real value of M3’s engineering approach (design tokens + semantic colors) is making "change once, consistent across the whole site" work; during review you can also ask designers in reverse: "Is this value hardcoded or using a token?" — only token-based values hold up to future skinning/dark mode/multi-platform adaptation.
Compiled and distilled from Will’s Notion design notes area Google Material Design(123.md articles, 12 categories). Due to the large volume, it was synthesized and condensed(ingest_quality: synthesized): Focused reading of overview/Guidelines-level documents for each category + core rule pages for color/typography/shape/elevation/layout/interaction/accessibility/content; component details (around 70 Guidelines articles for buttons/cards/dialogs etc.) were distilled along representative dimensions of "shape level/state applicability lists", not copied article by article. Original images/videos (.mp4 motion demos, color scheme screenshots, grid diagrams) contain paths with Chinese spaces and are gitignored, retained in sources; this article uses textual descriptions instead. For the general "what is a design system" theory (Design System vs Style Guide / adoption·adaptation·building your own / icon usability / visual style cycles), see NNGroup Design Systems · Icons · Visual Style · Motion · Visual Testing (19 articles · Design systems vs style guides · 4 icon usability standards/Recognition vs interpretability · Skeuomorphism/Glassmorphism/Flat design/Neumorphism · Clickable element recognition + banner blindness · 6 uses of animation and motion · Visual testing: Attitude vs behavior/Desirability Toolkit/Mood boards); for visual design principles, see NNGroup Visual Design Principles · Gestalt Grouping · Visual Hierarchy · Typography · Color · Imagery (19 articles · 5 core visual principles/Gestalt proximity-similarity-closure-common region/Visual hierarchy-grids-golden ratio/Typography terminology-pairing-readable typefaces/60-30-10 color rule/Picture superiority effect-photography-imagery/Aesthetic-usability effect/Glossary).
Sources and related materials
- NNGroup Design Systems · Icons · Visual Style · Motion · Visual Testing (19 articles · Design systems vs style guides · 4 icon usability standards/Recognition vs interpretability · Skeuomorphism/Glassmorphism/Flat design/Neumorphism · Clickable element recognition + banner blindness · 6 uses of animation and motion · Visual testing: Attitude vs behavior/Desirability Toolkit/Mood boards)
- NNGroup Visual Design Principles · Gestalt Grouping · Visual Hierarchy · Typography · Color · Imagery (19 articles · 5 core visual principles/Gestalt proximity-similarity-closure-common region/Visual hierarchy-grids-golden ratio/Typography terminology-pairing-readable typefaces/60-30-10 color rule/Picture superiority effect-photography-imagery/Aesthetic-usability effect/Glossary)