Design

Eyes Best Practices

Updated: Sep 9, 2026

This page is for designers and developers building gaze interfaces. The guidance is platform-neutral and applies whether you build a 2D Android application, a Unity or Unreal project with Interaction SDK, a website or web app that users open in Meta Quest Browser, or a Spatial SDK application. Two topics fork by platform: how hover is delivered to your application, and what units you express target size in. The page covers button placement, target sizing and spacing, color theming, visual saliency, hover feedback, interaction timing, and close affordances.

🎓 Want a visual walkthrough of these gaze UI principles?

Designing UI for Gaze⁠ covers target sizing, spacing, hover behavior, and confirmation in a short video on Meta VR Academy.

Interface design requirements

Modifying an interface to accommodate gaze input requires fundamental changes to information architecture, content layout, interactions, and affordances. Key considerations include:

Sizing and spacing: To keep gaze input reliable, follow the guidance on the sizing and spacing of interactive elements. Maintain a minimum angular size for targets, and provide enough spacing between interactive elements to mitigate gaze-targeting error.
Visual feedback: Keep affordances and on-hover visual feedback minimal to avoid the Midas Touch effect, where an interface activates elements the user merely looks at. Minimal feedback also reduces gaze error and supports eye comfort. Reduce peripheral motion so that you can reliably guide a user’s eyes to the center of buttons.

Eye tracking availability

Eye tracking is a device feature. It can be unavailable on a given device, and it can drop out while your application is running. Targeting then falls back to the hand or controller ray, and to head gaze only when no hand or controller tracking is available. The 3 degree minimum on this page is an eye-tracking figure, and its precision assumptions do not carry over to those fallbacks. Ensure other input modalities are also supported, and design your interface to degrade gracefully when gaze precision changes.

Progressive disclosure

Hover delivery depends on how you build your application

2D Android applications do not receive gaze hover events. The system renders hover feedback on your behalf, progressive disclosure on hover will not work, and no user flow may depend on hover state. See Look and Pinch for 2D apps.

Web content in Browser does not receive gaze hover events. The system renders hover feedback on your behalf, so looking at an element does not fire :hover styles or pointer events, and no user flow may depend on hover state. This matches how a touchscreen behaves: the page learns about the interaction only when the user commits. The system identifies interactive elements from the rendered page, so build controls from semantic HTML such as <button> and <a href>, or give them an interactive ARIA role and make them focusable. A <div> wired up with a click listener alone may not be recognized as a target.

Unity and Unreal projects built with Interaction SDK receive gaze hover events and render their own hover feedback.

Spatial SDK applications suppress hover events by default, so the system draws the hover effect and it is the sole feedback. An application that renders its own hover feedback can turn suppression off. Selection and other actuating events arrive either way. See How to add gaze interactions with Spatial SDK.

The design guidance on this page applies in all four cases. Whether the system or your application draws the hover state, it should stay subtle and must not move the target.

For gaze and hand interactions, use static progressive disclosure on select. This reveals more information or options once users show a clear intent to interact.

Use progressive disclosure sparingly. Avoid using it on hover (for example, hovering over a person, app icon, or world to hide their name and show additional actions). While providing more information contextually can be helpful, it can also distract users, prevent fixations by creating a moving target, and make interaction difficult if the target is unclear.

Progressive disclosure best practices

DO Reveal additional options on an explicit commit action, such as a pinch. Users see the change only after they signal intent, and the reveal stays predictable.

DON'T Reveal extra actions when the user looks at an element. The reveal creates a moving target and invites the Midas Touch effect.

DON'T Swap or hide existing content on hover. The swap creates a moving target and breaks the user's fixation.

Button placement

Gaze targeting relies on eye movement within a field of view. The center of a surface is the most reliable place to target.

The apparent size of a target shrinks as it moves toward the perimeter of the field of view, so targets near the outer edges are harder to acquire until the user turns their head. Avoid placing UI in dense groups, because tight clusters make gaze targeting noisy.

Diagram of a panel showing buttons placed near the center of the field of view, where gaze targeting is most reliable, compared with buttons pushed out toward the perimeter

Target sizing

Larger targets are more reliable to select with gaze. Eye-tracking accuracy varies by hardware, user, and calibration. Size elements as large as possible without harming the design.

Size gaze targets to at least 3.0 degrees of visual angle. Angular size, not physical size, determines whether gaze can reliably acquire a target. A target’s angular size shrinks as the user moves away from it, so the same object can pass the rule at one distance and fail it at another.

How you express that rule depends on how you build your application:

2D Android apps: Size touch targets to at least 48dp. The system scales your application window so that 48dp subtends about 3 degrees of visual angle at typical panel distances. That relationship holds while the panel sits within the system’s supported distance range, and the exact angle depends on the device display. Treat 48dp as a design convention that you apply in your layouts, not as a floor the platform enforces. For the window-scaling mechanism, see Look and Pinch for 2D apps.
Web content in Browser: Size interactive elements to at least 56 x 56 CSS pixels. Browser runs in a window the user can resize, so CSS pixels do not map to a fixed angular size across window sizes. Treat 56 x 56 as a design convention that you apply in your layouts, not as a floor the platform enforces. Size controls generously rather than to the minimum, and test your layout at the smallest window size you support. See Browser specifications.
Engine apps (Unity, Unreal, and Spatial SDK): You control both the world size of a target and its distance from the user, so compute the world size that subtends 3 degrees at the intended viewing distance of your UI. That size is 2 x distance x tan(1.5 degrees), which is about 5.2 cm at 1 m.

A 48dp element translates to a 3 degree hit target

Target spacing

Provide enough spacing between interactive elements to minimize gaze error. Spacing between the visually dominant parts of adjacent elements matters more than spacing between button bounds. When interactive elements sit too close together, gaze targeting becomes noisy and unreliable.

Target spacing best practices

A panel with three round buttons arranged in one horizontal row

DO Group buttons in a single row or column. A one-dimensional group keeps every neighbor on one axis, so gaze error along the other axis lands on empty space instead of the wrong button.

A panel with a round button and a wide button on one row and three more buttons on a second row below

DON'T Stack button groups in two dimensions. Targets crowd each other horizontally and vertically at once, so gaze error in any direction lands on a neighbor.

Color theming

Make sure there is ample color contrast room for the hovered and selected states of buttons. Gaze interfaces support both a light and a dark theme, and users choose between them in system settings, so design for both. Dark backgrounds increase contrast for UI highlighting that brightens on hover and selection, which helps users keep track of what they selected.

Both light and dark modes should lighten on hover, because lighter elements attract more attention and create stronger fixations.

Comparison of button contrast on light and dark backgrounds, showing that dark backgrounds improve hover and selection visibility

Dark backgrounds increase contrast for hover and selection states

Color theming best practices

DO Give the background and the buttons enough contrast to separate them. Contrast leaves room for hover and selection states to stand out.

DON'T Use low-contrast buttons that blend into the background. Users lose track of which element is hovered or selected.

A surface split into a dark gray half and a light gray half, each with a mid-gray button

DO Use shades of gray for surfaces and buttons. Gray leaves headroom above and below the base color, so hover and selection states have somewhere to go.

A surface split into a pure black half with a pure white button and a pure white half with a pure black button

DON'T Use pure black or pure white. Neither leaves headroom for a hover state to brighten into, so a hovered element reads the same as the rest.

UI saliency

Saliency is how strongly a part of the interface draws the eye. Consider visual composition, and design UI to draw focus to the center-most point of the target.

Avoid outlines or other elements that draw attention to the periphery. This matters more as the target’s angular size grows, for elements such as cards.

Button examples side by side, comparing visual weight concentrated at the center of the control with visual weight pulled out to its edges

A UI layout shown before and after a blur is applied, where the remaining bright areas reveal where the visual weight sits

When evaluating saliency during design, approximate visual weight and saliency by blurring the layer.

Two layouts with identical container spacing but different internal composition, showing how the gap between the visually dominant parts changes

Consider tradeoffs of how composition of salient elements impact spacing.

Hover states

Keep hover visual feedback minimal to avoid the Midas Touch effect, reduce gaze errors, and support eye comfort.

Use subtle changes in opacity, scale, or Z-distance (without altering container size) for effective gaze hover feedback.

Hover state best practices

DO Scale the content inside the container, not the container itself. This prevents large movements that pull attention away from the container's center.

DON'T Scale the container and reflow the layout around it. Eyes, including peripheral vision, are sensitive to motion, and large movements such as resizing an entire thumbnail distract the user.

If content scaling is not feasible or conflicts with your application’s experience, scale containers in place. Ensure the UI does not reflow or shift neighboring containers.

Example of subtle color changes that keep the eye centered on the control while providing hover feedback.

DO Use subtle color changes to keep the eye centered on the control. Color feedback signals hover without moving the target.

DON'T Use outline strokes for hover feedback. An outline pulls the eye toward the outside of the control.

Interaction timing

Gaze moves rapidly and directly across a surface, so avoid registering every interaction immediately. Timings prevent affordances from becoming noisy. Color and motion animate asymmetrically: hover-off runs longer than hover-on on both channels, and the color channel and the motion channel run on different durations. Run hover-off longer to limit peripheral distraction, reset UI the user is no longer fixating on subtly, and keep the main motion within the user’s central vision. For background on animation curves, see ease in, ease out.

Hover transitions

Use these suggested timings for hover transitions:

Hover transition	Delay	Suggested timing
color-hover-on	None	300ms
color-hover-off	None	400ms
motion-hover-on	150ms	475ms
motion-hover-off	None	625ms

Press and release

Use these suggested timings for press and release interactions:

Interaction	Suggested timing
interact-press	80ms
interact-release	100ms
interact-deselect	300ms

Applying these timings across platforms

These timings apply on every path. In Unity, the Meta Horizon OS UI Set in Interaction SDK ships gaze-tuned animator controllers that implement them, so you get the asymmetric hover behavior without authoring each transition by hand. Those controllers are separate from the standard pointer and hand animators, which use a flat 0.1 second duration on every transition. For the component library, see Meta Horizon OS UI Set.

Explicit close affordances

Provide a clear affordance to close or dismiss a UI instead of relying on patterns such as click off to dismiss or exit a mode. Users can struggle to find a blank spot to look at and click.