IDAGIO is the world's best classical music streaming service, but somehow, many of its new users were installing the app, signing up, landing on the Discover (home) screen and then...not playing any music 😱. Users who play something are 76% more likely to convert, so how could we help the users who aren’t playing anything get to a playback event?
IDAGIO's Discover screen at the start of the project
We were low on resources and time, which meant planning for cross-disciplinary collaboration as much as possible. Because of this constraint, success would be measured in cold hard numbers: This wouldn’t be an A/B test, so we’d need to compare organic traffic from earlier versions.
IDAGIO doesn't use personas to understand user context, but rather behavioural archetypes. We’d identified two of these based on prior user research: The classical “aficionado” (an expert who would likely be able to recite most of the great composers' works backwards), and an "enthusiast" (a user with less knowledge of the genre but who was eager to learn). We’d be primarily designing for the enthusiast listener in this instance.
The not-so-scientific outcome to one of our behavioural archetypes workshops
My first move was some ‘on the fly’ usability testing on our Discover page – why weren't users playing anything?
Although there was a diversity of thought processes, one thing became overwhelmingly clear: Over and over again, we heard that users were paralysed by choice.
Added to this was an environmental factor: Both aficionados and enthusiasts often listened in their offices, and wanted easy playback to suit their work context. Others noted that they frequently listened while completing other tasks, confirming that ‘lean-back listening’ was popular.
I brought these findings to our developers and we began to consider how we might approach the problem:
The Discover screen is made up of a long series of slider blocks, with no variance down the length of the page. Maybe some UI updates would help users feel less overwhelmed and more prone to decision-making?
We decided that given the timeframe we were working to, and the number of stakeholders that would have to be invloved in this update, this wasn't feasable. We also wondered if it was really solving the problem.
Discover was made up of around 20 different vertical content blocks. Maybe fewer blocks would equal more decisions?
This was quickly debunked after we looked at some data – very few users actually make it past two or more scrolls of the page, so changes this far down would likely have no impact.
After some soul searching, we came to discuss IDAGIO's mood player which was the company's most successful vehicle for 'lean-back listening'. It consists of a simple circular interface where a user can pick a 'mood' from which a stream of continuous playback begins. Could we replicate this success on Discover?
IDAGIO's Mood Player
Enter a discussion around Material Design's FAB (or floating action button). Could this help replicate the decision-making success of our mood player? It would certainly stand out against the rest of the Discover UI and would be seen by all users - not just those who scrolled down the page. There was another benefit to this approach: instead of reinventing the wheel, our devs could use out-of-the-box UI and animations.
We discussed the downsides: it wouldn't translate across platforms and we'd have to be judicious with colour and animations to stay in-keeping with brand standards. It wasn't a permanent solution. Despite these misgivings, we felt it would be a good vehicle for testing an idea.
In order not to stray too far from Material Design standards, we decided to mimic the basic Speed Dial formulation of the button, and used it as an opportunity to futher test some content on our users: Each option would contain content that we perceived would appeal to each of our user segments.
After these discusssions, I tested the design on 5 users, working to a traffic-light success matrix:
The final iteration
Percentage increase to IDAGIO’s day 1 retention (% of people who come back on the first day after signing up)
This project was a big win for the Android team team. IDAGIO's Android project was build some time after its iOS one, and for a while, the team had felt like it had been playing catch up. We didn't change that overnight, but the sense of achievement and bonding we felt after this project propelled us into bigger and better things soon after which might otherwise not have been possible ☄️.
We cranked this product improvement out without many of the deliverables expected in a standard project. Thinking fast and breaking things sometimes really is the way forward.
We'd been toying with the idea of a more tailored approach across the app, but weren't sure where to start. This has already formed the basis of several other successful projects, including a wider foray into recommendations systems.
The core of the project came from the synthesis of knowledge across the team. This exercise really taught me that if I feel stuck or uninspired, I should loop back with a developer.