Create or improve visual depth so layers, surfaces, and states feel intentional, readable, and physically believable without drifting into over-styled noise.
MANDATORY PREPARATION
Users start this workflow with /depth. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first.
Assess Depth Problems
Analyze where the interface feels flat, confusing, or physically inconsistent:
Elevation structure:
- Are all components using the same shadow regardless of job?
- Is it hard to tell what sits on the page versus above it?
Surface treatment:
- Which elements should feel raised?
- Which should feel inset, like inputs or wells?
- Are there places where color alone could suggest depth more cleanly than stronger effects?
Interaction states:
- Do pressed buttons feel like they move inward or just change color?
- Does dragging feel like an item pops forward above its neighbors?
Restraint:
- Are shadows and effects helping users understand structure, or just making the UI look busier?
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
CRITICAL: Depth should explain surfaces, states, and layering. If the effect is louder than the meaning, it has gone too far.
Plan the Depth System
Consult the elevation system for shadow levels, two-part shadow logic, raised/inset mapping, and flat depth via color.
Consult the surface separation when deciding whether depth should come from spacing, background shifts, overlap, borders, or shadows.
Consult the image treatment when overlapping media or image boundaries need cleaner depth cues.
Create a plan around:
- Elevation levels: Which 3–5 semantic levels exist?
- Surface roles: Which things are base, raised, inset, pressed, or dragged?
- Layering: Where can overlap clarify structure?
- Restraint: Which effects should be reduced or removed entirely?
Build Depth Systematically
Establish an Elevation System
- Define a small set of semantic levels for surfaces, controls, menus, overlays, and temporary UI
- Keep similar components on the same elevation unless there is a real reason to separate them
Raised and Inset Elements
- Raised elements should feel like they sit above the page with a shadow beneath them
- Inset elements should feel recessed through inner shadow, lip treatment, or darker surrounding surface
- Use raised and inset treatments deliberately — not every control needs obvious realism
Two-Part Shadow Logic
- Use a larger, softer shadow to suggest distance from the surface
- Use a smaller, tighter shadow near the edge to suggest compressed ambient shadow
- As elevation increases, the tight near-edge shadow should usually become subtler
Pressed and Dragged States
- Pressed states should reduce elevation and feel like the element moves inward/downward
- Dragged states should increase elevation so the item feels like it pops forward
- Match shadow, transform, and any color shift so the motion reads as a single physical change
Overlap and Layering
- Use overlap when it helps clarify multiple layers of information
- Let cards, controls, or media cross boundaries when it reinforces depth and grouping
- Keep overlaps readable; add separation or background-matching edges if layers start to clash
Flat Depth via Surface Color
- Lighter surfaces often feel closer, darker surfaces often feel further away
- Before adding more shadow, test whether a subtle surface-color shift communicates the same thing more cleanly
Don’t Get Carried Away
- Borrow cues from the real world, but stop before the interface feels photo-realistic or busy
- If the structure is already clear, simpler depth usually wins
NEVER:
- Use the same drop shadow for every component
- Add heavy shadows where color or spacing would communicate depth better
- Make every button, card, panel, and modal feel equally elevated
- Let realism overpower clarity
- Use depth effects with no semantic meaning
Verify Depth Quality
- Layer clarity: Is it obvious what sits on the page and what floats above it?
- State clarity: Do pressed and dragged states feel physically different?
- Consistency: Are similar components using the same elevation language?
- Restraint: Does the UI feel more understandable, not just more decorated?
Remember: Great depth creates structure, not spectacle. Use it to make layers and states feel obvious, then stop.
1---2name: depth3description: Add or refine depth through elevation systems, raised and inset surfaces, layered overlap, and meaningful shadow behavior so interfaces feel structured instead of flat. Use when the user mentions depth, elevation, shadows, layering, flat cards, pressed states, drag feedback, or inset controls.4---5
6Create or improve visual depth so layers, surfaces, and states feel intentional, readable, and physically believable without drifting into over-styled noise.
7
8## MANDATORY PREPARATION
9
10Users start this workflow with `/depth`. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first.
11
12---
13
14## Assess Depth Problems
15
16Analyze where the interface feels flat, confusing, or physically inconsistent:
17
181. **Elevation structure**:
19 - Are all components using the same shadow regardless of job?
20 - Is it hard to tell what sits on the page versus above it?
21
222. **Surface treatment**:
23 - Which elements should feel raised?
24 - Which should feel inset, like inputs or wells?
25 - Are there places where color alone could suggest depth more cleanly than stronger effects?
26
273. **Interaction states**:
28 - Do pressed buttons feel like they move inward or just change color?
29 - Does dragging feel like an item pops forward above its neighbors?
30
314. **Restraint**:
32 - Are shadows and effects helping users understand structure, or just making the UI look busier?
33
34If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
35
36**CRITICAL**: Depth should explain surfaces, states, and layering. If the effect is louder than the meaning, it has gone too far.
37
38## Plan the Depth System
39
40Consult the [elevation system](../frontend-design/reference/elevation-system.md) for shadow levels, two-part shadow logic, raised/inset mapping, and flat depth via color.
41Consult the [surface separation](../frontend-design/reference/surface-separation.md) when deciding whether depth should come from spacing, background shifts, overlap, borders, or shadows.
42Consult the [image treatment](../frontend-design/reference/image-treatment.md) when overlapping media or image boundaries need cleaner depth cues.
43
44Create a plan around:
45- **Elevation levels**: Which 3–5 semantic levels exist?
46- **Surface roles**: Which things are base, raised, inset, pressed, or dragged?
47- **Layering**: Where can overlap clarify structure?
48- **Restraint**: Which effects should be reduced or removed entirely?
49
50## Build Depth Systematically
51
52### Establish an Elevation System
53- Define a small set of semantic levels for surfaces, controls, menus, overlays, and temporary UI
54- Keep similar components on the same elevation unless there is a real reason to separate them
55
56### Raised and Inset Elements
57- Raised elements should feel like they sit above the page with a shadow beneath them
58- Inset elements should feel recessed through inner shadow, lip treatment, or darker surrounding surface
59- Use raised and inset treatments deliberately — not every control needs obvious realism
60
61### Two-Part Shadow Logic
62- Use a larger, softer shadow to suggest distance from the surface
63- Use a smaller, tighter shadow near the edge to suggest compressed ambient shadow
64- As elevation increases, the tight near-edge shadow should usually become subtler
65
66### Pressed and Dragged States
67- Pressed states should reduce elevation and feel like the element moves inward/downward
68- Dragged states should increase elevation so the item feels like it pops forward
69- Match shadow, transform, and any color shift so the motion reads as a single physical change
70
71### Overlap and Layering
72- Use overlap when it helps clarify multiple layers of information
73- Let cards, controls, or media cross boundaries when it reinforces depth and grouping
74- Keep overlaps readable; add separation or background-matching edges if layers start to clash
75
76### Flat Depth via Surface Color
77- Lighter surfaces often feel closer, darker surfaces often feel further away
78- Before adding more shadow, test whether a subtle surface-color shift communicates the same thing more cleanly
79
80### Don’t Get Carried Away
81- Borrow cues from the real world, but stop before the interface feels photo-realistic or busy
82- If the structure is already clear, simpler depth usually wins
83
84**NEVER**:
85- Use the same drop shadow for every component
86- Add heavy shadows where color or spacing would communicate depth better
87- Make every button, card, panel, and modal feel equally elevated
88- Let realism overpower clarity
89- Use depth effects with no semantic meaning
90
91## Verify Depth Quality
92
93- **Layer clarity**: Is it obvious what sits on the page and what floats above it?
94- **State clarity**: Do pressed and dragged states feel physically different?
95- **Consistency**: Are similar components using the same elevation language?
96- **Restraint**: Does the UI feel more understandable, not just more decorated?
97
98Remember: Great depth creates structure, not spectacle. Use it to make layers and states feel obvious, then stop.