One design system for Music and Podcasts

Amazon Music had spent years optimizing for songs, albums and artists. Podcasts landed on top of that foundation as a second-class content type. Table rows and show pages had diverged across native iOS, Android, tablet web and desktop web. The team needed a single component library that handled both content types with the same vocabulary, so a feature shipped on one service wouldn’t get re-designed for the others. Every decision had to accommodate the gap between React on the web and React Native on the apps, and the leap between a 3-minute song and a 90-minute podcast episode.

I worked across product, engineering and the broader Amazon Music design org to unify the podcast row and the music row into one parameterized component. The first step was a multi-week audit of every row variant across native app mobile, browser tablet and browser desktop, mapping differences down to the pixel. Then a single design that absorbed the long-tail edge cases without compromising the music experience. The same approach scaled up to the podcast show detail page: a device-by-device audit drove one layout system the team could ship as a single component instead of four. Specs covered both React and React Native, so engineering could pick up the work in either codebase on day one.

The Music + Podcasts design system landed as one component library spanning React and React Native. The unified table row was accepted as v8. The show detail layout became the multi-device baseline. Four divergent surfaces became one system the team could evolve in lockstep, plus a template for how new content types plug into Amazon Music without forking the design language again. Amazon Music closed 2024 at $3.86B in revenue and 75M users worldwide, and by August the platform was already extending the pattern into AI-powered podcast discovery (the Topics feature), the cross-content evolution of the unified component library between music and podcasts is now complete.