LocalPod

An Alexa Skill to obtain bespoke local podcast recommendations

Overview

What is LocalPod?

LocalPod is my capstone design for Thinkful, my UX/UI Bootcamp. I decided upon the brief for myself, which was to design  a way for users to:

The Problem

The problem I wanted to tackle here was threefold:

The Solution

View Clickable Prototype

I developed an MVP prototype that allowed users to seek local podcast recommendations by:

  • Running through a Q&A to select their preferred tone, form, format, and topic
  • Asking for a local podcast similar to one they already like
  • Providing their preferred tone and topic (i.e. "funny news podcast")

My Role

UX Research

  • Survey
  • Ethnographic Study
  • User Personas
  • Wizard of Oz Testing
  • Usability Testing

UX Design

  • Data Set Creation
  • Data Set Curation
  • Defining Slots
  • Prototype

UI Design

  • Dialog Flow
  • Prototype
  • Logo Design

The Process

The Basics of Voice Design

The first thing I had to do for this project was teach myself the basics of a voice design process. I met with a professional voice and conversational designer to understand the basics of a voice command, which is composed of 3 parts:

INTENT

What the user wants to do. This can be either a low utility (like getting a podcast recommendation) or high utility (like turning on lights) interaction.

UTTERANCE

How the user phrases their request. Users will come from different backgrounds and, as a result, will use diffferent words or phrases with the same intent.

OBJECTIVE

Sometimes an intent alone is not enough (like "order me coffee). Slots are like traditional form fields: they can be optional (what syrup) or required (what size).

My First Problem Statement

Here's the thing. I lied to you before. This project didn't start out as a local podcast recommendation concept. I actually started out with a completely different idea:

How could I design a way for users to discover new podcasts through the means they’ve had success with in the past without having to touch a thing?

Why did it change? We'll get into that later. But with that problem statement in mind, I wanted to know...

What do the Listeners Have to Say?

I sent out a survey to 14 podcast listeners to verify that the assumptions I was making in my problem statement.

First, I was able to verify that, be it doing their chores or commuting, users are typically multitasking while they listen to podcasts.

Next, I verified that podcast listeners were interested in discovering new content. 100% of listeners were either definitively interested or open to the idea.

Lastly, I pulled my survey data on habits while listening to podcasts and means of discovering new podcasts into a matrix to prioritize the most likely use cases for my MVP.

Who Would I Be Designing For?

Smart Speaker Owners

When I pulled national smart speaker ownership data, it was clear to me that I should be designing primarily for users between the ages of 18 and 44.

Podcast Listeners

Combining that with the most recent data on podcast listener demographics, I was looking at an almost even split between men and women. In addition, I learned that:

Podcast Listeners

51%

of U.S. residents have listened to a podcast (odds were pretty good that smart speaker owners also listen to podcasts)

49%

of podcast listening is done at home (where smart speakers would be)

80%

of listeners listen to all or most of an episode-podcast listeners are loyal.

What Would I Be Designing For?

The next big question was, which voice assistant should I design for?

One glance at the demographic data showed me that Amazon's Alexa was the clear winner. Now it was time to learn more about Alexa users.

What Does a Typical Alexa User Do?

Now that I knew who and what I would be designing for, the next crucial step in my data-gathering was determining what a typical interaction with Alexa looked like. I recruited 6 users for a brief user interview and then an ethnographic study to observe their typical intentions and utterances, and Alexa's responses to them.

With one power user as an exception, most of the users I studied used Alexa primarily for listening to music and/pr podcasts, with occasional use of her timer and weather features. When compared with national data on this smart speaker usage, this was an average sample.

The biggest takeaway from the data was the limited use of full sentences in user utterances-emphasizing the importance of designing for keywords rather than full sentences or particular sentence structures.

The Journey of an Average User

With significant data under my belt, it was time to chart the journey of a typical smart speaker user/podcast listener looking for a new podcast.

It struck me that the length of time it would take to identify a new podcast of interest was considerable in most use cases. This emphasized the importance of the word "efficient" in my problem statement.

Scoping Out the Competition

So what did the competition look like? How were they handling the need for a new podcast? I examined 3 options:

NATIVE

Alexa has a native ability to recommend podcasts to users. While at first disheartening, as I experimented with this skill, it became clear that Alexa's recommendations were exclusively tied to podcast top charts. Any users interested in finding a hidden gem were not going to be satisfied with her recommendations.

RECOMMEND ME

I next looked at a custom skill called "Recommend Me", which recommends movies to users. Again, recommendations were either random top movies, or the top movie in a category the user specified.

RECOMMEND ME A BOOK

The last skill I took a gander at was the "Recommend Me a Book" custom skill, which happily had a case study written about it to flesh out my understanding. Here again I found the same feature-recommendations from top charts, or from the top chart of the category you select.

Based on my survey data, I knew that users were rarely utilizing top charts to find new podcasts. This solidified my commitment to designing an app that could give users recommendations for podcasts in a way that they're accustomed to.

It's Thinkin' Time

It was time to brainstorm. I spent time generating ideas in a "how might we" format, collecting them into groups of possible features, and then prioritizing the features to identify what would make a true MVP.

Initial brainstorm session:

Grouping ideas into feature sets:

Prioritizing ideas by their feasability and importance:

Now I was ready to get started on the design itself....or so I thought.

The Snag

This is the part where I discovered that what I wanted to do is not currently possible with Alexa. At the time of writing, although Alexa can pull users' contact list in order to make and receive phone calls, she wouldn't be able to share data on what users' friends are listening to.

However, Alexa can share location data for an Echo device to a skill. Thus, the concept for LocalPod was born.

Is Local a Good Idea?

Now that I'd shifted my problem statement, I wanted to verify that the third part of my puzzle was accurate-that users would be interested in supporting local podcasts.

Upon pulling Google Trends data on searches for the phrases "shop local" and "support local art", it was clear that interest in supporting local artists and business owners has been steadily increasing over the years.

Google Trends data for "support local art" searches over time

Google Trends data for "shop local" searches over time

What Should it Do?

Now that I had a usable concept in place, I needed to define LocalPod's skill capabilities for an MVP. I decided on two capabilities, which would essentially handle two types of utterances:

Category & Subcategory

A user would ask for a recommendation for a local podcast by category and subcategory

Similar

A user would ask for a recommendation of a local podcast similar to one they already listen to

What Should it Sound Like?

With those capabilities in mind, I wrote sample dialogs for both utterances to begin to map out conversations between users and LocalPod.

With the big picture settled, I needed to dive into the details and create the data set.

Making the Data Set

I needed to focus my MVP on one locality and a small subset of podcasts, so I focused on Chicago, and podcasts tagged with either comedy or games. From there, I compiled a list of titles and the categories they were tagged with.

Unfortunately, it was obvious that this wasn't going to work. The categories and subcategories were somewhat redundant, and didn't allow me to filter podcasts in the way that I needed to.

I created a tagging system that would funnel podcasts down from a wide swath of recommendations to a narrower field of personalized options.

I folded the iTunes categories and subcategories into a flat hierarchy for the "topic" filter.

Re-Defining Capabilities

With my new data set, I needed another capability-a Q&A-style "quiz" that I could run users through to get them from all possibilities down to a limited few. My new capabilities were:

Quiz

A user would ask for help deciding and engage in a Q&A with LocalPod to filter through options

Tone & Topic

A user would ask for a recommendation for a local podcast by tone and topic

Similar

A user would ask for a recommendation of a local podcast similar to one they already listen to

Bringing LocalPod to Life

I started out development with a storyboard to visualize what a typical conversation with LocalPod would look like.

Going with the Flow

With visualizations in place, I was ready to create dialog flows and account for all kinds of interactions.I separated my flows into two options:

First, a flow for a first-time user, where LocalPod would immediately run them through the Q&A capability.

Second, a secondary flow for return users, which would allow them to access LocalPod's other capabilities.

With those flows in place, I engaged 3 users in Wizard of Oz testing, where I acted as LocalPod, in order to be able to separate out issues that arose from the design itself from issues that arose from code or prototyping malfunctions.

The biggest feedback from users?

Happily, one of my users also gave me verification that interest in local podcasts was real. They said,

“When I moved to Austin from New York, one of the first things I did was subscribe to Austin podcasts.”

The Prototype

In the end, I created a prototype of LocalPod in Adobe XD using their Voice Interaction and Speech Playback features.

After usability testing the prototype, the last piece in the puzzle was a definitive exit for users who weren't interested in any of the recommendations LocalPod provided.

The Presentation

Happily, my presentation went extremely well. My assessor gave me a perfect score and a glowing review, saying:

"This was hands down one of, if not the best, capstone presentations I've seen! Your storytelling was really well done, and it was obvious how you made your strategic and objective decisions."

So What Did I Learn?

Feasability Trumps All

While I did a good job verifying my initial problem statement, it would have saved me a lot of time if my next step had been to ensure that the base solution would even be technologically possible at the moment. In a constantly evolving landscape like voice design, it's crucial to understand what is currently possible before designing a pie-in-the-sky idea.

Keep it Short and Sweet

One of the biggest problems facing voice designers is the need to keep the voice assistant's script short. It is no fun to listen to a robot read to you, and that is one of the biggest obstacles to overcome in voice design in general.

Think Carefully About Categorization

A lot of voice design involves guiding users through a conversational Q&A session, filtering out possibilities for them until you find the most personalized option. This means that the data set you work with must be carefully considered from a filtering perspective before a conversation can be designed.

What Comes Next?

Next steps for LocalPod include:

More Case Studies

Interested in hearing more about my process? Want to hear about what I'm working on now?