"Beyond the screen" does not have to mean a headset. The most useful ideas from spatial computing already apply to the phones and browsers people use every day: depth tells people what matters, motion explains what changed, and sound and touch confirm what just happened. Here is how I design those layers in real web and app interfaces today, and why doing so prepares a product for spatial platforms later.

Every interaction asks a question

Each tap, click or swipe carries an unspoken question: did that work? A purely visual interface often answers it weakly. Phones get used in bright sunlight, on the move, with half an eye on something else. Feedback that arrives through more than one sense answers the question with confidence.

It is also an accessibility issue. If an error is shown only by turning a border red, people with colour vision deficiency may miss it entirely. The principle I design by is redundant feedback: important events are communicated through at least two channels, such as colour plus text, or motion plus a haptic tap.

Depth: hierarchy on the Z-axis

Give elevation a meaning

Shadows and layers should not be decoration. I define a small elevation scale and attach a meaning to each level:

Base: the page itself.
Raised: cards and interactive surfaces.
Floating: dropdowns, tooltips and sticky bars.
Overlay: dialogs and sheets that block what is beneath.

Higher layers get larger, softer shadows. In dark mode, shadows almost disappear, so elevation is shown by making higher surfaces slightly lighter instead, an approach popularised by Material Design.

Use glass and blur carefully

Translucent, blurred panels keep people aware of the context underneath, which is why they appear throughout Apple's platforms, including visionOS. They come with two costs:

Legibility. Text over a moving or colourful background can become unreadable. Add a tint behind the text and check contrast against the busiest background the panel can sit on, not the calmest.
Performance. Background blur is GPU work. Large blurred areas, or several stacked ones, can cause dropped frames on mid-range phones.

My own site uses glass panels over a live fluid simulation and a colour theme that changes on every visit, so each panel has to stay readable in the worst case, not just the screenshot case.

Parallax in moderation

Small depth offsets on scroll add richness. Large ones cause discomfort for people with vestibular sensitivity. Keep offsets subtle and switch them off when the system's reduced-motion setting is on.

Motion: explain change, don't decorate it

Good interface motion answers two questions: where did that come from, and where did it go? The rules I rely on:

Keep it short. Small feedback such as presses and toggles works at roughly 100 to 200 milliseconds. Larger transitions like panels and page changes sit around 200 to 400 milliseconds. Anything longer feels slow on repeat use.
Ease with intent. Elements entering the screen decelerate as they arrive, which is ease-out. Elements leaving accelerate away, which is ease-in. Anything the user drags directly should follow the finger and settle with a spring.
Preserve continuity. If a card expands into a detail view, animate it from the card's position, not from nowhere. The View Transitions API, now available in modern browsers, makes this far easier on the web than it used to be.
Stay interruptible. Nobody should have to wait for an animation to finish before acting.
Animate cheaply. Stick to transform and opacity where possible, which browsers can composite without recalculating layout.
Respect reduced motion. Replace movement with a quick fade rather than removing the feedback entirely.

Sound: the most underused channel on the web

Sound is everywhere in apps and games and almost absent from websites. Used well, it adds confidence and character. Used badly, it gets a site muted or closed. My rules:

Opt-in by design. Browsers block audio until the user interacts with the page, so sound should start after a gesture and always come with a visible mute that remembers its setting.
Short and quiet. Interface sounds should be brief ticks and tones, sitting well below any content audio.
One tonal family. Sounds that share a key and timbre feel designed; a grab bag of sound effects feels like a toy.
Never the only signal. Many people browse with sound off.
Step aside for content. On makashif.com, the ambient soundscape fades out when you play a video, stays quiet while that video is paused but still on screen, and returns only once it has left the viewport.

The Web Audio API can also synthesise sound live instead of loading audio files, which means sound can respond to input. When you paint with the fluid on my site, your stroke speed picks a note from the chord the background music is playing, and your horizontal position pans it left or right, so whatever you draw stays in key.

Haptics: touch that confirms

On mobile, haptics close the loop that a physical button used to close.

iOS offers impact, selection and notification feedback through UIKit's feedback generators, plus Core Haptics for custom patterns.
Android provides haptic feedback constants on views, and VibrationEffect for finer control.
React Native and Flutter expose the same capabilities through haptics packages and platform APIs.
The web has the Vibration API, which works in Chrome on Android but not in Safari on iOS, so treat it as a progressive enhancement.

Map haptics to meaning: a selection tick for pickers and snap points, a light impact for toggles, and distinct success, warning and error notifications. Do not vibrate on every tap, and respect the user's system settings.

Design feedback as a system

Rather than choosing feedback component by component, I define it once for the whole product. A simple matrix covers most interfaces:

Press: the button scales down slightly in about 100 milliseconds, with an optional soft tick and a light haptic on mobile.
Toggle: the thumb slides with a spring, a quiet click plays, and a light impact confirms it.
Select or snap: a highlight moves to the new item with a selection tick and no sound.
Success: a check mark draws in, a short rising tone plays, and a success haptic fires.
Error: the field is outlined, a clear message appears, an optional small shake runs unless reduced motion is on, and a low tone and error haptic follow.

Documented like this, feedback becomes consistent, testable and easy for any developer to implement.

The horizon: spatial computing

Headsets like Apple Vision Pro and Meta Quest make depth, motion and sound the default rather than the enhancement. Interfaces float in the room, people select with their eyes and hands, and audio is positioned in space. Some details change completely. On visionOS, for example, apps do not receive raw eye-tracking data for privacy reasons; the system draws the hover highlight itself, and interactive targets need to be generous, with Apple's guidelines calling for around 60 points.

You do not need to build for headsets today unless your audience is there. But a product with a clear elevation scale, purposeful motion and a defined feedback system is already speaking the language spatial platforms use. Whether I am building cross-platform apps or designing interface motion, these are the foundations I put in place first.

Key takeaways

Communicate important events through at least two channels, and never through colour alone.
Give each elevation level a meaning, and test glass panels against the worst background they can sit on.
Keep motion short, purposeful, interruptible and respectful of reduced-motion settings.
Make sound opt-in, quiet and tonally consistent, and have it step aside for content.
Map haptics to meaning, and define all feedback once as a product-wide system.

Planning a project? Book a free discovery call — I'll tell you honestly what it needs.

UX Beyond the Screen — Depth, Motion, Sound and Haptics in Modern Interfaces