Design

Eyes

Updated: Sep 8, 2026

This page introduces gaze as an input modality. It is for designers who are planning a gaze interface and want the shape of the input before reading the detailed rules. Two sibling pages go deeper: Eyes technology covers the system parameters, and Eyes best practices covers the design guidance.

Usage

People look at what they intend to act on. Attention reaches a target before a hand does, so the eyes already carry a reliable signal of intent.

In immersive experiences, gaze turns that signal into a targeting method. The user looks at an element, then commits with a separate action such as a pinch. Targeting and committing are distinct steps, and that separation is what makes gaze workable as input.

Close-up photograph of a person's eye, with the iris and pupil in sharp focus

Eyes do not move smoothly. They travel in rapid jumps called saccades when focus switches between elements, with brief pauses called fixations in between. This constant motion makes raw gaze unreliable as a direct pointer. The system compensates for it. Eye tracking data is smoothed before targeting sees it, and on the 2D panel path the gaze point magnetizes to nearby interactable elements, so a user does not select empty space between targets.

Strengths and challenges

Advantages

Fast, low-effort targeting and selection. Looking at a target takes less time and effort than moving a hand, a ray, or a controller to it, especially across distance.
Available when the hands are busy or unavailable, which supports accessibility and gives users more flexibility.
Especially useful when hand tracking is the active input.
A natural interaction with a low learning curve, so users pick it up faster and more intuitively.
Pairing a gaze target with a separate commit action reduces accidental activation and increases certainty.

Challenges

Precise control is difficult. Accidental activation is common when gaze alone drives actions.
Accuracy varies by hardware, by user, and by calibration quality, and reliability falls off toward the perimeter of the field of view.
Eye tracking can be unavailable on a device, or it can drop out during a session. Targeting then falls back to the hand or controller ray, and to head gaze only when no hand or controller tracking is available.
A visible affordance for the current target is essential. Without visible state, a user cannot tell what a commit will act on.
The eyes often leave a target before the hand finishes the commit. The system holds the target through that, but confirmation feedback still has to land fast enough to be seen, or the user misses it and repeats the action.

What gaze suits

Gaze is a good fit for:

Selecting among discrete targets, especially on a panel or at a distance where reach is impractical.
Flows where the hands are busy, or where hand tracking is already the active input.
Any flow where a user’s attention already lands on the target before they act.

Gaze is a poor fit for:

Precise or continuous pointing, such as drawing or fine dragging.
Actions that must never fire without deliberate intent, unless a separate commit action gates them.
Critical flows that must work on devices or in sessions where eye tracking is unavailable. For head-driven input on its own terms, see Head.

These build paths support gaze: 2D Android applications, web content opened in Meta Quest Browser, Unity with Interaction SDK, Unreal with Interaction SDK, Spatial SDK, and WebXR with the Immersive Web SDK.

For target sizing and spacing, see Eyes best practices. For the numeric targeting parameters, see Gaze specs.

Terminology

These are the characteristics and frequently used terms to be familiar with:

Term	Definition
Saccade	A rapid eye movement made when focus switches between elements.
Fixation	A brief pause between saccades, when the eyes rest on one element.
Gaze and hands	Eye tracking for targeting combined with a hand pinch for actuation.
Head gaze	The final fallback, which uses head pose instead of eye direction. It applies only when no hand or controller tracking is available.
Midas Touch effect	An interface activating elements that the user merely looks at.

Design

This section covers how gaze works as an interaction method, the principles that make gaze targeting reliable, and the comfort factors to account for across a long session.

Interactions

Discover the input capabilities and interaction methods that use gaze as an input modality:

Capability	Description
Targeting	The user looks at an element, and the system resolves which interactable the gaze lands on.
Selection	A separate commit action, such as a pinch, acts on the targeted element. Targeting and committing stay distinct.
Hover feedback	Which side draws hover feedback depends on the build path. 2D Android applications and web content in Browser do not receive gaze hover events, so the system renders feedback on their behalf and no user flow may depend on hover state. Unity and Unreal with Interaction SDK receive the events and render their own feedback. Spatial SDK suppresses hover events by default, so the system draws them, and an application that renders its own can turn suppression off.
Progressive disclosure	Reveal additional options on an explicit commit, not when the user looks at an element. A reveal on look creates a moving target and invites the Midas Touch effect.
Dismissal	Provide a clear affordance to close or dismiss a surface rather than relying on clicking off it. Users can struggle to find a blank area to look at and commit.

For a comprehensive overview of all input modalities and their corresponding input mappings, see Input mappings.

Design principles

Explore the fundamental concepts that shape reliable and comfortable gaze interactions:

Principle	Description
Size targets by angle	Angular size, not physical size, determines whether gaze can reliably acquire a target. The same object passes at one viewing distance and fails at another.
Space targets apart	Spacing between the visually dominant parts of adjacent elements matters more than the gap between their bounds. Elements packed too tightly make targeting noisy and unreliable.
Favor the center of the field of view	The center of a surface is the most reliable place to target. Apparent size shrinks toward the perimeter, so targets near the outer edges are harder to acquire until the user turns their head. Avoid dense clusters there.
Keep hover feedback minimal	Subtle feedback avoids the Midas Touch effect, reduces gaze error, and supports eye comfort. Use small changes in opacity, scale, or depth, and never move or resize the target itself.
Draw focus to the center of a target	Design composition so visual weight sits at the center of a control. Outlines and edge treatments pull the eye toward the periphery, which works against reliable targeting.
Give hovered and selected states room	Ensure enough color contrast that a user can tell what is hovered and what is selected. Both light and dark themes should lighten on hover.
Time transitions asymmetrically	Hover-off runs longer than hover-on, which limits distraction in peripheral vision while keeping the response to a new target immediate.
Degrade gracefully	Eye tracking can be unavailable or drop out mid-session. Ensure other input modalities are also supported.

For the detailed rules and values behind these principles, see Eyes best practices.

Comfort

Reduce motion in peripheral vision. Peripheral vision is sensitive to movement, and large changes outside the user’s focus pull attention away from the target. Keep on-hover feedback subtle. Minimal feedback supports eye comfort across a long session, alongside reducing gaze error. When an element responds to a look, scale the content inside its container rather than the container itself. The layout then stays fixed, and it does not reflow around the element a user is looking at.