Placing a virtual object on a real surface feels like a small interaction: point the phone, tap, and the model appears. Behind that gesture is a sequence of decisions about geometry, coordinate spaces, tracking, and user intent. A convincing AR placement flow makes those decisions visible enough that the user understands both success and uncertainty.
This guide focuses on hit testing as one part of that flow. It does not treat a detected intersection as proof that a location is suitable or safe. Start with the spatial AR API hub for the broader learning path, then use the following design steps to build a more dependable placement experience.
Understand what the hit test contributes
The W3C WebXR Hit Test Module describes an interface for testing rays against real-world geometry and obtaining results relative to spaces. It is an additional capability around WebXR, not a promise that every immersive environment exposes the same environmental information.
At the application level, think of the result as a placement candidate. Your interface still needs to decide whether to show a preview, allow confirmation, or ask the user to try another location. A geometric intersection does not carry all the product meaning of “a good place for this object.”
For a tabletop game, the application might require a sufficiently usable play area. For a wall label, it might need an appropriate orientation. Those rules should be explicit and separate from the mechanism that obtains candidate geometry.
Define the interaction before the reticle
Write the intended sequence in user language. A useful starting sequence is scan, aim, preview, confirm, and adjust. Each state should have one clear next action. Do not display a confirmation prompt while the application is still looking for a usable candidate.
Make the preview visually different from a committed object. Use a labeled outline, a distinct surface treatment, or a visible placement instruction. Do not rely only on red and green. A visitor should understand whether the object is following their aim or already attached to the scene.
Keep the model's scale understandable during preview. If the application allows resizing, explain whether the preview is life-size or illustrative. A beautiful object at an ambiguous scale can mislead users even when the underlying hit test is technically correct.
Keep coordinate conversions in one place
A placement result and your scene object may not use the same parent space. Create a clear conversion boundary rather than applying ad hoc offsets throughout rendering code. Name the source space, destination space, and transform direction in your implementation notes.
Use an asymmetric test model with a marked front and top. Place it on different candidate surfaces and check orientation from several viewpoints. This catches cases where the position appears plausible but the object's forward direction or pivot is wrong.
Avoid correcting a bad import convention by adding unexplained rotation constants to placement code. Fix or document the asset conversion instead. Otherwise, the next model may arrive with a different convention and expose the hidden dependency.
Design a useful “not yet” state
An empty set of usable candidates is a normal state, not an exceptional failure. The interface should explain what the user can do without pretending it knows exactly why geometry is unavailable. A calm instruction to aim at a clear surface is better than a technical error code.
Do not leave a stale reticle visible indefinitely after the underlying candidate disappears. That can imply confidence the application no longer has. Define how long a preview remains valid and what visual treatment indicates that the user should reacquire a candidate.
Keep the experience useful when placement never becomes available. A conventional model view, dimensions, or descriptive content can preserve the purpose of a product demonstration. A fallback should support the original task rather than simply announce that AR did not work.
Confirm an intentional placement
When the user confirms, make the transition obvious. The preview should stop following the aiming point, and the interface should acknowledge what happened. Provide a clear adjustment or undo path so the user does not need to restart the entire session after a mistaken tap.
Treat a confirmation as an application event with its own validation. Recheck that a usable candidate still exists and that the task is in the correct state. This protects against rapid taps, delayed input handling, or a candidate disappearing between preview and selection.
Keep repeated taps from creating unintended duplicate objects. If multiple placements are allowed, make that a deliberate mode. An accidental cluster of identical models is often an interaction-state problem rather than a rendering problem.
Separate placement from ongoing attachment
Finding a placement candidate and maintaining an object's relationship to the environment are different responsibilities. Your architecture should distinguish the initial placement transform from whatever mechanism keeps the committed object associated with the tracked scene.
The spatial anchors guide develops that second responsibility. For the placement flow, define the handoff: what information is retained, when the preview is removed, and what the user sees if the attachment step cannot be completed.
Avoid promising permanent or cross-device placement merely because the object remains still during a short local test. Persistence, sharing, and relocalization introduce additional requirements. Describe only the behavior that your implementation has actually verified.
Work through a tabletop example
Imagine a hypothetical AR board-game preview. The user opens a product page, reads a short explanation, and chooses an AR view. The application begins with a transparent board outline and the instruction to aim at a tabletop.
When a candidate is available, the outline becomes more defined and a placement action appears. On confirmation, the board remains at the selected location while the user can inspect it. A separate “place again” action returns to preview rather than adding another board by accident.
This example is intentionally modest. It does not require a complicated inventory, multiplayer synchronization, or advanced game logic to test whether placement makes sense. Establish that interaction first, then introduce the additional features one by one.
Decide what counts as a successful test
A successful placement test should include more than a screenshot. Ask whether a new user knew when to confirm, understood the model's scale, could undo a mistake, and could recover when the candidate disappeared. These observations tell you whether the geometry has been translated into an understandable experience.
Test the messy transitions
Build a test script that moves through candidate acquisition, candidate loss, confirmation, repositioning, and session exit. Try a quick tap during a transition. Try returning to the page after an interruption. Keep the script short enough to repeat after every significant change.
Use a small set of controlled environments and record their conditions. Then add less predictable real-world trials. Separate observations about geometric stability from observations about instructions and controls; both matter, but they require different fixes.
When a test fails, record the state transition and the expected outcome. “Placement feels broken” is difficult to act on. “The confirm action remains enabled after the preview loses its candidate” gives a developer a reproducible behavior to investigate.
Questions that come up in implementation
Is hit testing the same as object recognition?
No. In this workflow, hit testing supplies geometric placement candidates. Recognizing what a surface or object represents is a separate problem. Do not label a candidate “table” merely because its orientation looks convenient for your application.
Should every tap place content immediately?
Not necessarily. An explicit preview and confirmation can be easier to understand, especially when scale or orientation matters. Choose the interaction based on the task and test it with unfamiliar users rather than assuming fewer taps always means a better experience.
Conclusion: build the whole placement conversation
Good AR hit testing is not just obtaining a transform. It is the complete conversation between candidate geometry and user intent: look, preview, confirm, adjust, and recover. Keep uncertain states visible, coordinate conversions explicit, and duplicate actions controlled.
Once that conversation works, add the visual details that make the object feel present. Continue with the depth and occlusion guide to consider how real objects can affect the appearance of virtual content without confusing geometric evidence with certainty.
