Designing podcasts that start on time
CueUp is a routine-first podcast app that schedules listening around your day instead of asking you to manage a queue.
I led the product from early concept through product strategy, information architecture, interaction design, prototyping, and visual design.
The challenge
Podcast apps are largely built like libraries. You browse, choose, queue, and press play.
That model works well when listening is intentional. It creates more friction when podcasts are part of a recurring routine: a morning briefing, commute, workout, or wind-down.
CueUp started with a different question:
-
What would a podcast product look like if listening began with time rather than content?
The goal was not simply to design a better player. It was to make podcasts easier to fit into everyday life without requiring people to repeatedly decide what to play and when.
What I learned
Research and founder conversations consistently pointed to four sources of friction.
Listening was already tied to routines
People did not only think about podcasts by show or topic. Listening was often attached to context: something for the commute, news in the morning, a longer episode while working out, or something lighter at the end of the day.
Choosing interrupted listening
Having plenty to listen to did not eliminate the decision. People still needed to find something appropriate for the amount of time and attention they had available.
Discovery created more options, not necessarily better decisions
Large catalogs made almost any podcast accessible, but provided little guidance about what fit a particular moment.
Listening became social somewhere else
People reacted to podcasts through group chats, social networks, voice messages, and conversations with friends. The listening experience and the discussion around it were largely disconnected.
The opportunity was not another discovery algorithm. It was reducing the number of decisions between wanting to listen and actually listening.
The product hypothesis
The initial framing
Design a better podcast player.
I reframed as
Design a personal podcast assistant that knows when listening fits into your day.
That changed the product hierarchy. I prioritized four layers:
- Routine
- Curation
- Conversation
- Playback
Playback still needed to be excellent, but it was no longer the differentiator. The core product bet became timing. If CueUp could understand when someone wanted to listen, it could make discovery and playback much less demanding.
Organizing the listening loop
I mapped the product around four moments: Discover → Cue → Listen → Discuss. The challenge was keeping scheduling central without turning CueUp into a calendar app. The resulting information architecture used five primary destinations:
-
Home
A feed of ideas, clips, quotes, and moments from podcasts, rather than a conventional library of episode artwork.
-
Discussion
Conversation attached directly to episodes, with activity from friends and the wider community.
-
Ideas
A personal collection of saved quotes, clips, and takeaways.
-
Schedule
The system for deciding what should play and when.
-
Profile
Connections, interests, preferences, and account controls.
A persistent player maintains listening context across the product. The schedule acts as the system of record for what happens next. Home and Ideas feed it with things worth hearing. Playback executes it. Discussion extends the experience after listening.
Designing around time, not a queue
A traditional podcast queue answers one question: What comes next?
CueUp also needed to answer: When should it happen?
That created a different interaction problem. A list could communicate sequence, but not the relationship between listening and the rest of someone’s day. A traditional calendar offered precision, but introduced too much complexity for something that should take seconds to understand. The schedule needed to show recurring listening moments without feeling like another productivity tool.
Why a circular day model
I explored the schedule as a circular representation of the day, with listening cues positioned around familiar moments such as morning, commute, work, personal time, and wind-down. Users could place podcast cues on the ring, connect them to routines, optionally use calendar context, and control whether playback should start automatically.
The goal was not minute-by-minute planning. It was creating recognizable anchors in the day. That distinction made the circular model more appropriate than a conventional queue or calendar. Editing the schedule could feel like shaping a routine rather than managing a playlist.
Automation without dependency
Schedule-aware playback becomes more useful with context such as calendar events and recurring routines. But calendar access could not become a requirement. Some users will not grant it, and a core product experience that depends on a sensitive permission becomes fragile before the user has received value.
I therefore treated manual cueing as a complete experience first. Calendar integration could make the system smarter, but the product still needed to work without it.
This also shaped the role of automation throughout CueUp. The product should make repeated decisions easier without taking control away from the listener.
Discovery through ideas, not episode lists
Most podcast discovery begins with shows and episodes. CueUp approached discovery one level lower. Instead of asking users to commit to a 45-minute episode based on artwork and a title, the Top Ideas feed surfaced clips, quotes, and individual moments first.
The idea could create the initial interest; the episode could come second.
This also created a natural connection between discovery and the rest of the product: See an idea → save it → cue the episode → listen later. Social signals such as saves and reactions could provide additional context without becoming the primary reason content was recommended. The goal was to lower the commitment required to discover something worth hearing.
Turning listening into conversation
Podcasts often create conversation, but that conversation usually happens outside the listening product.
CueUp treated this as a second product hypothesis:
-
Could conversation turn listening from a one-way activity into a loop?
Instead of introducing a generic social feed, I attached discussion to the episode itself.
People could:
- comment directly on an episode
- react to clips and ideas
- save quotes and takeaways
- see what people they follow were listening to
- move from a discussion back into the source episode
That created a potential loop: Listen → React → Discuss → Discover → Listen. Keeping conversation attached to the source preserved context and gave discovery a natural input: what people you care about were already hearing and discussing.
Designing for intermittent attention
CueUp would often be used while the user’s attention was somewhere else: walking, commuting, cooking, exercising, or working. That influenced where I introduced novelty.
Playback remained intentionally familiar. Core controls did not need to be reinvented. The schedule carried the more distinctive interaction model because that was where the product needed to communicate something genuinely new.
This separation allowed CueUp to introduce a different way of organizing listening without making every part of the experience unfamiliar.
Key design decisions
-
Time-first instead of library-first
Tension — Opening on a conventional library would make CueUp immediately understandable, but it would also make the main differentiator secondary.
Decision — I centered the experience on today’s listening context rather than the full podcast catalog. The product needed to communicate within the first few moments that CueUp was about what fits now, not simply what exists.
-
Circular schedule instead of a linear queue
Tension — A list is efficient for ordering episodes, but poorly suited to showing when listening belongs in a day. A calendar provides temporal structure, but brings the weight and precision of a productivity tool.
Decision — I used a circular day map to represent listening as a set of recurring anchors. The model made time visible without requiring users to manage a detailed calendar.
-
Episode-native discussion instead of a generic social feed
Tension — A standalone social feed creates more opportunities for engagement, but separates conversation from the thing people are discussing.
Decision — Discussion remained connected to episodes, clips, and ideas. This kept conversations understandable and allowed every social interaction to lead naturally back into listening.
Visual system
CueUp needed enough personality to feel different from a utility player without competing with the visual identities of thousands of podcasts.
For Now Playing, the interface pulls color from episode artwork to generate dynamic backgrounds. This gives each episode its own atmosphere without requiring custom visual treatment for every show. CueUp’s yellow remains reserved for identity and interaction moments such as active navigation, controls, and calls to action.
The system allows podcast artwork to remain expressive while CueUp provides a consistent structural layer around it.
Tradeoffs
Calendar access could not be a dependency
Calendar context can make scheduling more intelligent, but requiring it introduces both privacy concerns and onboarding friction.
Design response: manual routines remain viable without calendar access.
Automation creates a cold-start problem
Personalized curation becomes more useful as CueUp learns from listening behavior. A new listener has no history.
Design response: initial recommendations would need to combine explicit interests with editorially selected content until behavioral signals become useful.
Social features introduce moderation risk
Ranking discussions based primarily on activity or controversy may increase engagement while also rewarding unhealthy behavior.
Design response: I would not ship controversy as an isolated ranking signal. Discussion quality, moderation, and user controls would need to be part of the system.
Cross-platform consistency competes with early focus
A podcast product benefits from being available everywhere, but building multiple platforms simultaneously increases complexity before the core interaction model has been validated.
Product response: establish the experience on iOS first, then expand once the scheduling model proves useful.
What I would validate next
The most important question is not whether people understand the interface. It is whether they are willing to delegate a repeated listening decision to a schedule. The next phase should test the product longitudinally rather than through a single usability session.
I would measure:
- how many users create their first listening cue
- how many create more than one recurring cue
- scheduled playback completion
- how often users manually override CueUp’s selection
- whether routines remain active after one and two weeks
- whether scheduled listening increases overall listening frequency
- whether social activity leads back into episode playback
I would also look closely at overrides. An override is not necessarily failure. It may reveal where the product should preserve choice rather than automate it. That distinction would determine how far CueUp should move from scheduling toward true delegation.
Reflection
The initial assumption was that better playback could differentiate the product. It could not. Spotify, Apple Podcasts, Overcast, and other established products already play audio well.
The more interesting problem existed upstream of playback: deciding what should start and when.
CueUp changed how I think about automation in consumer products. The best automation does not remove every decision. It identifies the decisions people make repeatedly, preserves the ones that express preference, and quietly takes care of the rest.