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
Gemini Notebook
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?
Elevation Foundation includes a Figma file, AI context .md, NotebookLM source .md, setup guide, AI prompts, accessibility .md, and dev handoff .md.
The Figma file gives you elevation tokens, depth levels, shadow styles, surface roles, overlay rules, examples, and documentation. The Markdown files give AI tools the system context needed to help you customize, explore, review, document, and hand off your elevation foundation with less guesswork.
Can I customize it?
Yes. You can adapt shadow values, elevation levels, surface roles, overlay rules, dark mode behavior, and naming.
The goal is to customize the elevation system without breaking surface hierarchy, depth logic, accessibility review, or implementation meaning.
Will this fit my brand?
Elevation Foundation is not tied to one fixed shadow style. You bring your product or brand direction and map it into product-ready elevation roles.
If your current depth language has gaps, for example unclear overlay hierarchy, inconsistent card shadows, weak dark mode behavior, or too many local shadow exceptions, the setup workflow and AI-ready Markdown files help you identify what needs review before implementation.
Can I use it with an existing design system?
Yes. You can use Elevation Foundation as a reference model to audit or repair an existing elevation system.
It can help you find duplicate shadows, unclear semantic roles, inconsistent overlay depth, weak surface hierarchy, missing dark mode behavior, and gaps in developer handoff. You do not need to replace your whole design system to use it.
Do I need to use AI?
No. You can use the Figma file and setup workflow manually.
AI is optional, but several supporting files are designed primarily for AI-assisted workflows. The AI context .md helps with safe customization. The NotebookLM source .md helps with knowledge exploration, Q&A, and briefings. The accessibility .md helps AI review foundation-level elevation risks. The dev handoff .md helps AI generate developer-facing implementation notes.
Are the Markdown files standalone guides?
They are Markdown files, but they are not all traditional standalone guides.
You can read them manually, but their main purpose is to support AI-assisted workflows. Each .md file has a different role: customization context, NotebookLM knowledge source, accessibility review context, or developer handoff context.
What does the NotebookLM source do?
The NotebookLM source .md is a structured knowledge file for exploring the elevation foundation.
You can upload it to NotebookLM and ask questions about elevation roles, shadow tokens, surface hierarchy, overlay rules, dark mode behavior, accessibility concerns, and implementation guidance. It helps turn the foundation into a searchable knowledge source for you, your team, or your client.
What does the accessibility file do?
The accessibility .md is designed mainly for AI-assisted review.
It gives AI the review logic for foundation-level elevation risks such as surface separation, overlay hierarchy, contrast between elevated surfaces, dark mode depth cues, and excessive visual noise. It does not guarantee accessibility by itself. You still need to review the actual values and product usage after customization.
What does the dev handoff file do?
The dev handoff .md is designed mainly for AI-assisted handoff generation.
It gives AI the structure to generate developer-facing notes from your customized foundation, including elevation role meaning, shadow values, surface hierarchy, overlay rules, dark mode behavior, implementation risks, and CSS-oriented token mapping. Developers still need to adapt the output to their codebase, naming conventions, and token pipeline.
Does this include components?
No. Elevation Foundation covers the elevation foundation layer: depth tokens, shadow styles, semantic elevation roles, surface hierarchy rules, overlay logic, accessibility review logic, and developer handoff context.
It may include examples that show how the elevation roles work, but it is not a production component library.
Does this support dark mode elevation?
Yes. Elevation Foundation includes structure for reviewing light and dark mode elevation behavior.
You still need to review your actual values after customization, especially where shadows, surface contrast, and overlay hierarchy need to remain clear in dark mode.
Who is this for?
Elevation Foundation is for product designers, UI designers, freelancers, agencies, design system leads, design system engineers, consultants, and teams that need to build, repair, document, review, or hand off a structured elevation system.
Is this for beginners or advanced teams?
Both, but for different reasons.
For newer teams, it gives a structured starting point instead of a blank canvas. For mature teams, it works as an audit, repair, documentation, and handoff reference for weak or inconsistent elevation foundations.
How is this different from building it myself?
You can build this yourself. The difference is that you would need to create the token architecture, elevation scale, shadow styles, semantic elevation roles, overlay rules, dark mode guidance, setup workflow, AI context, NotebookLM source, prompts, accessibility review logic, and handoff structure from scratch.
Elevation Foundation gives you that structure so you can focus on adapting it to your product, brand, team, or client.
Will developers be able to use it?
Yes, but not as a drop-in code package.
The dev handoff .md helps generate developer-facing notes from the foundation. It explains elevation role meaning, shadow values, surface hierarchy, overlay usage, dark mode behavior, implementation risks, and CSS variable mapping. Developers still need to adapt the output to their codebase and implementation workflow.
Can I use this for client work?
Yes. You can use Elevation Foundation as part of paid client work and deliver a customized foundation to your client.
You cannot resell, redistribute, or repackage the original product as a standalone product or template unless the license explicitly allows it.
What is not included?
Elevation Foundation is not a UI kit, component library, shadow preset pack, visual effects library, glassmorphism pack, neumorphism pack, or automatic accessibility guarantee.
It gives you the foundation structure, workflow, AI-ready Markdown files, review logic, and handoff structure. You still need to customize values, review the result, and adapt implementation to your product or client environment.
Still have questions?
Reach out at hey@designsystems.surf
