In a design system, what do elevation levels communicate, and why define a few named levels rather than per-component shadows?
answer
- distance between surfaces
- above, temporary, or in focus
- one light source for every shadow
- components reference a level by role
- if everything floats, nothing does
basics
~20 sElevation levels show how far a surface sits above others, signalling hierarchy, temporariness and focus. A few named levels, each mapped to one shadow or tone, keep one consistent light model and let the system retune depth in one place.
solid answer
~40 s**Elevation** is the perceived distance between surfaces along the depth axis. It tells users which surface is on top, which is temporary (a menu, a sheet, a dialog), and where to look. A design system defines a **small set of named levels**, such as resting, raised, overlay and modal, each mapped to one shadow token in light themes and usually to a surface tone in dark ones. Components reference a level by role ("menu surface") rather than inventing shadows, so every shadow shares one light direction and softness progression, a level can be retuned once, and review can spot an off-scale shadow. The discipline also stops elevation becoming decoration: if every card in a game companion app's inventory is raised, nothing stands out when a trade dialog opens over it.
go deeper
Recall that elevation shows which surface is on top and temporary, and use the system's named levels by role instead of writing shadows.
Explain why one light model and a few named levels beat per-component shadows, and how levels map to shadows in light themes and tones in dark ones.
Show how you would audit a library whose shadows have drifted, collapse them onto the scale, and define which state changes may raise a surface.
Weigh how many levels the system should expose across web and native, and how strictly to restrict elevation changes to keep the hierarchy readable.
## What elevation is **Elevation** is the apparent distance between two surfaces along the depth axis, the axis pointing out of the screen. People read depth from cues they know from the physical world: a surface nearer the light casts a larger, softer shadow and may look slightly lighter. A design system uses those cues deliberately to communicate three things: - **Hierarchy**: which surface sits on top of which. - **Temporariness**: menus, sheets and dialogs float because they will go away; the page underneath is permanent. - **Focus**: the highest surface is where attention should be. ## A small set of named levels Instead of letting each component pick its own shadow, the system defines a handful of **elevation levels** and maps each to a visual treatment. In a multiplayer game's companion app it might look like this: | Level | Typical surfaces in the app | Light-theme treatment | |---|---|---| | 0, flat | lobby background, match-history list | no shadow | | 1, resting | loadout cards, friend tiles | small, tight shadow | | 2, raised | sticky header once the list scrolls under it, a card being dragged | slightly larger shadow | | 3, overlay | menus, the squad-invite sheet | larger, softer shadow | | 4, modal | the match-result dialog above a dimming scrim | largest, softest shadow | Each level becomes a **shadow token** (a bundle of colour, offset, blur and spread values) and, for dark themes, usually a **surface tone** as well. Components refer to the level by role, for example "menu surface" or "dialog surface", never to raw shadow values. ## Why named levels beat per-component shadows 1. **One light model.** All shadows share one light direction and one progression: higher levels get larger offsets and more blur, and the shadow gets softer as the surface rises. Hand-made shadows drift in direction, colour and softness until surfaces look lit by different lamps. 2. **Change in one place.** When research shows overlays are too heavy, the overlay level is tuned once and every menu, sheet and popover follows. 3. **Reviewable.** A spec that says "level 3" can be checked; a shadow with bespoke numbers can only be eyeballed. 4. **Portable across platforms.** Web and native platforms render shadows with different parameters. A named level can be mapped to each platform's closest rendering, so the same component reads at the same depth everywhere, even if the exact pixels differ. 5. **Pairs with dark themes.** Because the level is the unit, a dark theme can express it through tone instead of shadow without touching the components. ## Elevation can change with state Elevation is not only fixed per component. A header can rise from level 0 to level 2 when content scrolls underneath it, signalling that it now floats. A card can rise while it is dragged and settle when dropped. The level change is the signal; the system defines which transitions are allowed so that no surface jumps two levels for a hover. ## Auditing a library whose shadows have drifted 1. Collect every shadow value in use across components and screens. 2. Group them by the role of the surface that uses them: resting, raised, overlay, modal. 3. Map each group onto the nearest named level, and treat outliers as design questions rather than reasons for new levels. 4. Replace the raw values with level references, and make any new raw shadow visible in review. Such an audit usually shows dozens of values collapsing onto four or five levels, which is the strongest argument for the scale. ## Pitfalls - **Elevation as decoration.** Raising every card to make it "pop" flattens the hierarchy: when everything floats, a real overlay has nothing to stand out against. - **Too many levels.** Ten levels that differ by one pixel of blur cannot be told apart; users perceive only a few distinct depths. - **Heavy, dark shadows.** Hard black shadows look dated and dirty; most systems use soft, low-opacity shadows, sometimes two layered together, as common practice rather than a rule. - **Shadow as the only boundary of a control.** A text field defined only by a faint shadow may be hard to see; its boundary needs a cue with enough contrast, which is an accessibility question in its own right. - **Level and layer disagreeing.** A menu that appears above a dialog but casts a smaller shadow sends a mixed signal; the visual level should follow the stacking order.
- How many elevation levels does a design system typically need?Usually a handful, often four to six including flat. Users perceive only a few distinct depths, so levels that differ by a pixel of blur are indistinguishable and invite arbitrary choices. Start from the surface roles the product actually has, resting content, raised or scrolled-under bars, overlays and modals, and add a level only when a role cannot be expressed with an existing one.
- Why should a surface's elevation be allowed to change at runtime?Because the change itself communicates. A header that gains elevation when content scrolls beneath it shows it now floats; a card that rises while dragged shows it is lifted out of the list. The system should define these transitions, which states raise a surface and by how much, so teams do not invent their own and blur the hierarchy.
saying these in an interview costs you the question
- Raising every card makes the whole interface feel more premium.
- Each component should tune its own shadow to look best in isolation.
- More elevation levels always give designers useful flexibility.
- A shadow is enough to show where a text field's boundary is.
- Elevation is purely decorative and carries no meaning for users.