Audio Player: The creation of the O'Reilly audiobook feature
TL;DR
I helped reimagine the audiobook experience for O’Reilly’s mobile app, moving from a video-player workaround to a purpose-built, mobile-first audio solution. As one of two product designers, I led user flow mapping, competitive analysis, iterative design, and usability testing. Through unmoderated Maze testing, we used a diverge-converge approach to explore layouts and validated decisions, like chapter skip, playback speed, and mini-player behavior. With tight constraints (8-week timeline), we scoped an MVP while designing toward a full-featured vision. The result was a thoughtful, high-performing audio player that continues to serve users well with minimal post-launch revisions.
Overview
O'Reilly Media, Inc. is a learning company that delivers technical and professional development through its online platform. Alongside books and courses, O’Reilly offers audiobooks to support subscribers who prefer learning through listening or want the flexibility to learn on the go. Initially, the mobile app used a stopgap solution—streaming audio through the video player in audio-only mode. To better serve audiobook listeners and improve performance, we reimagined the audiobook experience from the ground up with a mobile-first approach explicitly tailored for audio learning.
Roles and responsibilities
I was one of two product designers on the native mobile app team. We collaborated on the end-to-end design of the audiobook player experience. This included everything from initial research where we explored best practices across existing audiobook players, to clearly defining the problem we aimed to solve. I mapped user flows to visualize key journeys, conducted design explorations to identify and iterate on possible solutions, and gathered feedback from stakeholders throughout the process. We ran usability testing to validate our designs and refine the experience, followed by a smooth handoff to engineering. Post-launch, we monitored performance and user feedback to ensure the experience met listener needs in real-world use.
Scope and constraints
The product requirements document intentionally kept the scope for this net-new experience relatively light to enable a quick release. The roadmap included plans for a fast-follow mini-player and a few dedicated sprints for future upgrades. With scope creep always a risk, we designed our ideal end-to-end experience and strategically pared it down to a focused MVP that aligned with our timeline. We had eight weeks total from discovery through design and into dev handoff, so clarity and prioritization were key to delivering a solid foundation for the audiobook experience.
Process and what I did
Competitive Analysis
One of the unique advantages of this project was that we weren’t limited by legacy engineering or design decisions - we had the rare opportunity to build the audiobook experience from the ground up. As part of the discovery phase, I conducted a competitive analysis, reviewing dozens of audio players to identify what worked well and why. I also documented interesting interactions that didn’t align with our current goals but were worth considering for future iterations. After compiling the pros and cons, we compared our notes across the team and identified patterns in best practices, common user flows, and standout features. These insights helped shape the foundation for our native player and inspired the features we aimed to implement.
The competitive analysis involved noting what worked well for that particular interface, as well as what might work well for our users.
The competitive analysis made clear that audio player interfaces vary greatly across products. To explore the right direction for our experience, we broke down the player interface into modular components, reducing it to boxes. This allowed us to quickly sketch out as many layout variations as possible, free from existing conventions.
To maximize collaboration, we used a diverge-then-converge approach: Each of us selected our favorite rough layouts to refine individually, then regrouped to compare, critique, and align on the strongest directions moving forward.
As we refined our layouts independently, we noticed a natural hierarchy across our designs. Playlist and share actions consistently surfaced near the top, while core playback controls—chapter skip, back/forward, and play/pause—gravitated toward the center. We also began experimenting with placement and sizing for the future “mini-player,” considering how it would coexist with the native app.
We invested a lot of time organizing the layout in low fidelity, but because the interface relied heavily on iconography, we transitioned into high fidelity earlier than usual. The only image element we had to accommodate was the audiobook cover, which varied between rectangular and square formats.
Another critical consideration was designing for both iOS and Android. While we aimed for overall parity in experience, we couldn't make the two platforms identical due to backend constraints and the need to respect native interaction patterns. Striking the right balance between consistency and platform authenticity became a key part of the design process.
We ran though dozens and dozens of possible layouts between both Android and iOS devices
We brought in the broader product design team for group feedback at this stage. We had established a solid foundation, but several details still needed refinement through critique and discussion. Key topics included:
Whether to include chapter skip functionality and how it would integrate into the main controls
Feedback on play/pause iconography and whether it aligned with user expectations
Clarity and consistency of the seek icons (15s back / 30s forward)
Overall user experience around playback speed selection on Android
Early thoughts and input on the mini-player design and its future integration
While the top and bottom of the interface came together nicely, there was much debate on whether we should keep the chapter skips. Testing the interface would resolve many of our unsolved questions.
The mini-player required a flow chart as it needed to be anchored to the bottom everywhere with the app, except on the audio player.
Seek Button Timing
Another important discussion focused on timing the back and forward seek buttons. Through our competitive audit, we noticed a common pattern: 15 seconds for rewind and 30 seconds for fast-forward. The 15-second rewind feature appeared to support listeners who wanted to replay content without skipping too far back. In contrast, the 30-second skip appeared frequently in podcast players, which we hypothesized might be utilized to bypass commercials. While our platform doesn’t include ads, we believed aligning with these established interaction patterns was important, giving users a sense of familiarity and control.
Ultimately, we chose these 15- and 30-second durations as a thoughtful baseline and made a note to monitor user feedback post-launch. Two years later, there have been few to no complaints—the audio player still uses the same skip times, suggesting our timing hypothesis struck the right balance.
Mini-Player
The mini-player required careful consideration—not just in layout, but also how it would live within the broader app experience. We needed it to strike the right balance between persistent access and minimal disruption. It was essential for users to easily jump back into their content and have a straightforward way to exit the audio experience when needed. That led to introducing the ‘X’ close icon, giving users a sense of control. The play/pause button was an obvious inclusion, while the 15-second rewind earned a spot due to its utility. We also included the book cover and a scrolling chapter title to provide quick, contextual information at a glance. Tapping the mini-player transitions the user into the full (max) player, allowing them to access more advanced controls and features.
Next Steps
With the team's feedback, we decided to run another round of diverge-then-converge, this time in high fidelity. The goal was to interpret the feedback individually and explore how it could shape the next iteration of the audiobook player.
We split our design space again and approached the task by first outlining goals and key user tasks. We created separate prototypes from there, incorporating the latest design decisions and refinements. Once the high-fidelity prototypes were ready, we set up unmoderated usability testing using Maze to gather insights directly from users.
Maze Usability A/B Testing
To evaluate the interface, we defined a focused set of usability goals.
These centered around six key areas of the audiobook experience: the table of contents, chapter skip, mini-player, playback speed, progress slider, and download functionality.
Given that the Android implementation used a modal for playback speed adjustments, we chose to test the Android version of the interface.
We created two separate prototypes to test key interface decisions, the most notable being the inclusion of chapter skip functionality.
Prototype A included the chapter skip buttons, while Prototype B did not.
The product design team had expressed mixed opinions on their necessity, so we used testing as an opportunity to let user behavior guide the decision. By omitting the chapter skip from one version, we could ask testers if they felt anything was missing and observe whether they brought it up organically. In addition to the chapter skip difference, the prototypes also featured slight layout variations. Prototype A placed the chapter title and progress bar above the audio controls, while Prototype B reversed that order, placing audio controls first, followed by the progress bar.
Prototype A on the left, and Prototype B on the right
We conducted unmoderated usability testing through Maze, recruiting twenty participants - ten for each prototype. Our only requirement was that participants had prior experience using audio players, ensuring a baseline familiarity with common patterns. One limitation of the test was that Maze only supports desktop-based testing. Since we were designing a mobile-first audio experience and the desktop prototype couldn’t play live audio, we recognized that some results might be slightly skewed. Despite this, the test provided valuable directional feedback, helping us identify usability trends and surface user preferences across the two designs.
Task 1: Table of Contents
Find and start listening to the chapter on how to manage a team.
This task aimed to evaluate whether users could correctly identify the table of contents (TOC) icon and understand how to navigate within the audiobook. We knew the TOC icon was the most popular interaction within our app’s Reader feature (where users consume books), which sits on the far left side of the screen. I wanted to move it to the right for easier thumb accessibility. Testing it would allow us to see if the icon was still discoverable.
Another factor we closely monitored was potential confusion between the TOC icon (bottom right) and the “add to playlist” icon (top right). Visually, they are similar, so we wanted to see which icon users would gravitate toward and whether any mis-taps occurred during testing.
Testing result: Direct success of 90% for both A and B tests.
Recommendation: The heatmap suggested that completing this task was enough for us to keep the icon in the bottom right corner.
Task 1: The table of contents icon (left screen, bottom right icon) opened the TOC screen on the right through the use of a bottom sheet
Task 2: Chapter Skip
Restart the current chapter from the beginning.
This task's purpose was to determine whether a chapter skip function should be included in the final interface. Our goal was to keep the controls minimal and focused by limiting the UI to only the most essential features. Including a chapter skip function would add complexity, so we wanted to validate whether it was truly necessary.
I was especially interested in seeing how users in the group testing the prototype without chapter skip would attempt to complete the task. Would they struggle? Look for an alternative? Or even mention its absence unprompted? Their behavior would offer insight into whether the feature was intuitive, expected, or potentially unnecessary.
Recommendation: The results leaned in favor of including the chapter skip feature. When the option was present, the interface felt less ambiguous, and users more confidently completed navigation tasks. This gave us a strong signal that chapter skipping was not only familiar but also expected.
At the end of the test, we asked users if they felt anything was missing. Three out of ten testers from the no-chapter-skip group explicitly mentioned they would like an easier way to move between chapters, further validating the need for the feature. The feedback pointed toward including a chapter skip in the final design.
Task 2: Prototype A (left) demonstrates that a chapter skip was beneficial. Prototype B (right), had users tapping the 15-second back button multiple times to return to the beginning of the chapter. After the test, testers from prototype B mentioned they'd like an easier way to move between chapters.
Task 3: Mini player
You missed the last few seconds of your current audiobook while browsing the app.
Back up to the portion you missed.
Testing the mini-player allowed us to evaluate whether users recognized it as an interactive element or saw it as part of the static interface. We wanted to ensure it felt actionable - users understood they could tap it to return to the full player view, without overwhelming the rest of the screen.
Recommendation: With a 95% success rate, the mini-player has a strong enough pattern to move forward with the addition.
Task 3: Do users know they can interact with the mini-player? This heatmap says yes.
Task 4: Playback speed
Double the current listening speed.
We explored several ideas for enhancing the playback speed control, but recognized that some interactions would need to be simplified for the MVP. Speed control was one of those features we identified for future iteration. We prioritized clarity and ease of use for the initial release by delivering a simple, functional version that met user expectations without overcomplicating the experience.
Recommendation: 100% success rate. Keep it as-is for now, but continue exploring other ideas that add surprise and delight in the future.
Task 4: Our tap through playback speed cycled through five various speeds by half speed increments from 0.5 through 2.0 and tested extremely well.
We also tested interactions with the progress bar and the download feature. Our goal for the progress bar was to see if users recognized it as an interactive element and whether they would tap or drag it to navigate within a chapter. The download task focused on icon clarity and recognition. Users were asked to save the book to their device, which helped us evaluate whether the download icon was intuitive and easily discoverable in the context of the audio player.
Left screen tested user awareness of the progress bar being interactive. Right screen tested download icon findability and clarity.
Once testing wrapped up, we used the insights to finalize updates to the interface and overall experience. With the core mobile designs locked in, we shifted our focus to additional screen formats - designing for Android tablets and various iPad views, including regular, compact, and split-screen modes. This ensured a consistent and optimized experience across multiple devices and use cases.
Presenting the final iOS audio player MVP
iPad MVP
iPad horizontal split views
iPad portrait split views
Outcomes and lessons
The audio player remains my favorite project I worked on at O’Reilly. Building something net-new brought a unique set of challenges—defining our own MVP requirements, continuously evaluating feasibility with engineering, collaborating closely with my design partner, and communicating clearly through evolving ideas. One of the most rewarding aspects was the close partnership with the engineering team. Through constant dialogue, I gained a deeper understanding of platform-specific behaviors, especially around iPad, and learned how to communicate more effectively with developers. This project stands out as a true example of how strong cross-functional collaboration can elevate the design process and the final experience.