← Back to all work

Bringing Design to a Team That Had Never Had a Designer

Rayo is Bauer Media's audio app - live radio across the station brands, plus catch-up and podcasts, on mobile, web, car and smart speaker. Its Alexa skill had been shipping for years with no designer: no documented flows, no design files, and everything about how it worked living in the PO's and the lead developer's heads.

After helping take the Rayo app from beta to launch, I volunteered to move to the Voice and Connected Device team as its first designer, alongside a developer and a QA who joined at the same time. What follows is the evidence I started from, the diagnosis that set the team's priority, the decisions I made and what they cost, and what two years of support data can and cannot tell you about the result.

My role

Sole designer

Impact

The biggest complaint theme fell and stayed down

Premium listeners hearing adverts was the largest ticket theme and the one most directly downstream of broken linking: 753 tickets in January 2024, 54 in January 2025, and a monthly average that went from 185 to 56 and held there for two years. Other teams were improving the premium experience over the same period, so I do not claim that fall as mine alone - what the data does and does not support is set out below.

Seven ways to link became one

Seven linking routes, each with its own bugs and no consistent logic between them, converged on a single path through the Alexa app using Amazon's app-to-app pattern. Six help centre articles were rebuilt around the three themes the diagnosis had identified.

A source of truth the team could run

I rebuilt the skill in Voiceflow: every intent, its conditions, synonym variations and error states. Developers built new features from it and QA tested against it, so it stopped being my documentation and became the team's spec. And because the journeys were mapped in full, it runs - you can talk to it and it answers, close to the live skill.

What I inherited

Seven different ways to link a Rayo account to Alexa. Six help centre articles explaining them. Zero documented flows, and no shared source of truth for how any of it worked.

A product that reported success it had not achieved

The app says you are linked. Alexa confirms you are a premium member. You still hear adverts. You unlink, and nothing actually unlinks - permission is revoked but the OAuth tokens stay alive, so the state is wrong in a new way. You re-link to fix it, and it happens again.

Silent failures throughout

Nothing ever told anyone that something had gone wrong. On a screenless device there is nowhere to look and nothing to read, so a listener could not tell a broken link from a broken app from a broken subscription. Neither could customer service.

The audit

I started by failing the way a new user fails

I had never used an Alexa device. I bought an Echo Dot and an Echo Show, set them both up with no help from the team, and documented every step from first power-on through finding the skill, exploring content and playing a specific show. Before I could judge the experience I had to be able to describe it.

What the skill could actually hear

Alexa skills were not conversational at this point - this predates Alexa+. The skill only responded to word-perfect utterances built for each intent. Anything else failed, silently, on a device with nowhere to show you why.

I asked the lead developer for the interaction model JSON and went through it with him to understand how it was structured, then pulled it apart and documented every intent, utterance and synonym in Confluence. It stopped being something only one person could answer.

Five problems, two causes

There was no research platform at Bauer yet - UserTesting and UserZoom only arrived after this shipped - so I went to customer service and asked what people were actually contacting us about. They pulled three months of contacts, the skill store reviews and the premium cancellation survey. Smart speaker problems were a recurring theme in support, the store listing was dominated by one star reviews, and a meaningful share of people cancelling premium said they could not use it on their device.

Five issues came up most: premium users hearing adverts, account linking failing, premium features not working, access to premium stations, and playback and streaming drops.

Four of the five were the same failure wearing different clothes: the account link was not holding. Permission, OAuth tokens and Amazon's own record could all disagree, and nothing owned the truth. If the link state is wrong server-side the premium catalogue is not returned, so hearing adverts, losing premium features and losing premium stations are not three problems sitting next to a linking problem. They are the linking problem, described by the listener in the terms they experienced it.

The fifth, playback and streaming drops, was a separate technical fault with nothing to do with linking. I spotted the pattern in the ticket themes; the lead developer supplied the mechanism, which was that unlinking revoked permission without ever clearing the tokens. Joint diagnosis, not a solo one.

I took the customer service report to our PO and made the case that account linking should be the team's first priority: four of the five biggest complaint themes traced to one cause, and it was hitting paying customers. It became the priority. That was the first time design had set the agenda on that team.

Restructured journeys

A source of truth that runs

With no documentation and no design files, my first job was to make one. I rebuilt every intent in Voiceflow - intents are the voice equivalent of features - mirroring the real skill including its conditions, synonym variations and error states. Developers built new features from it and QA tested against it. Because the journeys were mapped in full it also runs: you can talk to it and it responds, close to the live skill, which is how I have used it for testing features designed since.

Seven paths into one

The root cause sat in the backend: Shepherd, our own system, could not communicate reliably with Amazon. I took the diagnosis to the backend team and asked whether the underlying problem could be fixed. They agreed with it and had no capacity - fair enough, they had just launched Rayo and were carrying the tech debt from it. So the question became what could be fixed inside my own team's control.

That is what led to consolidating the routes rather than repairing them. The legacy brand apps had Amazon app-to-app linking built in, technically the most direct route and also the buggiest, and fixing it needed the backend work we did not have. Linking inside the Alexa app was the most stable and the simplest to explain: tap link, sign in with your Rayo account, agree, done. Rayo owns two screens inside that flow. The rest of it is Amazon's, and so is the last step of every other route - which is why adding routes only adds places to fail.

Four decisions, and what each one cost

  • Where linking happens. Fix the buggy in-app routes, keep several routes and improve them all, or hand off to the Alexa app. I handed off. Cost: a branded handoff Rayo does not control.
  • The old invocation. "Alexa, open Planet Radio" could be retired at launch, kept temporarily, or kept indefinitely. Kept indefinitely. Cost: two invocation names to maintain. Listeners with a decade-old habit should not have to relearn it.
  • The rebrand message. "This is Rayo, the new name for Planet Radio", time-boxed to three months. Cost: every session slowed for three months, on a surface whose whole value is speed to audio.
  • Making linking worth doing. No incentive, a premium discount, gating a feature people already have, or building a new feature and gating it. Continue Listening, new and only for linked accounts. Cost: engineering time on a feature whose only job was to justify a different feature.

On the last one: gating something people already have is a takeaway. It would have generated exactly the support contacts this project existed to remove, and it punishes the unlinked rather than rewarding the linked. Building something new and putting it behind the link means nobody loses anything.

On the three months: long enough that an occasional listener heard it a few times, short enough not to slow every session indefinitely. It was a judgement call discussed with the team, not a calculation. Looking back I would let the data end it rather than the calendar - watch the split between people saying "Rayo" and people still saying "Planet Radio", and retire the message when that curve flattens.

The flow runs across three surfaces

What makes this different from designing a screen is that it does not live on one surface. It starts in voice, passes through Amazon's system layer, and finishes on the phone. Rayo owns neither the middle nor the end.

Three checks have to pass before anyone can be sent anywhere, and none of them are visible to the listener: is the Alexa app installed, is this one profile or a household with several, and are notifications on, off, or never set? If the device belongs to a household the link can only go to the primary user, so there is an extra step to confirm that is what they want. And if notifications are on, Alexa says "I'll send you a link"; if they are off, it says you will find it in the Alexa app. Same flow, different words - honest about a permission Rayo does not control rather than promising something that will not arrive.

Most of the estate has no display, so the Echo Dot path was designed as the complete journey. The Echo Show adds one option, the QR code. The screen is additive, never load-bearing.

Every exit teaches the way out

Good design lets someone feel in control, and on a phone that is easy: if you want to know whether you are linked, you open settings and look. On a voice device there is nothing to glance at. The only way to check is to ask, and that only works if you already know the exact words. So every exit in the flow, successful or failed, ends by teaching the utterance that checks it. If someone is stuck, the dead end should at least leave them with something they can use next time.

Help where the problem is

On the Echo Show, a Get help button opens the Rayo support page in Alexa's own browser, in situ rather than sending anyone away. The three articles surfaced there - linking, hearing adverts, premium stations - are the three themes from the diagnosis. I took those themes back to customer service and we rebuilt the help centre around them, so the guidance was prioritised by the same evidence as the design.

Continue Listening, and the half I did not ship

Everything above makes linking work. None of it makes linking worth doing. You scan a code, sign in, agree to a permission screen and land back in exactly the same experience. If you are premium there is a payoff. If you are not, it is pure cost, and the business wanted everyone linked.

Continue Listening was my answer: ask Rayo to continue and it picks up whatever you had already started, with your listening history on the Echo Show home screen for linked users. What I originally designed was cross-device - you listen on the way home, you walk in, you ask Alexa to carry on. That is the version that makes linking worth doing, it needed backend work the team did not have, and it was scaled back to Alexa-only. What you start on the Echo, you continue on the Echo. That is what shipped.

Everything fell. Except the one thing I said was unrelated.

The new linking flow shipped in Q2 2024. I do not have the analytics I would want - GA4 was not implemented on the skill until October 2024, months after this shipped - so there is no clean before and after in product data. What I have is two years of customer service tickets.

Hearing adverts as a premium user went from 753 tickets in January 2024 to 54 in January 2025, and from a monthly average of 185 to 56. It held at that level for two years with no drift back. Across all eight support categories, monthly averages, 2024 (excluding June and July) to 2025: account linking 14 to 4, down 71%; hearing adverts 185 to 56, down 70%; billing 75 to 26, down 66%; voucher 9 to 4, down 58%; general 41 to 21, down 49%; account 20 to 10, down 49%; cancel subscription 76 to 42, down 45%; streaming 22 to 22, up 2%.

Why I cannot hand you a clean number

Billing fell 66% and I had nothing to do with billing. 2025 was a better year across the whole premium experience and other teams were fixing things at the same time, so the fall in the linking-related categories cannot be attributed to this work alone, and I am not going to claim it.

What does hold

Streaming is the one theme I had diagnosed as a separate technical fault, and it is the only category that did not move. If this were simply lower ticket volume overall - fewer subscribers, a channel change, people giving up on contacting support - streaming would have fallen with everything else. It did not. So these are real category-level changes, and the prediction I made before doing the work is the one that held.

What this data does not say

  • Account linking tickets themselves were never the big number: 14 a month down to 4. It has the largest percentage fall on the chart and the smallest raw one. The impact shows up downstream, in the themes people actually complained about.
  • June and July 2024 are excluded. A backend refactor logged everyone out and produced over a thousand account-linking tickets in two months. Leaving it in would make every fall look bigger than it was.
  • These are support contacts, not behaviour. Fewer complaints is not the same as more successful links.
  • A large spike in linking events in late 2025 was a marketing campaign, not this work.
  • April 2025 shows a joint spike in hearing adverts and streaming, which looks like one technical incident hitting both rather than anything to do with linking.
  • Nobody watched a real listener attempt the redesigned flow before it shipped. The evidence was behavioural and at scale, plus one first-run walkthrough by me, and by then I knew too much to be a useful test.

Two years on, the phone becomes the control surface

Back on the mobile team, I led the Rayo app side of app-to-app linking, and it has now shipped. Smart speaker settings sit with the other account-level settings: a primary link CTA, and sample utterances shown before you link - the device with a screen teaching the device without one.

There are three states: not linked, link pending and linked. Link pending exists because the status is eventually consistent. Shepherd queries Amazon for live status, usually instantly and occasionally a few minutes behind, so rather than assert something it cannot know, the screen says so and offers a route into the Alexa app, which always shows the accurate status. Unlinking routes there too. Rayo can never own linking - whichever direction you go there is always a step under Amazon's control, and the honest design is the one that admits it.

What I would do differently

Agree the feedback loop before the build, not after

I shipped this without a loop at either end. Nothing was watched before it went live, and nothing could be measured after it, so I had strong evidence about the problem and almost none about the solution. The fix is one thing rather than two: agree up front how the design will be validated and how it will be measured, and make the case to analytics for tracking to land as part of the build. On this project that means link completion rate, time to link, and linked versus unlinked listening hours.

Ship the whole incentive, or none of it

In-skill resume shipped. Phone-to-speaker resume, the part that gives a non-premium listener a reason to link at all, did not. When the cross-device version turned out to need backend work we did not have, I accepted the smaller one, and the smaller one does not do the job it was built for. The deeper version of that: "can we build all of this" and "is the half we can build still worth building" are two different questions with two different owners. Taking the answer to the first as the answer to the second is the actual mistake.

Smaller things I would carry forward

  • Documentation needs a named owner. The Voiceflow file was the team's source of truth, and the team was later disbanded.
  • A written state model - what linked means and who owns it, agreed across product, backend and customer service and checked against Amazon's docs - would have surfaced the five-problems-one-cause insight on day one.
  • The customer service report was a one-off ask. A standing monthly read would have made it a feedback loop rather than archaeology.
  • Logging the actual fallback utterances would turn every misheard request into a synonym to add.

What I took away

Most of what made this work was not screen design. It was getting a team that had never had a designer to agree on what the flow actually was, and then keeping that agreement somewhere everyone could use it.

The other half is the partner surface itself. You are always designing around somebody else's last step, so the real job is deciding where to spend the control you do have. Work on the skill is paused while the team waits on Alexa+, and one constraint is still open: "Rayo" is acoustically close to "radio", and Alexa cannot reliably tell them apart. That one is a conversation with Amazon, and the kind of problem you only find by reading what the system misheard.

Experience it yourself

Everything you've just read about is live. If you have an Alexa, just say "Alexa, open Rayo" and try it for yourself.

Written by Alex Chiu, Senior Product Designer in London. Contact: alex@mchiu.co.uk.