Translate the creative brief into something the medium can reliably support before committing the team to a build.
CLIENT PROJECT / IMMERSIVE / WEBAR
AURORA PORTALS
Four browser-based spatial experiences designed from consultation through deployment. I helped define what AR could realistically support, designed the experience around those constraints, and built the cross-platform production pipeline required to make it work across web, Android and iPhone.
EXPERIENCE ARCHIVE01 / THE BRIEF
Turning an idea into something AR could actually do.
Ideas United reached out after seeing spatial experiments I had already been developing around launching architectural environments into augmented reality. I came into the Emory Healthcare project as more than an implementation resource. My first responsibility was to meet with the team, understand the experience they wanted to create, and help define what the medium could realistically support.
Those early conversations established the boundaries of the build. I explained where mobile AR was strong, where the technology would introduce friction, and which ideas needed to be redesigned rather than forced through the medium. From there I developed and iterated an experience direction that preserved the feeling of entering another environment while remaining practical enough to launch from a browser on a visitor's own device. My job was not to force the original idea through AR. It was to understand what the technology could support, preserve the intent of the experience, and design a system capable of delivering it.
02 / EXPERIENCE DIRECTION
Four environments built around one delivery system.
Aurora Portals became a set of four immersive environments rather than four unrelated technical builds. I wanted the interaction model to stay familiar while the content and visual identity of each environment could change. That gave the production team a repeatable system and gave the audience a consistent way to understand how to enter and explore each experience.
The media below is intentionally placeholder content for this template pass. Each state will ultimately hold the finished imagery, launch capture or environment-specific material from the four Emory experiences.
01 / 04
ENVIRONMENT 01
PORTAL 01
Placeholder for the first environment. This panel will describe what the experience needed to communicate, how its content differed from the other portals, and any environment-specific production decisions.
03 / DELIVERY
From a link to an immersive environment.
Accessibility shaped the technical approach. The experience needed to move from a larger activation into something a visitor could open on a personal phone without downloading a dedicated application. A QR code or direct link could become the handoff: scan, open the browser, and enter the spatial experience.
Making that moment feel simple required the complexity to live behind it. I maintained a standalone web experience while testing and adapting the activation across Android and iPhone. The browser was the common entry point, but each device ecosystem introduced different constraints around spatial assets, animation and performance. Deployment therefore became part of the experience design rather than a final step after the creative work was finished.
MOBILE / EXPERIENCE
▶
ENTER
04 / SPATIAL ASSET PIPELINE
Building the orb differently.
One of the earliest production problems came from the environment itself. A single high-resolution panoramic image did not automatically become a high-resolution spatial experience. Once the image was wrapped, compressed and prepared for mobile WebAR, important areas could distort or lose clarity. Simply increasing the resolution of one source image did not solve the structural problem.
I developed a reusable Blender template that treated the environment as six corresponding faces before resolving those surfaces into the sphere seen by the user. Each face could be prepared and optimized deliberately, with known correspondence between top, bottom and the four surrounding sides. Because the project contained four environments and each one went through multiple iterations, this became a production pipeline rather than a one-time fix. Every launch could use the same spatial logic while still allowing me to tune the imagery for that specific orb.
01 / 04
PIPELINE 01
SOURCE / ENVIRONMENT
The starting visual material had to survive a transformation from flat imagery into an immersive mobile environment. This is where I evaluated what detail needed to be preserved before the asset entered the 3D pipeline.
05 / CROSS-PLATFORM ARCHITECTURE
One experience, different runtimes.
Cross-platform delivery exposed a second layer of the problem: identical spatial assets and animation behavior could not simply be assumed to work identically everywhere. The finished experience needed to function as a standalone web build while also operating reliably across Android and iPhone. I treated those platforms as part of the testing matrix rather than reducing the experience to the capabilities of the easiest device.
iOS required an additional production path. I bought a Mac specifically because solving problems inside Apple's spatial ecosystem required access to tools that were not available in my existing workflow. Reality Composer became part of the animation pipeline for preparing and controlling the behavior required on iPhone. When the intended experience crossed the limits of my current toolset, I expanded the toolset rather than shrinking the idea.
Reusable spatial construction and per-face image optimization across four environments and repeated iterations.
A standalone web path that also acts as the low-friction entry point from QR or direct link into the mobile experience.
Asset, interaction and performance testing against Android behavior rather than assuming desktop output would translate unchanged.
An Apple-specific animation path used to prepare and control spatial behavior required by the iPhone version.
Production hosting and media delivery supporting a public-facing experience that could be tested, deployed and preserved.
06 / ITERATION + TESTING
The build changed as it met real devices.
Aurora Portals was not a straight line from approved concept to final file. The work moved repeatedly between experience design, Blender, browser tests, mobile devices and platform-specific fixes. A decision that looked correct in a 3D workspace could reveal a new limitation once it was compressed, launched through the browser or tested on an actual phone.
I used those failures as information. The six-face orb template came from image-quality problems. The iOS branch came from animation behavior that needed Apple-specific tooling. Cross-device testing changed how assets were prepared and delivered. The final system is the record of those iterations, not simply the first concept rendered more cleanly.
PROCESS 01
CONSULTATION
DEFINING WHAT AR COULD SUPPORTI began by helping the team separate the desired experience from assumptions about the medium. The first technical decision was knowing which ideas could survive real-world mobile AR and which needed to be redesigned.
07 / PRODUCTION NOTES
BUILD / PROCESS
▶
ENTER
Solving for the experience, not the tool.
Aurora Portals reinforced something that has become central to how I work: the medium does not get to dictate the idea before I have exhausted the ways of solving the problem. The finished experience crossed consultation, 3D production, web development, mobile optimization and platform-specific spatial tools because no single part of that stack could solve the entire problem.
What mattered was making the transition from the larger activation to a visitor's personal device feel simple. Most of the complexity stayed behind that moment. My contribution was building the systems, templates and alternate production paths required to make that simplicity possible, then communicating those constraints clearly enough that the larger team could design and produce around what the technology could actually deliver.
PROJECT ARCHIVE
Launch a preserved Aurora Portals experience.
QR
DESKTOP LAUNCH
ENTER EXPERIENCE