Go Live! // Audacy

Stream live audio without limits. Anytime, anywhere.

Lead product designer

ROLE

Jun 2022 - Sep 2023

TIMELINE

The challenge

Go Live is an Audacy-affiliated platform where radio and show hosts have the ability to broadcast live to an audience without the need for a studio. Hosts and DJs wanted to go beyond their scheduled radio shows to reach their audience in a fun and impromptu way.​

This project came about as part of a larger initiative for Audacy to stay competitive in the audio streaming world. Following a rebrand and revamped listener experience, there was a desire to get even closer to the listener community by utilizing continuously more powerful streaming technologies. I worked with the team to shape the framework and experience of this app from the ground up.

Use cases and real-life context

Sporting events

With this tool, radio hosts can have the ability to broadcast while at a game or event, providing their audience with a more intimate view of what it’s like to be in the arena as a radio personality.

Remote guests

Guest speakers often aren’t able to come to the studio on tight schedules. Allowing hosts to broadcast with guests remotely, outside of standard programming, would break the limitations of having to wait for the program to air.

Live journalism

Situations arise where a news radio personality would want to provide coverage from the ground, such as at a conference or protest, or while reporting traffic and weather locally.

Simple banter

Chatting and having fun conversations between hosts and their audience about anything they feel like. From childhood memories, to worst gifts they’ve received, and anything in-between.

Initial story map

During our initial kick-off with the Product Director and team, I was provided with a story map from engineering and the streaming tech vendor. This was a decent starting point for understanding core functionality and the capabilities of the tech available to us.

broadcast scheduling

Hosts should be able to run an impromptu session, and they should also be able to schedule sessions for a later date.

audience questions

Listeners should have the ability to post a question or prompt when they are requesting to be a caller. This would give the host a better understanding about what the caller would want to talk about.

chat & activity

Hosts and Listeners should have the ability to chat and send emoji & reacts to stay engaged in the session.

inviting co-hosts

Hosts should be able to invite co-hosts or guest speakers either during a session, in advance of a session, or for a scheduled future session.

managing callers

Audience Callers can request to join broadcasts, therefore a host will need crowd-management and moderator tools.

ad breaks

For monetization (and to take quick breaks) a host should be able to initiate ads during the broadcast. Hosts should have control over how long the ad break is.

Competitor feature analysis

We also needed to see what other platforms were doing, and additional features they might have.

instagram live

  • Ability to create fundraisers

  • Impromptu and Scheduled lives

  • Invite others to join

  • View questions and requests

  • See chat and reactions

twitter spaces

  • Set name and select topics from list

  • Impromptu and scheduled Spaces

  • Invite co-hosts and speakers

  • View speaker requests

  • Add tweets and media to Space

  • Adjust settings mid-broadcast

discord stages

  • Assign Topic for the Stage

  • Available only on community servers

  • Moderator, Speaker, and Listener roles

  • Pin stream to discord channel

clubhouse

  • Public and Private rooms

  • Invite people who follow you into room

  • Add Room title

  • Raise hand

  • Connect to Twitter to find friends

  • Follow people and topics,

Wireframes ver. 1

V1 rapid test summary

The first round of wires was introduced to the product team as well as the hosts who were interested in giving feedback. I ran a series of rapid tests by sharing the screens and took notes. Here are the key takeaways:

The good stuff

  • 3/5 Testers liked the broadcast setup options and felt it were robust enough to fulfill their needs.

  • 5/5 Testers liked the information on the “connecting” screen, but weren’t sure if “ready co-hosts” and “notifying followers” was relevant before the broadcast started

  • 5/5 Testers appreciated the ability to set a topic for the caller / questions panel as a tool to keep the conversation relevant.

  • 3/5 Testers said the floating Caller prompt in “Audience caller active” screen was nice-to-have UX. It would show the audience what the conversation is referring to.

What could be improved

  • 2/5 Testers thought broadcast setup could be faster and done in fewer steps. This feedback was valuable to explore.

  • 4/5 Testers liked the audience question & caller feature, but thought it might not be clear that accepting a question would add the listener to the audio stream.

  • 3/5 Testers suggested to decouple Questions and Callers as two separate features. This way, a listener can post a question / prompt without joining the audio stream. This made a lot of usability sense.

  • 3/5 Testers noticed the bottom nav bar, and asked what it was for during the broadcast. This wasn’t determined during V1 yet, but it likely doesn’t even need to be there. That way, the entire screen will be dedicated solely to the broadcast with no distractions or unnecessary nav tools.

  • 2/5 Testers suggested to add “Mute Caller” to the Caller panel for easier access.

Go Live & Audacy listener app mapping

We determined that Go Live should be a standalone app only accessible to invited radio hosts, and not within the Audacy consumer app. This was due to it’s unique feature set, permission requirements, and existing backend structure of the Audacy consumer environment.

This flow represents the relationship between what would happen when a host initiated a broadcast within Go Live, and what would be displayed to Audacy users when the broadcast is available.

Additional scope & features based on user feedback

“Green room”

Our hosts expressed a desire for a pre-broadcast space where they can chat among each other before going live to the greater audience. This could be essential for use cases that involved special guests, ensuring everyone was aligned on the format of the conversation flow, audio sounded good, etc.

Unauthenticated guest invites

If the Go Live app was going to be invite-only and special guests were to join one-off sessions, there needed to be a secondary web-based version of Go Live that would allow guest speakers to enter via unique invite codes.

Sharing sessions

For engagement and visibility, hosts and users should be able to share a broadcast session to their friends. This could help Audacy gain new users and expand the size of the audience.

v4 Wireframe testing

Overall there were 4 major rounds of wireframe testing and iterations before the designs reached high-fidelity. Determining scope for the ideal state, MVP, and learning about technical capabilities (and limitations) was an on-going process. Working closely with the product team, engineering, and future users was integral in ensuring a functional and valuable experience.

User test plan & tasks

During the remaining testing phases, we ran a series of moderated, task-oriented activities to receive feedback on the usability and value of the core features. Working with 3 radio personalities as advisors and 2 stakeholders on an on-going basis for this project.

pre-broadcast flows

  1. Initial channel setup

  2. Initiating impromptus session and scheduled sessions

  3. Sending invites to co-hosts and guest speakers

  4. Validating the importance of the pre-broadcast “greenroom” space

interactions & activity

  1. Toggling between activity and chat views

  2. Accessing the audience questions panel, answering & deleting items

  3. Moderating chat (removing comments, banning from chat)

audience callers

  1. Accessing caller requests

  2. Accepting / Denying callers

  3. Removing callers from session

  4. Enabling / Disabling caller requests in the broadcast session

ad breaks

  1. Accessing ad break panel

  2. Setting ad break duration

  3. Viewing the remaining time of an ad break

  4. Mute / Unmute logic & expectations upon completion of an ad break

v4 user test feedback

What worked

  1. Testers saw value in scheduling broadcasts and inviting co-hosts in advance. They said it would be easy to advertise them, and could be great for interviews with celebs or fireside chats.

  2. Radio hosts love speaking with callers as it brings them closer to their community, so they were excited about multiple callers in one broadcast.

  3. It was important for hosts to easily remove callers as quickly as possible in the event of trolling or hate speech.

  4. Testers liked the audience questions feature, especially if they wanted to disable audience call requests while still allowing a layer of audience engagement.

  5. Testers loved the greenroom feature and saw it as a very useful feature to get prepped with their cohosts and guest speakers before going live.

What needed considering

  1. Testers were hesitant to manage chat themselves, understandably they saw this as too many tasks and pressure.

  2. A few testers were confused about the close button in the top-right corner and weren’t sure of it’s functionality. “Will it close the UI or does it end the stream? Does it make me leave the stream?”

  3. Testers wanted a private chat panel for hosts and co-hosts in addition to the audience chat panel. There needed a clear distinction between the 2 chats.

  4. Testers must have the ability to mute and unmute guest callers, overriding their mic control. This was very important to the host experience.

  5. Testers wanted an option to go live as an individual (themselves) or as their radio show entity.

Microphone access for guest callers logic

We also had to refine and communicate the logic behind muting and unmuting guest callers, as well as the overall acceptance process when audience call requests come in. In order to determine the nuances of mic access, I provided the team with a flow after a few brainstorming sessions. Once we agreed on the logic, this flow was provided to the tech vendor as well as our in-house engineers for intake.

What an Audacy Listener would see

We planned to test out various positions and screens where the Go Live module would be accessed from. In this sample, the module appears on the Audacy listener’s For You Page. This page is populated with stations the user has listened to previously, local stations, and recommendations.

Unauthenticated guest views

As mentioned earlier, there had to be a way for special guests to join broadcasts without creating an account on the Go Live app. To accomplish this, designs were provided where the hosts could share a unique room code. The guest would go to the web version of Go Live to input the code and join.

Green Room

Here are the high-fidelity designs for some of the main Green Room screen states, including a view for an invited host and private chat.

Feature priority matrix

During this process I worked with the team to estimate the effort levels of core features, as well as additional features we’ve talked about. We needed to align on our “nice to haves”, our MVP, and the Beta test to develop prior to rolling out more robust functionality.

This product relied heavily on our vendor’s audio tech and syncing with Audacy radio databases, therefore the Beta environment would include a lean set of tools.

Scaling back for Beta

As features and scope were added to offer a robust long-term app experience, our engineering team was ready to develop and product test a functional app with a small group of hosts, live to the Audacy audience. The beta test would focus on audio quality, basic audience and host interactions, connectivity, and contextual use of the platform.

Features included in beta

  1. Going live as a Show entity, with hosts automatically added to a stream

  2. Audience caller interactions & crowd management

  3. Audience questions

  4. Public and Private Chat (moderated automatically using AI technology and reputation scores)

  5. Broadcast sharing

  6. Broadcast replay stability of finished sessions

Features excluded from beta

  1. Unauthenticated guest access

  2. Ad breaks (this ended up being more complicated than we thought)

  3. Green Room (needed more backend work due to linear stream logic)

  4. Going live as an individual (due to access permissions, decoupling individuals from a show entity required extra engineering time)

  5. Scheduling broadcasts, slotted in for future releases.

Beta test findings and product observations

audio quality inconsistencies

The audio quality was usually amazing, but got choppy or drop sometimes and the host had to start a new broadcast. This was not due to a poor connection, so engineers had to figure out why this was happening.

visual audio level metering needed

Hosts wanted to see their audio levels in the interface to ensure they weren’t too quiet or that the audio wasn’t clipping. The vendor tech did a great job in background noise suppression. However sometimes the hosts were too far or too close to their mic.

ad breaks for monetization were necessary

We knew new forms of audience engagement and getting more listeners on our platform would help increase revenue for Audacy. However, this project was more expensive than expected, so Ad Breaks would have helped increase ROI. The radio industry runs on ad revenue.

limited audience and not enough listeners

Listenership was fairly low at first due to limited advertising of the feature, and only a few stations were enabled for Go Live during beta testing. However, the Audacy listeners who did join were engaged and excited about Go Live.

would Go Live include video streaming?

That was a long-term plan for Go Live. Live audio is great, but the ability for video streaming is even better. It was too pricy for the organization at the time, however that was the end-goal. The hope was to include video streaming after a year or two.

interactions with the audience

The caller interactions worked well, and as long as users had their mic permissions turned on, the experience was smooth and reliable. The interactions of muting/unmuting callers as well as removing them was easy to use.

new items of interest not shown in UI

Hosts wanted an easy way to see if new calls or questions have been posted without having to open the menus. A numbered “bug” was added to the bottom nav bar during the first beta fast-follow.

missing features from beta limited the usefulness

Hosts were eager for the features they saw during design testing that didn’t make into the Beta version. They really wanted the Green Room and Unauthenticated Guest invites, as well as Scheduled Broadcasts.

ticketed events and exclusive members-only streams

Audacy was planning on rolling out a paid subscription with some really nice premium features. Another way to monetize Go Live could be members-only scheduled broadcasts. Stuff like intimate conversations with celebrities and sports stars, or early access music listening parties.

What happened next?

Go Live was in beta testing for a few months, during which, improvements and updates on the app were being made. The user base was slowly growing and gaining some traction. Then, the app was abruptly sunset by the organization following a company restructuring.

Why did this happen? The organization was hit by the recession and revenue greatly suffered overall. Costs of developing Go Live were increasing, and the features that would increase ROI for Go Live were going to be a monetary commitment.

As unfortunate as this was, companies have to pivot during uncertain times. Maybe someday it will return.

Next

Audacy User Onboarding