Depth with purpose: how Elevation adds realism and hierarchy
Oct 15, 2025
5 min read
Elevation is the invisible structure that gives interfaces depth and order. It shows what floats above, what stays fixed, and what fades into the background — guiding the eye and clarifying hierarchy.
Why elevation matters
Elevation in Design System is a key part of how users understand hierarchy in digital interfaces. Just like spacing or color, it helps establish relationships between elements — what sits above, what belongs together, and what demands attention.
In practice, elevation is often expressed through CSS shadows, layering, or visual separation. A card with a subtle shadow appears to float above the background. A modal with a deeper shadow signals that it interrupts the flow and takes priority. These cues work before a single click — they guide perception instantly.
When elevation is used consistently, it supports clarity. It creates rhythm in dense layouts, helps distinguish between persistent and temporary UI, and reinforces common interaction patterns — like dropdowns appearing above buttons or tooltips hovering over inputs.
Without a well-structured elevation system, systems can easily become visually noisy. Designers might apply arbitrary shadows, developers might guess z-index values, and users are left with an interface that feels inconsistent or hard to scan. Defining and documenting design system elevation levels helps teams reduce redundancy, friction, and confusion.
The building blocks of an elevation system
A well-structured elevation system gives teams a predictable set of layers to work with — not just a library of shadows. It defines how depth is created, named, and applied across both design tools and code.
Elevation levels
Most systems define a fixed number of elevation levels. These might start at 0 for flat content (like the base layout), and move up to 1 for cards, 2 for popups or dropdowns, and so on — typically capping around 5 or 6 to keep things simple. Each level represents a specific depth and should map to a consistent visual treatment.
Tokens and naming
Elevation is typically expressed through design tokens such as: elevation/level-0, elevation/level-1, elevation/modal, shadow/low, layer/card.
Some systems choose functional names (card, tooltip, modal), while others stick to numeric tiers (elevation-100, elevation-200). Either works — what matters is consistency and clarity across platforms.
Shadow, z-index, and layering
Elevation can be implemented in different ways:
In design (e.g., Figma): with shadow styles or tokenized effects.
In code: with box-shadow properties, z-index stacks, or both.
For instance, elevation-2 might correspond to a specific shadow style in Figma and to a z-index of 20 in CSS — depending on how your team structures layers.
It’s important to separate the semantic meaning of elevation (e.g., “this element sits above others”) from the visual implementation (e.g., what kind of shadow is applied). That separation gives you the flexibility to update the visuals without breaking the logic.
Keep it minimal
Too many elevation levels create decision fatigue. Most design systems operate well with just 4–6 clearly defined layers. Enough to cover layouts, cards, modals, and interactive overlays — no more than necessary.
Structuring elevation in Figma
For elevation to work across teams, it needs to live in both design and development — and speak the same language in both. That means going beyond visual styles and creating a shared system of tokens, naming, and documentation.
In Figma: Styles and Naming
Start by defining elevation levels as reusable shadow styles. These can follow a simple naming structure such as: Elevation / 01 — description: flat base surfaces, background layout containers, Elevation / 02 — description: cards, tiles, and secondary containers etc.
Assigning elevation styles to components makes depth predictable. Instead of creating one-off shadows, designers rely on a consistent scale that reflects the system’s structure.
Naming conventions
You can take a semantic approach (card, dropdown, modal) or a numeric one (level-100, elevation-2). Semantic names make intent clearer; numeric ones are easier to scale. The best systems often combine both — functional labels grouped within a clear structure and descriptions.
Keep it scalable
Whichever route you take, the structure should be easy to extend. Avoid one-off shadows and instead assign each elevation level to a distinct role. This makes it easier to audit and maintain over time — especially as the product evolves.
Elevation usage standards
A well-functioning elevation system isn’t just a set of tokens — it’s a shared understanding of how and when to use them.
Clear guidelines help teams know which level to use for a given component, how elevation behaves across layouts, and what rules to follow for consistency.
Typical use cases might look like:
elevation-0: flat base surfaces, background layout containerselevation-1: cards, tiles, and secondary containerselevation-2: dropdowns, flyouts, secondary navigationelevation-3: modals, dialogs, full-page overlays
Pairing these levels with visual examples strengthens understanding. A simple illustration showing cards vs. modals, or how elevation appears in both light and dark themes, can prevent ambiguity.
Why it matters
Without clear rules, elevation becomes a guessing game. One designer uses a strong shadow, another skips it, and developers are left unsure what was intended. Before long, the interface starts to feel messy — with shadows clashing, stacking orders conflicting, and no clear sense of depth.
The good news? Even a simple elevation guide in your design system can make a big difference. It doesn’t need to be perfect — just clear enough to help everyone stay on the same page.
Accessibility best practices
Elevation helps users understand structure — but not everyone perceives depth in the same way. Relying on shadows alone to communicate hierarchy can create barriers, especially in low-contrast environments or for users with visual impairments.
That’s why it’s important to design elevation with clarity, not subtlety. If two layers have different meanings, they should look meaningfully different, not just by a soft shadow blur.
A few good practices:
Combine elevation with other cues like spacing, background color, or borders.
Ensure shadows have enough contrast against the background, especially in light mode.
Test elevation styles in both light and dark themes to make sure depth is still readable.
Use elevation sparingly — the more layers compete for attention, the harder it is to scan.
Think of elevation as one part of a broader visual system. It shouldn’t carry the full weight of meaning — just help reinforce it. The most accessible elevation systems are those that work clearly for everyone, even at a glance.
Real-world examples
Many mature design systems handle elevation with clear levels, consistent tokens, and platform-agnostic logic. Here’s how a few of them do it — and what you can take away from their approach.
Material Design
Elevation in Material UI is one of the most structured. It uses a dp-based scale (1dp to 24dp) that maps to specific shadows and layering rules. Each level is tied to a functional role — cards, app bars, modals — and elevation is defined both visually and semantically. The system also adapts shadows for dark themes and includes motion guidance for elevation changes.
Takeaway: A numeric scale works well when paired with rich documentation and consistent mapping to components.
Atlassian Design System
Atlassian uses a token-based approach to elevation, with names like elevation.shadow.raised or elevation.surface.overlay. Each token represents a shadow style and a purpose. The system is restrained — only a few elevation levels are defined, but they’re used consistently across components and platforms.
Takeaway: You don’t need many layers. A few well-defined levels can be more effective than an overcomplicated scale.
USWDS (U.S. Web Design System)
USWDS defines elevation with a simple numeric scale (0 to 5) and encourages consistent layering via utility classes and tokens. The shadows themselves are subtle, and the system emphasizes semantic usage (e.g., use elevation-4 for modals across all U.S. government websites using the system).
Takeaway: Simplicity scales. A minimal elevation system backed by strong conventions can work across huge ecosystems.
Conclusion
Elevation is more than just a shadow — it’s a system of depth, clarity, and hierarchy. When thoughtfully defined, it helps users understand interfaces faster and interact with confidence. When neglected, it becomes a source of inconsistency and confusion.
By limiting elevation to a few clear levels, aligning design and code, and documenting usage with examples, you set your team up for success. Whether you’re refining a large system or starting from scratch, the key is consistency over complexity.
Want to see how other systems structure their elevation?
Browse our Design Systems Library and explore real-world approaches in action.
