Elevation Foundation
Build an AI-ready Elevation Foundation without starting from scratch
Turn random shadows into a clear surface and depth system your team can customize, document, and hand off to development
Trusted by Designers from
Elevation gets messy when shadows are used without clear purpose. Most teams lack shared rules for depth, overlays, and implementation
_
Most elevation systems stop before they become usable infrastructure
Having shadow values is not the same as having levels, surface logic, overlay rules, dark mode behavior, and handoff guidance
of teams connect tokens across design tools, code, and documentation
Source: zeroheight, 2026
+
of developers and designers say handoff between design and code could be improved
Source: Figma, 2025
1
Local shadows
Shadow values chosen locally without shared depth logic or usage rules
2
Shadow styles
Reusable shadow styles grouped by visual appearance or intensity
3
Elevation scale
Depth levels and shadow values organized into a structured token scale
4
Semantic roles
Elevation tokens mapped to surfaces, overlays, and modals
5
Documented rules
Rules for hierarchy, overlays, dark mode, and edge cases
6
System layer
AI context, handoff, modes, and team knowledge work from one model
Bring structure to your elevation system, wherever you're starting from
Start from scratch, clean up existing shadow styles, prepare handoff, or customize your surface hierarchy with AI
Start with hierarchy, not just shadows
Turn shadow values into a system for surface relationships, overlays, and depth
Turn shadows into a system
Audit existing shadows, clean up inconsistent depth, and define reusable elevation rules
Use AI without breaking depth logic
Adapt elevation, shadows, and overlays with AI while preserving system structure
Bridge between design and code
Connect elevation roles to token meaning, dark mode behavior, and implementation rules
From random shadows to a clear surface and depth system
Turn shadow values into elevation levels, surface hierarchy, overlay rules, and developer-ready handoff
Random shadow values without clear usage
Defined elevation levels with clear usage logic
Shadows used as decoration
Depth tied to hierarchy and surface relationships
Developers guess which shadow value to use
Developer-readable elevation handoff
Surface hierarchy handled manually
Surface and overlay rules documented
Overlay depth differs across patterns
Dark mode elevation guidance built in
Dark mode shadows are undefined or inconsistent
Shadow tokens mapped to implementation rules
Turn visual shadow choices into reusable system roles
Replace disconnected shadows with semantic roles for surfaces, raised areas, overlays, dark mode, and handoff
Before
Visual shadows, mixed usage, unclear depth logic, and repeated decisions
After
Elevation levels, surface hierarchy, overlay rules, dark mode guidance, and dev handoff
Customize, document, and hand off your elevation foundation
Adapt elevation roles, document hierarchy, and give developers the logic behind depth, overlays, and dark mode
Figma file
fig
Build from a structured elevation foundation with tokens, depth levels, shadow styles, and documentation in one file
Setup guide
Customize your elevation scale, shadow values, surface hierarchy, and workflow step by step without breaking the system structure
AI prompts
Audit shadows, adapt elevation roles, review surface clarity risks, and prepare handoff with repeatable prompts
AI context
Md
Give an LLM the elevation rules and constraints for safer customization
NotebookLM source
Md
Explore the system and generate briefings from one source
Accessibility
Md
Review surface separation, overlay clarity, dark mode cues, and visual noise risks
Dev handoff
Md
Explain elevation roles, token mapping, overlay rules, and implementation guidance
Make elevation decisions easier for devs to implement consistently
The dev handoff file explains elevation roles, shadow values, overlay rules, and dark mode behavior before implementation
Token meaning
Explain what elevation tokens represent and how to use them in design and code
Surface hierarchy
Clarify surface, raised, overlay, popover, and modal relationships across product surfaces
Usage rules
Show where elevation roles should and should not be used to avoid local exceptions
Implementation notes
Give developers the logic behind shadow values and implementation
Use AI with elevation system context, not generic prompts
Give Claude or another LLM the rules, constraints, and depth logic it needs to help without inventing a new system
OpenAI frames context optimization as a core lever for improving LLM accuracy
Source: OpenAI, LLM Accuracy Guide
Role-safe changes
Adapt elevation scale, shadows, overlays, and naming without breaking the system model
System-aware audit
Find duplicate shadows, unclear roles, inconsistent depth, and weak overlay logic
Accessibility review
Check surface separation, overlay hierarchy, dark mode cues, and visual noise
Handoff-ready notes
Turn elevation logic into clearer implementation explanations for developers
The defined path, stack, and instructions are rigid enough to give the process structure and dynamic enough to apply to your own creations
John Curley
UX/UI Designer
Use Elevation Foundation when depth decisions get inconsistent
Whether you are starting from scratch, cleaning up shadow styles, defining overlay hierarchy, or preparing developer handoff
Start from scratch with an elevation system
When you are building a new product or design system, elevation decisions can turn into disconnected shadow styles quickly. Elevation Foundation gives you a structured model from day one: depth levels, shadow tokens, surface roles, documentation, AI context, accessibility notes, and developer handoff
Outcome
You start with an elevation foundation that is ready to customize instead of inventing every rule from zero
Adapt existing shadows into product roles
Audit messy shadows and layer gaps
Prepare handoff without guesswork
Deliver client-ready elevation foundations
Built for teams and designers working on surface hierarchy
Use Elevation Foundation when depth decisions need to be structured, customized, documented, and handed off
01
Product designers
Keep interfaces consistent with reusable elevation roles across products
02
UI designers
Turn visual shadow choices into clear rules for hierarchy, surface separation, and depth
03
Freelancers and agencies
Deliver client-ready elevation foundations with documentation, AI context, and handoff
04
Design system leads
Standardize shadows with clearer roles, naming, dark mode behavior, and usage rules
Based on analysis of 100+ design systems. Patterns translated into a reusable elevation foundation
Since 2023, Design Systems Surf has cataloged mature design systems across foundations, components, documentation, and implementation patterns.
Elevation Foundation turns that research into reusable depth roles, surface hierarchy rules, AI context, accessibility guidance, and handoff.
Save 24–36 hours on elevation system work and documentation
Elevation Foundation removes repetitive setup, documentation, AI context, accessibility, and handoff work
Trusted by designers working on design systems
Feedback from people building, auditing, documenting, and maintaining design systems
10k+
Designers across 175+ countries follow Design Systems Surf for design system examples, patterns, and practical resources
What to know before you start
Clear answers about what Elevation Foundation includes, how it can be customized, and how it fits into real design system work
Is this just a Figma template?
No. The Figma file is one part of the package. Elevation Foundation also includes AI context .md, NotebookLM source .md, setup guidance, AI prompts, accessibility .md, and dev handoff .md.
The Figma file gives you the working elevation system. The Markdown files support different AI workflows: customization, knowledge exploration, accessibility review, and developer handoff.
What is included?
Can I customize it?
Will this fit my brand?
Can I use it with an existing design system?
Do I need to use AI?
Are the Markdown files standalone guides?
What does the NotebookLM source do?
What does the accessibility file do?
What does the dev handoff file do?
Does this include components?
Does this support dark mode elevation?
Who is this for?
Is this for beginners or advanced teams?
How is this different from building it myself?
Will developers be able to use it?
Can I use this for client work?
What is not included?
Still have questions?
Reach out at hey@designsystems.surf
