Back
My SiriusXM — final designs

My SiriusXM

Role
Product Design Intern
Date
Summer 2026
Timeline
3 weeks
Team
1 designer, 1 PM, 1 content designer

Overview

SiriusXM is redesigning the Library page to be an all-in-one "My SiriusXM" page for users to find, manage, and return to content. I worked as the sole designer on the Episodes and Favorites drill-down pages. Over 3 weeks I designed these pages across mobile, tablet, web, and TV breakpoints.

My main focus was the episodes page. I combined two types of episodes into an easy-to-navigate drill-down view so users could quickly find and play episodes.

The current state

Episodes didn’t have their own dedicated page. Instead they were organized in two folders in the library. Hiding content behind folders and separating two different types of content (saved vs new) led to fewer users regularly using episodes.

The current Library, with My episodes and New episodes listed as folders alongside channels and shows
The library page
The My episodes list, filtered by Downloaded, each row carrying a download icon
My episodes
The New episodes list, each row carrying a save icon and a download icon
New episodes

The process

This case is organized into the four main decisions I drove during the design process.

Advocating for action buttons

The original product brief wanted to remove action buttons (save and download) to promote the long press, which could hold more actions.

I argued that removing them didn’t just take away the only call to action to save or download episodes. It also made it impossible for users to tell which items weren’t saved or downloaded yet.

As specced (no action buttons)
The Episodes page as specified, with New, Saved and Downloaded filters and no secondary actions on any row
As shipped (with action buttons)
The shipped Episodes page, each row carrying a save tick and a download arrow that fill in once the episode is saved or downloaded

Replacing meaningless filters with actionable ones

The My SiriusXM Episodes page merges My episodes and New episodes. Thus, it made sense to think about how these two types of content should be differentiated in the new Episodes page. I began my process exploring different ways to break up the New and Saved episodes, but quickly found problems with this divide.

  1. New as a category and new as a badge meant different things, creating inconsistent labelling. The new badge appears on episodes released in the last 48 hours, but “new” (in the New episodes sense) refers to the most recent episode of podcasts you follow, which might be a week old. So a “new” filter would hold some items badged “new” and others that weren’t.
  2. The median user follows one show, meaning they’d have a maximum of one “new” episode. That makes the “new” filter unnecessary for most users.
  3. “New” and “saved” are arbitrary backend distinctions. To a user, everything in the drill-down is an episode they care about — whether they saved that episode themselves or it came from a show they follow. Forcing them to choose between the two is unnecessary.
Initial explorations of "new" and "saved"
The specced Episodes page with All, New and Saved filter pills
Filter pills
An iteration splitting the page into a New Episodes section above a Saved Episodes section
Double header: inspired by the car view
An iteration with a Saved folder row above a New Episodes list
A Saved folder

Instead of forcing this distinction on users and causing confusion between different types of “new,” I advocated for status-based filters (unplayed, in progress, downloaded), since users could act on those.

The shipped filters: All, Unplayed, In Progress, Downloaded
The shipped filters: All, Unplayed, In Progress, Downloaded

Developing a new filter framework

The brief originally proposed disappearing filters for both the Favorites and Episodes pages. I proposed a new framework for filter behaviour depending on whether a filter is status-based or categorical.

  • Categorical filters should change depending on content.

    • The point of categorical filters is to browse a collection more efficiently; scrolling past empty filters defeats the purpose.
    • The empty state doesn’t provide meaningful information.

  • Status filters should be persistent.

    • Status filters orient you, so the empty state carries information.
      • E.g. no unplayed episodes left → you started all the episodes you wanted to listen to.
    • Status changes far more often, and a filter set that is always changing feels unstable.

Based on this logic, I successfully argued that Favorites filter pills (categorical) should adapt to the content while Episodes pills (status-based) should stay consistent.

Demo of the favorites filters disappearing as content changes

I adapted designs across 4 breakpoints

One pattern that broke across the breakpoints was the infinite scroll pattern. On mobile, tablet, and web, the favorites and episodes sections were infinite scrolls, with a view all button in the section header. However, the design system didn’t support a view all button in the header for TV. Instead, TVs used a “view all” tile placed in the final slot. However, placing the “view all” tile at the end of an infinite scroll made the “view all” mostly redundant.

We briefly considered not having a drill-down page at all in TV and having the page navigate via the infinite scroll, but this took away users’ ability to filter content. Thus, I decided to not incorporate infinite scroll in TV breakpoints, and instead cut the scroll off and put a “view all” button in the last slot.

Demo of navigating TV view via remote with "view all" tile

The final design

Episodes
Favorites

In total I designed the Episodes, Favorites, and Downloads drill down pages, the Live & Upcoming games section, and all empty states across 4 breakpoints

The full design file: four rows of frames, one per breakpoint, covering every state of the Episodes and Favorites pages

Conclusions

What I learned

This project was an incredible learning opportunity and huge thank you to the working team, my mentors Joshua Claassen and Michelle Hsu, and the design systems engineers for helping me navigate everything! Two of my key takeaways were:

How to design consistently across multiple breakpoints

This was my first time designing in a formal design system. Adapting a page across multiple breakpoints meant rethinking the flow in the context of the new device, not just scaling the design. When components or design patterns didn’t translate, I worked with the design systems team on what was feasible.

When to challenge requirements

This was also my first time designing against formal product requirements. Asking why each one was written taught me the reasoning underneath: the design system’s constraints, the business goals, and the research behind them. It also surfaced the ones whose rationale had gone stale. I challenged requirements like the disappearing episode filters as the design evolved.

What’s next

  1. Measure playback starts after launch and compare against the current library’s 27% of playbacks.
  2. Measure whether there is an increase in Time Spent Listening (TSL) per session and per user compared to the current Library’s 20%.

Thanks for reading