STEFAN BRAUN
Back to overview
Selected work · 2025–2026

Foundation Before Feature

A product brief for audio playlists became a broader continuity problem. Research and recurring feedback showed that the main friction was not organising audio, but keeping listening going. I reframed the scope around a queue-first MVP that creates a reliable foundation for continuous listening before adding deeper playlist features.

Organisation
Handelsblatt Media Group
Role
Product Designer — Working Student
Duration
October 2025 – February 2026
Team
Product Owner, Research Team, Web Engineering, App Engineering
Audio queue flow: adding an item, opening the mini-player, expanding the player and switching to the queue. Open video file
In this caseOverview

Introduction / Project Summary

Handelsblatt Media Group already offered audio across Handelsblatt and WirtschaftsWoche. Users could listen to podcasts and to articles through an AI text-to-speech feature, but the web experience was still built around single-item playback. When one item ended, listening ended with it.

Recurring NPS feedback and a concept test with 648 participants led to a request for “audio playlists.” During synthesis, however, the problem appeared broader than playlist organisation. People described audio as something they used while commuting, multitasking, working, or winding down. In those moments, the more fundamental friction was interruption.

I reframed the brief from building a playlist feature to establishing a continuity foundation. The resulting direction was a queue-first MVP: continuous listening across articles and podcasts, with enough management to make the experience predictable and controllable.

Problem / Context

The initial brief was reasonable: Handelsblatt Media Group already had a saved reading list, so turning saved content into an audio playlist seemed like a logical extension.

The research pointed to a different need.

Users did not primarily struggle with organising audio. They struggled because playback stopped after every article or podcast episode. That interruption was particularly disruptive in the situations where audio had the most value — commuting, household tasks, work, or other hands-free contexts.

Building a playlist on top of the existing experience would therefore have added another organisational layer without fixing the underlying break in continuity.

The product question became:

How might we make listening easy to continue and control before adding deeper playlist functionality?

My Contribution

I joined Handelsblatt Media Group as a part-time working student between October 2025 and February 2026.

My ownership covered the shift from the original playlist brief to a defined, shippable MVP, including:

I worked closely with a Product Owner who managed stakeholder alignment and scope decisions, a research team that ran the concept test and usability study, and web and app engineering.

The strategic framing — queue over playlist, foundation over feature depth — was developed in close collaboration with the Product Owner. The design decisions and their rationale were mine to develop, document, and defend.

Process / Approach

Research & Reframing

The brief said playlists. The research suggested a more fundamental problem.

A concept test with 648 participants, combined with recurring NPS feedback, showed that audio was used as a companion in specific contexts such as commuting, multitasking, working, and winding down.

The system failed in those moments because listening could not continue automatically. After every article or podcast episode, the experience stopped and required another manual decision.

That changed the framing:

The system did not primarily fail because users lacked a way to organise content. It failed because listening could not continue.

648
Concept-test participants
NPS
Recurring listening feedback
Research inputs behind the shift from playlist organisation to listening continuity.

Ideation

Before narrowing the scope, I explored a much broader audio ecosystem.

The ideation work mapped four usage contexts:

Potential directions included AI-curated briefings, Siri quick commands, CarPlay, Smart Speaker support, cross-device handoff, and personalised audio experiences.

The purpose of this exploration was not to build all of these ideas. It helped identify which capabilities depended on a stronger listening foundation.

Exploration across morning, commute, work and evening contexts.

The Decision

The core product decision was:

Queue, not playlist.

A full playlist feature would have introduced deeper complexity around persistence, synchronisation, and content management before the basic listening experience was reliable.

The queue isolated the immediate problem: continuity.

The MVP therefore focused on the smallest meaningful system that could support:

This also protected the longer-term roadmap. App-specific patterns, account persistence, cross-device continuity, and personalisation could build on the same listening model later.

Rollout

The concept was structured as a staged rollout.

Stage 1 — Web Foundation

Stage 2 — App Experience

Stage 3 — Personalisation & Sync

The first stage deliberately prioritised a stable listening foundation before feature depth.

Before → After

Previously, the audio player behaved as a single-item experience. When one item ended, the listening flow ended.

The MVP introduced a shared Player / Queue hub so that playback could continue without requiring another manual start after every item.

Before: a single item, followed by another manual listening decision.
After: playback sits within a shared Player / Queue model.

Entry Points

Queue actions were placed where content decisions already happened.

Three-dot context menus on teasers and article headers gave users access to actions such as:

This allowed users to shape a listening session without leaving their current browsing context.

The system also accounted for duplicate prevention and confirmation feedback so that queue actions had clear outcomes.

Audio actions appear where people already browse content.
The article header provides another entry into the same listening model.

Player Hub

Playback and queue management were treated as one cohesive system rather than separate destinations.

The expanded player used two tabs:

Users could switch between listening and queue management while keeping the current playback context intact.

Basic management included:

The management model stayed intentionally limited, but complete enough to make the queue feel reliable.

Player and queue share a hub, preserving the current listening context.

Interaction Logic

Every queue action needed a predictable result.

I mapped the decision logic for states such as:

The flow defined when the system should play, pause, skip, add, reject a duplicate, or provide confirmation feedback.

The same interaction logic could then be applied consistently across entry points.

Specification of item states and the resulting player behaviour.

Validation

An unmoderated remote usability test ran on February 17–18, 2026.

The test included 11 participants aged 40+ across desktop and smartphone. The focus was on the core interactions rather than the complete product experience.

What held up

The main queue interactions were understood quickly.

Participants generally understood:

Reordering in particular matched existing expectations closely enough that users attempted it without needing explicit guidance.

What needed attention

Queue findability required brief exploration for some participants after adding an item.

Because the participants were unfamiliar with the product and were not representative of regular subscribers, this was treated as a learnability signal rather than immediate evidence that the information architecture was wrong.

11
Usability-test participants
40+
Participant age range
2
Platforms: desktop & smartphone
Unmoderated remote study, 17–18 February 2026. Core-interaction validation; participants were unfamiliar with the product.

Interpretation

The usability finding did not automatically trigger a redesign.

Instead, the question became whether queue findability would remain a problem in real usage after people had learned the interaction model.

That led to a set of post-launch monitoring signals rather than another major structural change before release.

Post-Launch Measurement Plan

Success signals were defined around the original continuity problem.

Sessions with 2+ items queued

Primary signal for whether users are building listening sessions rather than only playing isolated items.

Add-to-queue rate per session

Measures whether queue entry points are discoverable and useful during normal browsing.

Auto-next starts

Direct measure of whether the new system is actually creating continuous listening.

Queue opens after add

A findability signal: after adding content, do users understand where the queue lives?

7- and 14-day return to audio

A retention signal for whether continuous listening creates enough value for users to return.

Outcome / Impact

The project produced a defined queue-first MVP for the web experience rather than the originally requested full playlist feature.

The outcome included:

The key outcome was not simply a new interface. It was a more defensible product direction: solve continuous listening first, then build richer audio features on top of a stable foundation.

Reflection / Next Steps

Reframing a brief is a research responsibility

The most important decision in the project was not visual.

“Build playlists” and “fix listening” were not the same problem. Research made that distinction visible. Without reframing the brief, the team could have delivered a feature that matched the original request while leaving the more fundamental user friction untouched.

Constraints forced precision

Reducing the first stage to a queue made every remaining interaction more important.

The queue worked not despite its limitations, but partly because those limitations clarified what the first release actually needed to do well.

Foundation thinking requires product communication

A queue can appear smaller than a full playlist feature when viewed only as an output.

Its value becomes clearer when understood as infrastructure for future capabilities such as app patterns, account persistence, cross-device continuity, and personalisation.

Making that relationship understandable to stakeholders was part of the design work.

Next Steps

The next stages of the roadmap were intended to explore:

Post-launch behaviour should determine whether the assumptions from usability testing hold in real-world use, especially around queue findability, repeated queue creation, auto-next usage, and return to audio.

Next casePersonalised Practice PathsAll selected work