Native iOS & Android App

How might we design a jukebox that always plays the right song?

Rockbot is a music streaming service for businesses to manage custom playlists and license their background music. A growing number of restaurant chains, bars, retail shops, exercise gym chains and other businesses were subscribing to Rockbot's background music service to play music for their customers.

The company was more than a background music service for businesses. End consumers could download an app to check-in to the location in order to vote on the music queue and make their own song requests.

At first the company appealed to small and medium businesses. The consumer app was designed with these businesses in mind. Things worked out well and the company was growing fast.

But as the company grew we began to attract much larger corporate restaurants, gyms and retail chains. These businesses had different needs and wanted much more curated music.

Rockbot had over 16million licensed songs. Many of the companies first customers made many thousands of these songs available. But the new corporate chains would often only have several hundred songs available for request.

The team wanted to improve the customer experience for a new context. One without many music choices.

Rockbot, 2016

Why this problem?

What we learned from the data

New businesses had request libraries that were up to 10x smaller than some of our first customers.

The number of downloads per day and per venue were still very high and at peak levels. But most people weren't using the app. Of all the new downloads only 80% of the new accounts used the app to interact with the music. People were taking all the time to create an account but then not using the app. 

Pain points

There were a number of pain points for users as request libraries at venues become much smaller.

People were searching for music and not getting results.

When browsing the available request library at a venue, the app used a listview to organize songs by music genre. But with much smaller libraries this design pattern was difficult to use. Song categories only had one or two songs.

Opportunity

Our new self-onboarding trial flow was a success and we were signing up many new free trials, but we were worried that businesses might not convert if they weren't satisfied with the song request experience.  At first glance, there didn't seem to be any problems with the song request app.  The feature was a popular selling point for businesses and the overall number of song requests per venue was very high.  But, with a deeper look a few problems became clear.   Most requests came from one or two regular customers at each venue and others didn't seem to be engaged. 

Discovery & Research

Overall, the app downloads numbers were very high, but most people never took the first step of making a song request.  Why would customers go to all of the trouble of downloading the app and then give up before requesting a song? 

Without digging deeper, it was hard to know whether they weren't finding a good song to play, the price of a song request was too high, or there was something else we were missing.  Of course, there are many different types of customers with different interests and motivations.  So it was likely that we had many small issues to address.  

In my user research sessions, I saw that new customers who downloaded the app weren't browsing the library of permitted songs as expected and were going right to search for a favorite song.  Because businesses deliberately limited the user request library, this favorite song usually wasn't available and made for a disappointing first user experience.  Customers also complained the cost of a song request was too high, but it was hard to say if they would be willing to pay if they had a better experience finding the right song. 

There was also this dynamic of a few regular customers who were big spenders and made the majority of song requests.  We saw this in the numbers and learned more from user research in the field.  It seemed like this type of use might be discouraging others from participating and was possibly bringing down the quality of the music overall.

Scope: 6 weeks to build a new interaction & onboarding flow to the native iOS & Android app.

Role: I led product design as an individual contributor.  I led design thinking workshops and user research.

Team: I worked as designer and PM with 3 developers.

Type: UX, task flows, user research, personas, prototyping, wireframes, mockups.

Tools: Sketch, InVision, Keynote.

Mocks for shuffle picks, a new music request tupe.

Defining the problem

A few of us thought there was an opportunity to appeal to more than just a few power users at each venue. Our business customers would be pleased with a broader group of customers making requests and less likely to cancel.  If song requests were distributed among more customers, we hypothesized that customers would generally be more pleased with the background music and rate it higher than when a few people were making all the song picks. 

If we could come up with a way to make song requests less frustrating and expensive, more customers might start to request songs. If we could get customers to pick a few songs right after downloading the app, we might be able to engage them on return visits using notifications.


The marketing, sales, customer success, and product team were aligned on this problem, but we didn’t know exactly how to do it or whether we could pull it off. 

Cross Team Alignment 

This was more than a UI problem.  The problem space was complicated and related to important business decisions.  For instance— the pricing model and how much to charge for a song request.  There was also an issue of multiple stakeholder conflicts, especially between small business owners and thier customers who used the request app.  Their customers wanted a permissive request library, but there was also a businesses interest in selective background music with curated playlists. 

To get unstuck, I reached out to the CTO and we hashed a plan to get leadership and key players from all of the teams together.  I also had some help from my design mentors at Google Ventures (an early funder of Rockbot), who got me started trying out their work in progress Design Sprint techniques.  After that, I led the company through a 5-day design sprint that helped us align on the problem we were trying to solve.  

We decided on a few ideas that could make a big difference.  First, we decided to design a structured flow that helped new customers request songs.  Ideally, we would include some free picks in this onboarding flow and promise the same with each check-in on return visits.  Second, we wanted to help our first-time customers avoid the potential dead end of searching for a favorite song and wanted to offer song category picks— for instance, a customer could pick a favorite artist or type of music and make a randomized pick.  We decided to call this song request type a shuffle pick.  Because of the particulars of our licensing agreements, the company was able to offer a few shuffle picks for free with every check-in.  After that, shuffle picks were offered for much less than song requests.

If we could figure out a structured flow for customers to make free shuffle picks each time they checked in, we could get many more customers to use the feature at each venue.  We set a goal to increase the number customers who made a song request within 10 minutes of downloading the app by 10x.  As a result, we wanted to expand the number of returning, regular customers at each venue by 3x.  

Sketches for marketing collateral to promote the request app with free plays.

Planning

Now that the company was aligned on an important problem.  I got right down to work on prototyping some of the ideas from the design sprint.  In the first week, I dialed-down the fidelity and lead a few different sketching session with the CTO and key people from product team.  We got product involved early in order to support discussion of implementation details, edge cases, and tradeoffs so that we could make important decisions about how to allocate developer resources and whether or not it would pay off to schedule extra time to refactor.   

At the same time, I used the sketches to work with sales, biz dev, and customer success teams in order to construct a shared understanding of what we wanted to build and how it related to key outcomes that would drive user engagement and support the sales team in driving business growth. That way, they could better communicate the upcoming changes to customers and our sales leads and flag any concerns they might have about the change.

On a previous project, I already established a pipeline for semi-weekly user testing in the field.  For this project, I decided to switch this up so that a few recruits would come in the office once each week.  That way interruptions would be minimal and we could stay heads-down on prototyping and implementation details for the next few weeks.

Early wireframes for a new song request interaction that allowed a customer to make a randomized pick of an artist or other playlist.

Mockups with edge cases for the iOS app.

Screenshots of prototype used for user acceptance testing of new song request type.

Implementation

I spent the second and third week pairing with one of the iOS developers to iterate quickly in tight loops and and led external & internal feedback sessions and user tests & interviews via invision prototypes and test-flight app releases of work in progress.  I began to flesh out implementation details with the team and further identify edge cases.  At the same time, I worked to support alignment across teams, gathered feedback, and looped back with the developer to further iterate based on what we learned.  It was a busy few weeks, but moral was high overall and the team was focused on a clear goal.

As the team became aligned on the implementation details and the scope of work & timeframe became easier to estimate.  I led a small team to polish up the rough edges and began to prototype some animations and transitions using keynote and invision. I worked with a 2nd developer to quickly implement transitions & animations in the ios and separately looped in the android app developer so we could work on both the animations and the follow-up implementation of the ios build.  Meanwhile, with the first developer I continued to iterate in tight loops, until 100% of the users we tested (both new recruits and loyal regulars) made 3 or more music picks within 5 minutes.

After that, I spent the fourth and fifth week pairing with one of the iOS developers to iterate quickly in tight loops and and led led external & internal feedback sessions via invision prototypes and test-flight app releases of work in progress to flesh out implementation details, further identify edge cases, and  support alignment across teams as I looped back with the developer to further iterate based on what we learned.

To play it safe in rolling out the new features and help communicate the idea to stakeholders I designed on-boarding cards for the first user experience with the new feature.  As it turned out, we learned in user tests that the hinting and motion affordances we built into the update during design polish was obvious enough and these on-boarding tutorial cards were not needed.

Wireframes for onboarding cards for the first user experience.

Motion prototype for animations and transitions to support browse and search (0:36 min).

Outcome

In a/b tests of the new flow as we we noticed a few big changes.  As expected, many more customers— 6x as many— were making three or more song requests after downloading the app for the first time.  In some ways this wasn't surprising.  This was the metric we targeted in prototype iterations.  As we rolled out the app update, we noticed some unexpected results.  With more people using the app, the number of votes per venue increased by 8x.  The number of engaged users (signed in and using the app in any way) increased by 3x overall.  

This increase in engagement helped us scale up by increasing the number of active locations by 20% month over month from a handful of demo venues in SOMA and North Beach to multi-location chains all over the country such as Panera and Buffalo Wild Wings.

Later on, we continued to build on the idea of an easy, randomized favorite song request with check-in and created the Rockbot Anthem feature which utilized Bluetooth beacon technology so that customers could add a favorite song to the queue simply by walking in the door.

In hindsight there were a few things we could have done differently.  The issue of stakeholder conflict wasn't completly resolved and in going through recent app reviews a few years later, it appears to remain a problem.  It might have been better to address this while we had the focus.  Also, we avoided the problem with search by building a new UI layer on top of it.  There was an opportunity to get search right but it would require more product thinking or some difficult tradeoffs.  These two UI layers created a bit of design and technical debt that would need to be cleaned up later. 

Later we used bluetooth beacons to auto-request a favorite song as a customer walked in to the venue. View article.

More Case Studies