Designing an End-to-End Native App Audio Experience

A fully redesigned audio experience that doubled app usage and increased audiobook consumption by 150%.

Quick Overview 

Role & Context 

Solo designer partnering with Product Manager, Lead Engineer, and 8-person engineering team split across iOS and Android.

Timeline

12 weeks from discovery through launch 

The Challenge 

Design a native audio player that transformed O'Reilly's basic playback workaround into a real listening experience, addressing early-session abandonment and enabling the multitasking behavior users expected.

Constraints

• 12-week timeline 

• Backend-heavy foundations and cross-device continuity requirements 

• Two platforms to ship in parallel: iOS and Android 

• Needed to align with existing O'Reilly design system and patterns

3 Strategic Decisions 

1. Grounded design in real listening behavior
   Conducted landscape analysis of 15+ audio apps (Spotify, Audible, Pluralsight, Libby) and tested end-to-end to understand core listening fundamentals vs. our technical playback capability. This revealed the gap: we played audio, but failed listening fundamentals. 

2. Prioritized features that eliminated abandonment triggers
   Partnered with engineering to validate feasibility and turn research-backed feature list into MVP. I prioritized five features beyond core playback based on engineering feasibility and direct evidence from user feedback and behavioral data: background playback, lock-screen controls, chapter navigation, speed control, and offline downloads. 

3. Designed for cross-platform consistency with platform-specific intelligence
   To ship cohesively across iOS and Android while respecting native patterns, I designed a shared icon set between SF Symbols and Material, maintained consistent interaction logic, and used each platform's native conventions for system-level controls (Control Center vs. notification shade).

MVP Scope (what shipped) 

• Full-screen audio player with playback fundamentals (play, pause, scrub, chapter navigation) 

• Background playback and lock-screen controls (native to each platform)

• Persistent mini-player for multitasking

• Speed control and chapter skip buttons 

• Offline download support

Impact

• 150% increase in audiobook downloads and consumption within first two quarters

• Doubled overall app usage across iOS and Android

• Extended to CarPlay post-launch for omnichannel listening across mobile, tablet, and automotive contexts

• Reduced early-session abandonment (leading indicator tied to original problem)

Context

O'Reilly Media, Inc. is an EdTech SaaS company that delivers technical and professional development content through its online platform and mobile app. Content was delivered through ebooks, videos, case studies, live events, and most recently, audiobooks.

O'Reilly launched audiobooks for native using a pragmatic workaround: the existing video player. At the time, it seemed like a reasonable shortcut. Audio played, and the content could ship quickly.

But once the release hit real users, our native team’s Slack channel that streams App Store reviews was immediately flooded with complaints. That was the first clear signal that the experience was not meeting basic listening expectations.

Problem

Audiobooks were shipped through a video player experience that broke core listening behaviors. Users could technically play audio, but they could not reliably listen the way they expected to on mobile.

Why it mattered

This was not just a UI issue. The funnel was breaking, adoption of a strategically important content format was at risk, and the workaround created mounting tech debt that made basic audio features increasingly expensive to ship over time.

My role

I took ownership from there. I was the lead product designer on the native app team and took on this 12-week initiative and drove the key product and UX decisions from discovery through launch. I partnered closely with the Product Manager, Lead Engineer, and an 8-person engineering team split across iOS and Android to align scope, constraints, and timelines.

I bridged business objectives with real user listening needs by owning research synthesis, 0 to 1 player design execution, participant recruiting and usability testing, and handoff documentation that enabled a smooth build across both platforms.

Constraints and success criteria

Constraints

• 12-week timeline

• Backend-heavy foundations and cross-device continuity requirements

• Two platforms to ship in parallel, iOS and Android

• Needed to align with the existing O’Reilly design system and patterns

Success criteria

• Reduce early-session drop-offs after tapping Play

• Improve listen-through behavior and repeat usage

• Increase adoption of audiobooks

• Deliver a cohesive experience across platforms and devices

Exploring the problem

It was clear a new audiobook feature would need to be designed and developed so I would need to explore the problem space.

I owned the initial diagnosis by diving into App Store and Google Play reviews and synthesizing them into clear, actionable themes. I paired that with behavioral analysis in Amplitude and FullStory, which showed the audiobook funnel breaking down. Users hit play, entered the player, and abandoned within seconds, with repeated play attempts and low listen-through.

At the start, several things were ambiguous. My team did not have a shared definition of what “a real audio player” meant in terms of listening fundamentals, we did not know what was immediately possible on the backend, and I didn’t know how to classify a “good player.” 

To define what “real player” and “good” needed to look like, and avoid rebuilding the wrong solution, I ran a landscape analysis across leading audio players in education and entertainment. I hands-on tested popular apps end to end to compare core listening behaviors like play and resume, skip controls, speed, and background playback. That work clarified the gap: our workaround technically played audio, but it failed the fundamentals of a true listening experience.

Feature choices and tradeoffs

Next, I partnered with engineering to validate feasibility and turn my research-backed feature list (about 15 items) into an MVP we could realistically ship. I led an impact vs. effort exercise with both engineering teams to weigh user value against backend complexity, then used that framework to define scope and make tradeoffs explicit.

To stay consistent with established patterns in the O’Reilly app, I prioritized key interactions users already relied on, like Add to Playlist and Table of Contents, so the new player felt native to the ecosystem. I also pushed for consistency across iOS, Android, and devices because I wanted the two platforms to feel related. I did not want playback or their current state to break when users moved between phone and iPad, so I worked with engineering to ensure cross-device continuity was part of feasibility discussions.

Strategic Feature Prioritization

After a few working sessions, I made the call on the MVP scope. I prioritized five features beyond core playback based on engineering feasibility, and direct evidence from user feedback and behavioral data:

1. Background and lock-screen controls (Highest Impact)

• User evidence: "Audio stops when I lock my phone" appeared in 64% of negative App Store reviews

• Behavioral data: FullStory showed users tapping play, locking screen, then immediately reopening to find playback stopped

• Impact: Users expect to lock their phone and keep listening (like every other audio app), but instead playback stops, creating immediate frustration visible in session recordings. Based on industry benchmarks, fixing this could improve first-month retention by 40-55% (users currently abandon when they realize the app doesn't work as expected), cut support tickets 50% (this single issue drives most complaints), and make the app usable for real-world listening. Without this, we're asking users to drain their battery and keep their screen active for hours, which explains why it's the #1 complaint and biggest retention barrier. 

2. Chapter navigation/scrubbing

• User evidence: FullStory sessions showed users attempting to scrub forward/back

• Behavioral data: 70% of audiobook sessions involved mid-book resumption (Amplitude)

• Impact: Adding a scrubber would let people visually see their progress, navigate to any point with a single gesture instead of multiple button taps, and recover from interruptions. It also addressed a fundamental audiobook behavior: people rarely listen in one sitting, so they need easy tools to orient themselves and navigate multi-hour content.

3. Variable speed

• User evidence: Benchmark analysis showed speed control was table-stakes across all leading audio platforms

• Behavioral data: (Post-launch: 73% of users adjusted speed at least once)

• Impact: Unlocked massive engagement gains because users could consume 31-48% more content. Research indicated this feature directly converts to measurable increases in listening time and book completions.

4. Offline downloads

• User evidence: App Store reviews mentioned "doesn't work on subway" and “this feature is useless during business traveling” and connectivity issues. Many called the app “unusable” without this feature.

• Behavioral data: Amplitude showed 60% of listening sessions on mobile networks

• Impact: 60% of sessions on mobile networks experience streaming failures (18-23% buffering rate), causing 27% abandonment. This feature would eliminate streaming-related abandonments, improve 30-day retention by 38-52%, and unlock the commuter/traveler market (31% of listening time) where app is currently unusable.

5. Persistent mini-player

• User evidence: Behavioral observation showed users switching between player and library/search

• Impact: A persistent mini-player would let users multitask within the app (browsing while listening), provide always-visible playback context (current book, progress, quick controls), and eliminate the friction of constantly navigating back and forth between player and library. This mirrors standard audio app patterns and enables the common behavior we're seeing: planning what to listen to next while finishing the current book.

Deferred (High-Value but Timeline Risk):

• Sleep timer - High user request but not blocking core listening (could layer post-MVP)

• Advanced bookmarking - Required backend architecture changes (4+ week engineering effort)

• Voice control - Important for accessibility but could enhance in v2

Designs and critique

Flows

I created end-to-end user flows for the MVP audio player to define how listening works across the app and outside the player screen. I mapped key entry points (audiobook detail, search, library and downloads, and resume listening) and designed rules for the mini-player state: when the mini-player appears, when it persists while users browse other content, and when it should hide (for example, switching to video or no active audio session).

I also defined interaction edge cases like background and lock-screen behavior, interruption recovery, and back navigation so listening stayed continuous and predictable.

Layout Exploration - Interface

I explored three approaches to balance discoverability with mobile usability, focusing on control hierarchy and thumb reach optimization.

Version A

Grouped core controls at ⅓ screen mark with secondary controls stacked below. Downloads farthest from thumb, then speed, then table of contents. Utility controls (AirPlay/Cast, share, add to playlist) at top.

• Pro: Table of contents had great thumb placement; speed button felt prime for quick access

• Con: Bottom-heavy UI; chapter skips segregated from related primary controls; book title and author easy to miss

Feedback & Improvements

I demoed low fidelity to my design teammates for feedback. The consistent feedback was that the interface still appeared cluttered and made tap targets difficult—especially when users were likely on the move. The team agreed there needed to be clear hierarchy for the controls.

I refined the final low fidelity by balancing the pros and cons from critique, paired with conventional patterns from familiar audio apps (Spotify, Audible) and edtech players (Pluralsight, Libby) to keep primary listening actions predictable.

The final design gathered the best of each version: utility controls at top, chapter skips among core controls, removal of redundant book title and author (already visible on cover), and strategic placement of speed control and table of contents. During landscape analysis, I recognized that AirPlay and Cast typically appear in the bottom-left corner, so I followed that pattern. I also decided to only display the chapter title since every cover in our library included the book title and author.

High fidelity

Because we were shipping on two platforms, I designed for consistency without fighting native conventions. I kept the interaction model aligned across iOS and Android while respecting OS-specific patterns where they mattered. To bridge the two design languages, I designed a shared icon set that sat between SF Symbols and Material iconography and validated recognizability through testing. For system-familiar actions like share, cast, and minimizing the player, I used each platform’s conventional icons and behaviors already established elsewhere in the app.

Mini-Player Control Exploration

I explored which controls belonged in the constrained mini-player space. Play/pause and close were non-negotiable. The third control decision considered:

Skip back 15s (final choice): Supports multitaskers who miss important information and need quick replay

Chapter skip: Enables navigation but less relevant for users mid-browse

Speed control: High-value but accessible from full player when needed

Research showing 91-94% browse while listening validated that the mini-player serves active multitaskers who need to quickly replay missed content, making 15s back the optimal third control.

Design critique

I led a structured design critique with the product design team to pressure-test the MVP player and catch issues early, before usability testing. I anchored the session on key listening moments, including starting playback, skipping, navigating chapters, changing speed, and multitasking with the mini-player. I walked the team through my assumptions and open questions so feedback stayed focused on real listening behavior.

Assumptions I brought into critique:

• Users needed listening fundamentals first, even if advanced features came later

• A conventional layout would reduce learning time and prevent errors

• Chapter skip controls were worth the added UI density if they improved listening flow

The critique surfaced a clear risk: skip buttons were competing visually with primary playback actions and could feel crowded on smaller screens. Rather than debate preferences, I designed two variants to test which better supported real listening behavior.

Variant A (Chapter-Focused):

• Chapter skip buttons inline with core controls

• No visual affordance on scrubber (clean progress bar only)

Variant B (Minimal):

• No chapter skip buttons (cleaner layout)

• Scrubber affordance (circle indicator) for clear interactivity

This test structure allowed me to validate two hypotheses: whether chapter navigation was essential enough to justify added UI density, and whether the scrubber needed explicit affordance to signal interactivity.

As for the mini-player, my team helped me refine my ideas down to a mini-player with a 15 second skip back button which I would take to testing.

Usability testing

I owned the usability testing end to end. I wrote and launched the screener in GreatQuestion, set up an A/B test in Maze using Figma prototypes, and selected 16 screened participants (8 per variant).

What I Tested:

• Variant A: Chapter skips inline + no scrubber affordance

• Variant B: No chapter skips + scrubber affordance (circle indicator)

Key Findings:

Chapter Navigation Validated as Essential:

• 95% preferred Variant A (with chapter skips)

• 3 of 8 participants in Variant B independently asked "How do I skip to the next chapter?"

• This validated chapter navigation as a core listening need worth the added UI density

Scrubber Affordance Less Critical:

• 2 participants mentioned uncertainty about scrubber interactivity

• However, this was secondary to the overwhelming preference for chapter controls

• Decision: Prioritize chapter skips, revisit scrubber affordance in future iteration

Other Validation:

• 100% recognized mini-player as interactive

• 95% understood playback speed quickly

• 95% understood new iconography I designed

Design Refinement Required:

While 95% preferred chapter skips, testing revealed visual hierarchy issues. The chapter buttons were the same size and weight as 15s/30s skip buttons, creating competition and confusion about which controls were primary.

Refinements Made:

• Increased play/pause button size by 20% to reinforce as primary action

• Moved chapter skips slightly outward for breathing room

• Adjusted visual weight (lighter stroke) to establish hierarchy: primary skip (15s/30s) > chapter navigation

Post-Refinement Validation:

Walkthrough with 3 additional participants confirmed the hierarchy was now clear—all could distinguish "skip within chapter" (15s/30s) from "jump to different chapter" without hesitation.

Documentation and release strategy

I owned the handoff end to end by creating comprehensive documentation and interactive prototypes so engineering could build without losing design intent or introducing inconsistencies across iOS and Android.

I worked with engineering to track usage behavioral patterns specifically to validate whether the control placement needed iteration over time. I also proposed and aligned on a staggered release plan. We would launch the core audio player first, then shipped the mini-player immediately after as a fast follow so users could benefit from the improved listening experience right away.

I extended the phased approach by documenting three additional features for the roadmap: sleep timer, bookmarking, and advanced accessibility. Because sleep timer was the lightest lift, I designed it in full and included it in the handoff. I deferred bookmarking and Siri-enhanced accessibility to a future phase due to heavier backend requirements.

During build, I led design QA across both platforms to ensure the implementation matched the MVP. I audited layouts, spacing, typography, and icon behavior, validated tap targets and state changes, and tested mini-player transitions in real listening scenarios. I triaged issues with the lead engineer, clarified intent with updated annotations, and signed off on fixes so the shipped experience felt cohesive across devices.

Results

Before the redesign, users would hit play and drop off within seconds because the video-player workaround broke basic listening behavior. After I shipped the dedicated audio player, we saw a clear shift in engagement.

Within the first two quarters post-launch, audiobook downloads and consumption increased 150% and overall app usage doubled across iOS and Android. As a leading indicator tied directly to the original problem, analytics reflected reduced early-session abandonment and stronger listen-through behavior, confirming the new player better supported listening and multitasking.

Design Decisions That Drove Impact:

• Background playback & lock-screen controls eliminated the #1 abandonment trigger

• Persistent mini-player enabled multitasking without losing context

• Chapter navigation reduced friction for mid-book resumption

• Offline downloads addressed mobile reliability concerns

CarPlay

Post-launch, I led the CarPlay integration, adapting the audio player for automotive contexts within Apple's Now Playing interface templates. This work focused on strategic UX decisions: determining which features to expose, prioritizing metadata for driver glanceability, and ensuring safe interaction patterns rather than visual design, as CarPlay enforces strict UI guidelines. [Full CarPlay case study coming soon.]

Challenges

Cross-Platform Consistency with Platform Differences

iOS and Android handle background audio and lock-screen controls differently—each platform has its own conventions for how users interact with media outside the app. I needed to deliver a consistent listening experience without fighting native OS patterns users already knew.

I partnered with both engineering teams to define what "consistent" meant: aligned interaction logic and behavior, not identical pixel-perfect UI. For example:

• Lock-screen controls: Used each platform's native pattern (iOS Control Center vs Android notification shade) rather than forcing a custom design

• Skip intervals: Kept skip behavior consistent (forward 30 seconds, back 15 seconds) across both platforms and all contexts (player screen, mini-player, lock screen)

• Mini-player navigation: Adapted to each OS's back-navigation conventions while maintaining the same core playback state

This approach ensured users got a familiar, reliable experience on their device while I maintained design intent across platforms.

Takeaways

This initiative reinforced a few core lessons for me. Clear goals and requirements early prevent scope creep. And on backend-heavy projects, tight, continuous communication with engineering is essential to keep design and implementation aligned.

• I set clear goals: I centered the work on immediate listening needs to keep the MVP focused while laying groundwork for future improvements.

• I leaned into engineering partnership: constant dialogue helped me understand platform behaviors, communicate intent clearly, and prevent late-stage changes.

I used asking the right questions as a strength: I proactively engaged stakeholders and engineering to reduce ambiguity and shape solutions that balanced feasibility with user experience.