Challenging the Brief: From Station Pages to Schedule
How user research redirected a major feature toward what listeners actually needed - a schedule-first approach to catchup radio.
My role
Product Design
Impact
Redirected the project scope
User testing evidence led the team to pivot from a station page to a schedule-first catchup experience, avoiding development of a feature users wouldn't navigate to.
Designed and shipped the schedule feature
The schedule shipped across the Rayo app, giving listeners a direct path to find catchup shows - the core need that research uncovered.
Uncovered a fundamental listening insight
Users navigate radio by date and time, not by episode. This insight reshaped product strategy and informed how catchup content is structured across the app.
Problem
The product team wanted to build dedicated station pages in the Rayo app - a hub for each radio brand with schedules, presenter info, social links, and featured content. On paper, it made sense. But no one had asked whether users actually wanted a station page, or whether it would solve their real problem: finding something to listen to when their favourite show has already aired.
The starting point
The brief was ambitious. Station pages, presenter pages, hero content, social links, contact forms - a feature set that would touch every corner of the app. The goal was to improve engagement and increase average time spent listening by giving each radio station a proper home in the app.
Our lead UX researcher had already been raising questions about whether this was the right direction. A co-creation workshop the previous year had surfaced an important stat: live radio accounted for 97.9% of all listening on the platform. If almost all listening was live, what problem was a content-heavy station page actually solving?
Rather than diving into wireframes, we decided to build understanding first.
Building the evidence
Over several weeks, the design team worked through a series of research and discovery activities, each adding a layer of understanding.
We ran a design workshop to define what a station page could be. We mapped out user personas - from devoted station fans to casual rainbow listeners - and created content tiers (Gold, Silver, Bronze) based on how much content each station could realistically support. But even here, the team raised concerns: if V1 was too far from the vision, we'd set a poor direction that would be expensive to correct.
We dug into the information architecture, running tree tests to see how users expected to navigate station content. We mapped user journeys for three core scenarios - finding a specific show, checking an upcoming schedule, and discovering new content. The third journey, discovery, was flagged as too ambiguous to even map properly. That was a signal.
We also uncovered technical and structural constraints - schedule data only went 30 days back and 7 days forward, brand-station hierarchies were complex, and content teams hadn't been consulted on editorial needs. These weren't blockers, but they shaped what was realistic for a V1.
Throughout all of this, a question kept surfacing in our discussions: what value does a full station page provide versus just building the schedule?
What users actually told us
I built prototypes of the station page and schedule, and ran testing sessions with real listeners. This is where everything clicked.
The schedule page was the standout. Multiple participants described it as "perfect" - easy to navigate, clear information, exactly what they needed. When I asked how they'd find a show they'd missed, they went straight to the schedule. They thought in terms of "I missed the breakfast show this morning" - a specific day and time - not "I want to listen to episode 47."
The station page itself didn't land. Users found the navigation between a Radio Page and a Station Page confusing and suggested combining them. The For You Page was too long, with entry points to schedules buried under irrelevant content. Terminology was another friction point - "on-demand" and "episodes" didn't match how people thought about radio. They called it "catch-up."
One phrase from testing stuck with me. A participant said what they really wanted was to "pick the phone up, hit play, and put the phone down." That was it. Minimal friction to live radio, and a clear path to catch-up when they'd missed something. A station page with social links, presenter bios, and featured content was solving a problem they didn't have.
Changing direction
Together with our UX research team, we presented the findings to the product team, and I supported the case with the prototypes and testing evidence. The recommendation was clear: don't build a standalone station page. Instead, take the components that tested well - primarily schedule, and integrate them into the journeys users were already on.
This wasn't about saying no to the brief. It was about solving the right problem. Users didn't need a destination page for a radio station. They needed:
- Quick access to live radio
- A schedule-based path to catchup content
- Consistent language and interaction patterns - "catchup" not "episodes."
The new direction was to distribute station page components - schedule access, presenter information, now-playing context - into the maxi player and the For You Page, rather than isolating them behind a dedicated page users would never navigate to.
What we shipped
The schedule feature shipped as part of the Rayo app. Instead of a station page you'd have to find, schedule access lives where listeners already are - surfaced in context, within the flows they naturally use.
Listeners can see what's on now, browse upcoming shows, and tap into catchup content from the schedule directly. The experience uses language that matches how people actually talk about radio - "catch-up" instead of "on-demand," shows identified by time and date rather than episode numbers. It's a small shift that removes a real point of confusion.
What I took away
The biggest lesson from this project was about the value of pausing before you build. The original brief was well-intentioned and logically sound - but it was based on an assumption about what users wanted, not evidence. By investing in research upfront, we avoided shipping a feature that would have been technically correct but practically unused.
I also learned something specific about radio listeners that I hadn't expected: they don't think about radio the way they think about podcasts or streaming. There's no concept of "episodes" or "browsing." Radio is live, and when it's not live, it's catch-up - anchored to a time they missed. Designing for that mental model, rather than imposing a content-library pattern, was the difference between a feature that tested as "perfect" and one that confused people.
The schedule is now live, and we're tracking engagement and average time spent listening to measure its impact. But regardless of the numbers, the outcome I'm most proud of is the process - a design team that used research to ask the right questions, challenge assumptions constructively, and ship something that genuinely matches how people listen to radio.
Written by Alex Chiu, Senior Product Designer in London. Contact: alex@mchiu.co.uk.