ENGAGE XR

We added historical figures as AI-driven avatars and tested the interaction until it read on its own. People had to know, without being told, when the avatar was listening and when it was their turn to speak into the microphone in natural language.

We also built guardrails, so that each avatar only answered within its own history and character, and every conversation stayed historically accurate.

Over two years in-house, my role went beyond interaction and visual design. I regularly facilitated workshops with Product, Engineering and other stakeholders to define priorities and translate business needs into a working product roadmap, especially as the platform kept expanding across new devices, markets and use cases.

That meant being part of deciding what to build and why, not only how it should look and feel: weighing feature requests against engineering capacity, and helping Product, Design and Engineering align around the same direction before any of the interaction work below ever started.

ENGAGE XR runs on desktop, on mobile and inside the headset, and each one comes with its own way of pointing: a mouse, a finger, a hand, a laser. The easy answer is four interfaces. That is also how a product stops being learnable: what you know on one device buys you nothing on the next.

I defined a single spatial interaction system that held across all four, optimized for hand tracking and laser input. Four input paradigms, one model. It is the piece the rest of this page sits on: the keyboard, the desktop redesign and Drawpad are all the same system seen from a different device.

Redesigned the user flowchart for joining sessions, resulting in the implementation of QuickLink: a shortcut that significantly reduced entry friction.

Designed a custom keyboard to internationalize the platform. This involved feature prioritization work with the dev team, weighing scope against timeline, to build a fully native keyboard with language-specific interactions.

Arabic support was added, requiring the entire app to be adapted to RTL (right-to-left) reading direction, supported by in-depth research into Arabic app design conventions. Early concepts were prototyped in Spline 3D to communicate the vision to the team before development began.

Meta had no native Arabic keyboard at the time, so we built ours from scratch with no guidelines to follow (as far as we know, the first in XR to do it). That meant flipping the entire interface to right-to-left, and understanding how people actually read in that direction: which icons had to be mirrored, and which had to stay exactly as they were.

Since ENGAGE XR is not an action game, conventional mouse and keyboard controls did not fit the experience. The original free look with the mouse let people look around freely with no friction. It felt natural to build. It also made some users sick, and the problem showed up first as a support cost, not a survey result: in live sessions, someone from the team had to personally walk each new avatar through the controls, on site presentations, pressing buttons on their behalf, because the system did not teach itself. Some of that confusion came from switching devices too: what worked with a mouse did not map cleanly onto a VR controller. The company was losing a person, for several hours, every single day, repeating the same explanation.

I proposed replacing free look with click and drag to move the head. Objectively more friction, and that friction was the point. The team pushed back: users were already used to free look, and this would feel like a step backward. I facilitated a working session with Product and Engineering to walk through the support cost together instead of arguing the point in isolation, and we agreed on shipping the change with a contextual hint system on top of it, showing what each key or input did, dismissible once someone already knew the system. That is how the resistance actually got resolved, not by winning the argument about friction, but by making the friction legible so it stopped feeling arbitrary.

I conceptualized Drawpad in ShapesXR: a personal space where teachers and students could draw and take private notes during a session, and shared whiteboards embedded in the 3D environment where that same content could be displayed and worked on together. Every decision was built against protopersonas I created myself, K12 and university teachers on one side, more casual users coming in for entertainment rather than education on the other, each with different roles and permissions and different duplication modes, so a teacher could, for example, spin up a math exercise and hand a copy to every student at once.

The feature also integrated the new Logitech MX Ink pen, and introduced a mixed reality onboarding experience: users could anchor their Drawpad to their real desk, opening the passthrough cameras and using mixed reality so they could write and draw with physical surface resistance, closer to paper than to gesturing in mid air.

Every feature was wireframed in ShapesXR before it was built, and Drawpad was no exception. Working in three dimensions and at real scale lets you stand inside the layout and judge distance, reach and comfort before anyone writes a line of code. A flat mockup cannot answer those questions.

Beyond design, I oversaw developer implementation to ensure the built product matched the intended experience, and regularly tested APKs acting as UX QA, bridging the gap between design intent and technical output.

I also led a team of junior UI designers, guiding them to bring each concept to life with consistency and quality.