O'Reilly Media — Live Events (Native iOS & Android)

O'Reilly's conference business went fully virtual during Covid, becoming Live Events - a growing part of the platform experience that drove meaningful subscriber engagement. With attendance climbing on web, the initiative expanded to bring Live Events to the native iOS and Android apps, with the goal of increasing accessibility and driving registration among mobile-first subscribers.

I was the product designer responsible for the full native experience, from scoping the problem through design, build support, and QA. The challenge wasn't simply porting an existing feature. O'Reilly's live event infrastructure relied on On24, a third-party platform built for desktop, which had no meaningful mobile support. That constraint shaped every decision I made: what to build natively, what to work around, and how to communicate limitations honestly so users could make informed choices about how they attended.

The design work centered on three core problems I identified: creating a discovery and registration experience that felt intentional and event-worthy on a small screen; surfacing multi-date, multi-session events without overwhelming users; and designing a system of states across the full event lifecycle that covered dozens of use cases clearly and consistently. Early on I determined that showing users exactly what an event included was non-negotiable, particularly for sessions requiring tools like coding sandboxes that weren't viable on mobile.

Designing Around a Third-Party Constraint

Live Events ran on On24, a platform built for desktop-first experiences. Certain session types, particularly those involving interactive elements or coding challenges, weren't fully viable on mobile. I made the decision not to obscure that gap. Hiding it would have been the easier path, but it would have eroded trust the moment a user hit a wall mid-session.

I designed an "includes" section for each event detail view and created a custom icon set to communicate session type at a glance: interactive, challenge-based, video-only. I wrote the copy directly: some activities may not be fully accessible on mobile, and a larger device is encouraged for certain sessions. That transparency was a deliberate design decision to reduce early-event drop-off and protect the credibility of the experience.

The Registration Decision

My early exploration took cues from the physical conference experience Live Events had replaced. I designed a ticketing flow with digital confirmation, something closer to a concert experience, intended to build anticipation and signal that attending was worth committing to. O'Reilly's in-person conferences carried real prestige, and I wanted to recreate some of that energy.

However, I ruled it out. The flow was too heavy, the steps unnecessary, and a digital ticket implied a physical destination. A user who didn't read carefully might genuinely wonder where to show up. The ceremony I'd designed was undermining the clarity I needed to protect.

I simplified registration to a single action: a "sign up" button pre-event, shifting to "join" as the event approached. The web platform had landed somewhere similar, but my decision wasn't deference to precedent. It was the conclusion of my own exploration. I looked to the confirmation email and 24-hour reminder cadence to carry the emotional weight of attending something, without introducing friction at the point of registration.

Designing for State Complexity

The detail screen was the most demanding design challenge in the project. It was a single view that had to communicate meaningfully across dozens of distinct states, depending on where a user was in their relationship to an event. I mapped and designed every state myself. Even through design QA I surfaced edge cases I hadn't yet accounted for, which speaks to the complexity of the system I was holding together.

I designed for users who were unregistered and browsing, on a waitlist, registered for one date, registered for multiple dates, or watching a live countdown in the minutes before a session began. Each state carried its own information hierarchy and its own primary action: "sign up," "join waitlist," "add to calendar," "cancel registration," "join now." Getting those actions wrong at the wrong moment would strand the user or create friction at the most critical point in the experience.

The countdown was something I built specifically for native, with no equivalent on the web platform. I decided the timer would begin when users received their 24-hour reminder email. I set the threshold for the "join now" button to appear at 15 minutes out, early enough to give users time to settle in without opening the session so far in advance it lost urgency. That timing decision was later adopted by the web platform.

When an event concluded, I designed the detail screen to split into a tabbed view. "Next up" surfaced the next available date for recurring events. "Recordings" managed its own state arc, from "recording coming soon" to a "view recording" button once content was live. I chose a tabbed view for Android and a selection control for iOS, following each platform's native patterns rather than forcing a single solution across both. On the Live Events landing screen, I added a toggle between "Upcoming events" and "Your recordings" to give returning users a direct path back to content they'd already attended.

The standard I held across every state was simple: a user should never land on this screen and wonder what to do next.

Outcome & Reflection

After launch, registrations increased 12% and attendance increased 8%, both tracked separately from the web platform. The native app join rate was lower than I expected, but I identified why post-launch. Users were registering on the app and joining on the web platform, where attendance was tracked independently. Native app attendance looked low, but the app was driving top-of-funnel registration behavior that the tracking infrastructure wasn't built to follow across surfaces. The app was doing its job.

What made this project demanding was the sustained judgment it required. I held a complex state system together across dozens of scenarios, designed around a third-party constraint I couldn't change, and made a call to simplify registration after exploring a more ambitious direction. Every significant decision I made prioritized user trust over design ambition.

The most invisible design work is often the most important. A user moving from discovery to registration to attendance without friction rarely notices how many decisions went into making that feel effortless.