Owning Our Core: The Sideloading Overhaul at SideQuest

Context

Sideloading, the process of installing apps onto a VR headset outside of the official store, is what SideQuest was built on. It's the platform's foundational feature and the reason most users come to the site in the first place. Despite that, the sideloading flow hadn't kept pace with the product around it: it was clunky, error-prone, and left first-time users largely on their own. When a competitor moved into this space, it created urgency and an unexpected opportunity to formalize what should have been ours to own anyway. This began a ground-up rethink of the entire experience.

Problem

The existing flow had a narrow golden path and almost everything else was an edge case. First-time users had no idea what sideloading was, whether it was safe, or what they needed to do before clicking anything. The browser-based version was particularly brittle, and displayed a "success" confirmation regardless of whether the prerequisites had been met. This meant users who hadn't yet configured their headset or phone saw a success screen that meant nothing. There were no instructions, no guidance, and no recovery path when things went wrong.

Beyond first-time users, the flow didn't account for the full range of how people actually used SideQuest: some only had a phone and a headset with no desktop at all, some were installing game ports that required copying local files from a PC, and the experience varied meaningfully across the browser, desktop app, and VR app versions. Each had different technical constraints and acceptance criteria.

What I Did

The starting point was making sense of what we'd inherited. The contractor had built a working prototype, but it was dense and hard to follow. I worked with Engineering to unpack how it actually functioned; mapping the logic, the states, the failure modes. I then helped design understand what the system could do and where it had room to expand. That translation work was unglamorous but necessary: design couldn't refine what they couldn't fully see, and engineering couldn't build toward a vision that hadn't been articulated yet.

From there I built an extensive flowchart documenting the full UX, including every path, every error state, every conditional branch. The golden path turned out to be genuinely slim. Almost everything else was an edge case: wrong headset connected, prerequisites not met, mid-flow errors with no clear recovery, optional tutorial steps with their own sub-steps, and the game port installation path which was essentially a secondary flow nested inside the primary one. This was partially for my own understanding, but also to ensure QA had enough knowledge to ensure nothing slipped through.

That complexity made telemetry decisions harder than usual. Working with our data scientist, we talked through what we actually needed to know versus what we could track. The temptation with a flow this branchy is to put an event on everything, but that just gives us a dashboard full of noise from tons of button states across a dozen edge cases. Not useful. We focused on the events that would tell us where users dropped off, which error states were most common, and whether the optional tutorial steps were being used. That shaped the instrumentation rather than the other way around.

On the UX side, the core design challenge was finding the right balance between leaving users to figure it out themselves and overwhelming them with documentation. The solution was a context-aware onboarding wizard that adapts based on which headset is connected, what type of app is being installed, and where the user is in the flow. The designer ran with it and built upon the contractor's original prototype. My role was refining it as engineering built and we discovered new constraints: what was technically possible, where the conditional logic had limits, how the experience needed to differ across browser, desktop, and VR app environments.

The game port path deserved special attention. Installing a port requires not just the APK but local game files copied from the user's PC. This is a multi-step process that's genuinely confusing if you've never done it, and most game ports have unique setup steps. Our wizard handles this as a guided secondary flow, including file matching logic that ensures only the correct files are transferred. The last detail matters, as copying the wrong files wastes storage or could break the install. Even if it's outside of our control, it's exactly the kind of thing a user would blame on SideQuest.

I also made sure QA test cases mapped directly to the PRD throughout. Given the complexity, any gap between what was specified and what was being tested was a rework waiting to happen. We ended up with very few reworks at delivery, which given the surface area of this project felt like a meaningful outcome.

Outcome

The final experience is polished and looks fantastic: peep that oldschool CD spinning loader state!

First-time users get contextual guidance without being lectured at; power users can skip explanatory steps and move quickly. The flow works on Android devices using WebUSB and ADB (the same architecture as desktop) which meaningfully expanded the accessible user base. iOS remains unsupported, a hardware limitation unchanged by this work.

The new flow is instrumented in a way the old one never was — the previous version showed a "successfully sent to device" confirmation that fired regardless of whether the prerequisites had been met, which meant there was no meaningful success signal to measure against. What we can say now: of users who reach the device connection step (the first real friction point in the flow) 87% complete the sideload successfully. Overall funnel completion from first click sits around 10%, which sounds low but is consistent with the nature of the flow: many users click "sideload" to explore before they're ready, and the wizard is designed to guide them back when they are. On a typical day we're seeing roughly 200 successful sideloads per 2,000 attempts, with the vast majority of drop-off happening before device connection rather than during the guided steps. The instrumentation we built for this project means we can now actually see where friction lives, and iterate on it.

Also, something truly interesting surfaced during implementation: because the underlying architecture uses Android ADB, it can technically install more than just VR apps. That's an interesting longer-term question and the groundwork is already laid if the business decides to pursue it.

What I'd Do Differently

Ideally this project would have emerged from a deliberate product process rather than a reactive one, as a competitive dynamic forced the timing. That said, it might not have been prioritized otherwise, so the forcing function may have been net positive.

The honest answer is this one went well. The translation work between the external prototype and our design system was slower than I'd like. Maybe I'd build that shared understanding faster next time by getting design and engineering in the same room with the prototype earlier rather than working through it sequentially.

Also: this project was finished right before AI building/vibe coding took off. If I could go back and do it again, I would strongly leverage simple quick proto builds to test out various ideas and see what had the least user friction without slowing down the power users.