meta-display-design

name	meta-display-design
description	Load when the user is designing UX for Meta Ray-Ban Display — glanceable HUD patterns, micro-app archetypes (transit, cooking, lists), additive-display color rules, voice vs gesture choice, audio cues, motion safety. Don't load for technical Web App wiring — that's meta-display-webapps.
license	MIT
metadata	{"author":"HKTITAN","version":"1.0.0","graph":true,"depends":["meta-wearables"]}

Meta Display — design patterns for the additive HUD

A Web App on Meta Ray-Ban Display is not a small phone app. It runs in a 600×600 additive overlay on the world, in 2-second glances, with a D-pad and no continuous cursor. The patterns that work are narrower than they look. This skill is the design layer that sits next to the Web Apps technical skill.

The cross-vendor foundation for these principles lives in GUIDELINES.md at the repo root — the bible for display-wearable design. This skill is the Meta-specific application; read GUIDELINES.md for the universal principles, this skill for what's specific to MRBD.

When to load

Triggers:

• "Design for display glasses"
• "HUD UX"
• "Glanceable interface"
• "Micro-app patterns"
• "Additive display color"
• "Walking-and-using-glasses safety"

Don't load for:

• Technical Web App wiring — see [[../meta-display-webapps/SKILL]].
• DAT-based mobile-app UI — the design surface is the phone, not the glasses.
• Choosing devices — see [[../meta-wearables/SKILL]].

Decide first

The design decisions before code:

1. Glance budget — what can the user accomplish in a 2-second look? If your answer is "open the app and start configuring," you're designing for phones, not glasses.
2. Single primary action — what's the one thing this screen is for? Apps with multiple peer-level actions fail on a D-pad.
3. Voice or gesture? Voice is system-level (Meta AI) and not exposed to Web Apps; gesture is your primary input — see [[references/voice-vs-gesture]].
4. Context of use — walking, cooking, transit, sitting? Each has different safety constraints — see [[references/motion-safety]].

Map of content

Foundations

• [[references/glanceable-principle]] — the 2-second budget and why apps that fail it never get used.
• [[references/single-glance-decisions]] — one decision per screen as the universal rule.
• [[references/micro-app-archetypes]] — the small handful of shapes that actually work today.

Visual language

• [[references/additive-color-language]] — beyond "dark background, bright UI" — what designers should actually pick.
• [[references/iconography]] — silhouette-first icons for tiny additive surfaces.

Input language

• [[references/voice-vs-gesture]] — when voice is the right answer and when (today) it isn't available.
• [[references/audio-cues]] — sound design as part of the UX, not the soundtrack.

Concrete archetypes

• [[references/transit-pattern]] — minute-scale, glanceable, low-state.
• [[references/cooking-pattern]] — hands-free progression, audio prompts.
• [[references/list-pattern]] — focus-driven scrolling lists with paginated state.

Safety and accessibility

• [[references/motion-safety]] — designing for the user who is walking, driving, or carrying something.
• [[references/accessibility]] — text scaling, contrast, vision-impaired use, the realities of additive display.

Verify

Before claiming a design is "ready for glasses":

• Every primary action is completable in under 2 seconds of glance, measured.
• Every screen has exactly one primary action; secondary actions are deferred or hidden.
• All interactive elements are focus-reachable (D-pad-only).
• Background is dark; UI is high-contrast; type meets the 16/24 px floors.
• Critical state changes have an audio cue, not just a visual one.
• Motion context is considered — does the app work while the user walks?
• No flow assumes voice input where voice isn't exposed (Web Apps today).
• You've shown the design to a non-designer who can describe what each screen does without explanation.

Smoke test

If this skill loaded correctly, the agent should answer:

1. Can my glasses app use Meta AI's voice for user input? (Expected: not directly — voice is system-level; Web Apps cannot subscribe to voice input today; cites [[references/voice-vs-gesture]].)
2. What's a good "transit" micro-app pattern? (Expected: next-step prompt + arrival time, paginated by D-pad, audio cue on action; cites [[references/transit-pattern]].)
3. Why should I use audio cues even for visual state changes? (Expected: glasses are worn, not held; eyes are often elsewhere; audio carries when vision can't be relied on; cites [[references/audio-cues]].)

Sibling skills

• [[../meta-wearables/SKILL]] — picking a device.
• [[../meta-display-webapps/SKILL]] — the technical surface this design layer rides on.
• [[../meta-wearables-dat/SKILL]] — for DAT-based mobile-app UI, this skill applies less; the phone is the design surface.

Cross-vendor reference

• GUIDELINES.md at the repo root — the cross-vendor design bible. This skill is the Meta-specific application of those principles.

Sources

• Meta Ray-Ban Display launch — https://www.meta.com/blog/meta-ray-ban-display-ai-glasses-connect-2025/
• Web Apps build (UI guidance inline) — https://wearables.developer.meta.com/docs/develop/webapps/build/
• Build for Display Glasses (intent + use-case examples) — https://developers.meta.com/blog/build-for-display-glasses/