Increasing Audiobook Engagement 150% Through Native Playback Design

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 increasing audiobook content consumption.

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 what I should focus on for the MVP. 

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 a mini-player to support multitasking. 

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.

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 

• Dark mode implementation

• iPad and tablet devices

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

Context

O'Reilly Media 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 the native app 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

• 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.

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 into an MVP we could realistically ship. I led an impact vs. effort exercise with both iOS and Android 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 and Android 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

• Impact: Users expect to lock their phone and keep listening, 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

• Impact: Adding the ability to scrub would let people visually see their progress, navigate to any point with a single gesture instead of multiple button taps, and recover from interruptions.

3. Variable speed

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

• 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. Downloads for offline listening

• 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.

• Impact: 60% of sessions on mobile networks experience streaming failures causing 27% abandonment. This feature would eliminate streaming-related abandonments.

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, provide always-visible playback context, and eliminate the friction of constantly navigating back and forth between player and library.

Deferred (High-Value but Timeline Risk):

• Sleep timer - High user request but not pressing for MVP

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

• Voice control - Important for accessibility but could enhance in a future version

Designs and critique

Flows

I created end-to-end user flows for the MVP to define how listening worked outside of 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.

High fidelity

Despite shipping on two platforms, I designed for consistency. 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 faster chapter navigation but used less often than skip back

• 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. I decided to test two variants to validate if chapter skip was needed.

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

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 created comprehensive handoff documentation and interactive prototypes so engineering could build without losing design intent or introducing inconsistencies across iOS and Android.

I worked with engineering on instrumentation 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 ship 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 edge cases. 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.

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.

Takeaways

This initiative reinforced a few core lessons for me. In order to prevent scope creep, set clear goals and requirements early, 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.