AI Product Design - Designing podcast discovery for listening, not reading
- 12 hours ago
- 5 min read
Exploring how AI-selected moments and interaction design can help listeners decide before they commit
I’m working on a project built around an unusual premise: cold network calls that become spontaneous podcast episodes. Real conversations are recorded with permission, shaped into episodes, and then surfaced for other people to discover.
While working on that idea, I ran into a problem that extends well beyond this project: podcast discovery still relies heavily on reading.
Podcast discovery still asks you to read first
When you browse podcasts, you’re usually asked to make a listening decision from text. You scan the title, read the description, recognize a guest name if you’re lucky, maybe infer something from the artwork, and then press play hoping your interpretation was right.
That feels slightly backward for an audio product.
Video often handles this better. On YouTube on PlayStation, for example, simply focusing on a video can trigger a short preview before you commit. You experience the content first, then decide whether it deserves more of your attention. YouTube creators who understand the pattern also design their opening seconds accordingly.
That made me wonder whether podcast discovery could work the same way: instead of explaining an episode, let the episode introduce itself.
The hypothesis
Simply autoplaying the beginning of a podcast isn’t enough. Spontaneous conversations often take time to warm up, and the first 30 seconds are not necessarily representative of the most valuable parts.
The more interesting opportunity was to use AI to identify a small set of strong moments, then use interaction design to turn those moments into a coherent preview.
The core hypothesis was simple: if listeners can quickly experience the tone, substance, and rhythm of an episode before committing, discovery becomes a listening problem rather than a reading problem.
What I built
I built an interactive 9:16 podcast card designed around that idea.
On desktop, hovering over the card starts the experience. On mobile, the interaction can activate when the card becomes the focused item in the viewport. From there, the card moves through a short sequence.
First, a playhead scans across the waveform, creating the sense that the system is inspecting the episode. It then surfaces three AI-selected moments along the timeline. Those moments become a roughly 30-second montage, with synchronized captions and timestamps helping the listener stay oriented. Once the preview ends, the experience fades and the card flips into a clear Play full episode action.
The result is less like a conventional podcast card and more like a lightweight trailer generated from the conversation itself.
Why this matters to the product
Hypothesis: the broader product depends on spontaneous conversations becoming discoverable content. That creates a specific challenge: the listener wasn’t there for the original call, may not know the people involved, and has no built-in reason to care about the conversation.
Discovery therefore has to earn attention quickly.
I don’t want someone to read a paragraph and try to predict whether the conversation will be interesting. I want the conversation to prove it.
That makes this component more than presentation layered on top of the product. It is the point where someone decides whether a conversation that started as a cold call deserves another 20+ minutes of their time.
AI helps identify which moments may be worth surfacing. Interaction design determines how those moments are sequenced, framed, and experienced. The value comes from the two working together.
The interaction became the investigation
Once I started building, the important questions became much more specific.
When should the scan stop? How quickly should each moment appear? Should the playhead jump directly between excerpts or visibly travel between them? How long should captions remain on screen? How much supporting information can appear before the preview starts feeling like another thing to read? At what point should the experience stop previewing and ask for commitment?
These can sound like micro-interaction details, but they are the product experience. They determine whether the preview feels fluid, informative, distracting, or artificial.
They are also difficult to answer convincingly in a static mockup. I needed to experience the timing directly.
Building changed the cost of exploration
A year ago, I probably would have treated this as a dedicated prototyping exercise. I would have designed the states in Figma first, created enough motion to communicate the idea, and potentially involved engineering later if I wanted to understand how the real interaction behaved.
This time, I built the component directly.
Using React and TypeScript, I could structure the experience as a reusable component rather than a one-off prototype. Vite kept the development loop fast, which matters when most of the work is repeated adjustment. Motion handled animated transitions, timing, and state changes, while CSS 3D transforms gave the final card flip a more physical feel.
The sequence itself was driven by timed state changes controlling when the waveform scan starts, when selected moments appear, when playback advances, and when the preview transitions into the final CTA.
I used Cursor throughout the process to accelerate implementation, refactoring, debugging, and small interaction changes. The value was not simply that it wrote code faster. It reduced the friction between noticing something in the experience and testing a different version of it.
The first useful version took roughly 1–2 hours.
Not because the interaction was trivial, but because the cost of answering each small design question had dropped dramatically.
The output wasn’t a throwaway prototype
That distinction matters.
I didn’t end the investigation with something whose only purpose was to explain what engineering should eventually build. I ended with a working component that can become part of the project itself.
The process produced the interaction model, sequencing logic, reusable UI, implementation knowledge, and a clearer understanding of the product at the same time.
Investigation became infrastructure.
That changes the economics of exploration. Instead of deciding which questions are important enough to justify a prototype, I can investigate more of them while I’m thinking, and the artifact I use to answer those questions can survive beyond the investigation itself.
What this AI product design discovery changed for me
I still think prototyping is fundamentally about making an idea tangible enough to evaluate.
What has changed is what can happen after that AI product design discovery.
AI-assisted development is compressing the distance between thinking, testing, and building. For a product designer, that means the artifact used to answer a question can increasingly become the foundation of the thing itself.
I’m not trying to become an engineer. I’m becoming a product designer who can investigate product questions directly in the medium where the experience will eventually live.
For this project, that meant taking a simple question — shouldn’t you be able to hear whether a podcast is worth listening to? — and turning it into a working interaction in an afternoon.
Then continuing to build from there.
This is still a non-audio prototype, so the next challenge is synchronizing the audio and visuals properly.
Yikes.
Comments