Reality Labs Research

For two years at Meta Reality Labs Research, I built interactive proofs-of-concept to unblock researchers, empower designers and drive organizational decision-making. Much of this work remains confidential; I’ve described what I can below.

With hardware ranging from microcontroller benchtop rigs to experimental prototype headsets, my job was to build enough scaffolding to make the system designable, then use it to answer interaction questions. I built reusable Unity packages so other designers could bootstrap from my progress, and demoed frequently to testers and stakeholders to evaluate product fit.

Project 1 — Taking an experimental display from test patterns to wearable prototype

I joined a team of research scientists, EE/ME engineers and designers early, when the display ran an Arduino driver written for research simplicity rather than performance. It could show test patterns and static images, but nothing else.

Driver rewrite to unblock animation and interactivity

I rewrote the driver in Python, changing how frame memory was allocated to achieve 15× faster updates on the same hardware, which unblocked animation and real-time interaction. I wrote a Unity SDK bridge to bring the display into my team’s prototyping platform, unlocking 6DoF world-locking, hand-tracking and camera access. Within a few weeks the display went from a benchtop rig to a wearable prototype the team could use for design exploration.

Finding the interaction language

The point of the technical work was to unlock features I knew we’d need to answer key design questions, like:

• How should navigation be represented? How should an object or location be selected?
• How could the display communicate notifications or alerts?
• How could the display indicate objects in the physical world?
• Which patterns were intuitively intelligible, and which introduced visual discomfort?

We worked backwards from product use cases to the capabilities each would need, then tested various approaches and gathered feedback to downselect the most intuitive. A particular tradeoff was comfort vs legibility - we exploited a fact about human peripheral vision to achieve a highly visible signal, but the same effect was nauseating for some users. I carefully listened to affected users and produced a simple demo that allowed me to tweak parameters and switch through several approaches. After testing with roughly a dozen users, we found that reducing the speed of the effect and anti-aliasing the edges was sufficient to reduce nausea while preserving legibility.

Prototyping platform & product decision

The Unity SDK I built was used by other VR developers and designers to build further symposium demos after I moved on. I also produced a product-vision video connecting the research to a coherent future experience.

The prototype was demoed to senior leadership at several internal symposiums and demo days; leadership decided not to productize the display. That decision was our deliverable - the team took an unproven display from test patterns to a wearable prototype with a tested interaction language, which made an informed “no” possible.

Project 2 — Precise navigation with spatial audio alone

With an audio research scientist, I tested whether a person could navigate a real space safely and precisely using nothing but a spatially positioned audio beacon. The technique is described in U.S. Patent Application US-20260089459-A1, on which I’m a named co-inventor.

I started by building a Unity sandbox that exposed the scientist’s parameters (like ‘decision point falloff radius’) as interactive gizmos. This let us sit together and tune the effect in real time.

Once the guiding principles were locked in, I scanned a large section of the office and used spatial anchors to pin the virtual map to it, which let us borrow Unity’s navmesh pathing and audio occlusion to simulate future device capabilities.

What testing changed

Technically, the cue pointed the right direction. But without visual confirmation, people became cautious — behaving almost as though they were moving through an unfamiliar corridor with the lights off. Thus confidence, as much as accuracy, became the design goal. I made turns sharper and more perceptible - in practice, less lead time meant the signal was clearer and easier to follow. I also removed the separate wrong-way cue - it was disruptive precisely when someone was already disoriented. Instead, the beacon continuously repositioned itself in the direction the person should travel. The system stopped announcing the error and just kept pointing the way out.

Demo and handoff

We invited a blind participant to try the prototype on two indoor routes — one with simple directional changes, one a tight winding course around furniture. Using only the beacon, they deftly navigated both. It was an exploratory session rather than a formal accessibility study, but it was strong evidence that the interaction was legible and precise enough to keep developing.

I handed off my project code to another prototyper, who continued to build on it with the audio scientist. Whether the feature will eventually appear in future devices is, as far as I know, up in the air.

Summary

These were research initiatives rather than public launches, so I evaluate the work by what it made possible:

• Two hard-to-access research systems became experiences teams could evaluate, and both were picked up and extended by other people after I left.
• Interaction decisions came from observed behavior, not technical feasibility alone.
• The work supported multiple symposium and conference demonstrations and contributed to a patent filing (US-20260089459-A1).