Deezer | A UX Case study
Concept project | 2 week sprint | 4 UX Designers
The last two weeks have been the first opportunity we have had at General Assembly to work in a group. This filled me with excitement but also trepidation. 4 brains are better than 1 right? Yet, I still had concerns:
How were we going to tap into each of our strengths? How would we empower each other? How would we make sure everyone’s voice was heard?
In the ‘real world’, you will ideally be working in a team with a senior UX Designer who would ideally guide the process and keep us all on the right track. We didn’t have that. So we recognised early on that we would have to write up some ground rules to keep us all focused and to make sure that all voices were heard. With the ground rules drawn up, we entered into the world of group work.
Dissecting the brief
We realised early on that our brief was complex. To help us make sense of it, we mapped it out using a project canvas. Doing this enabled us to visualise our project and develop a shared vision. These were the main insights that emerged:
- Deezer’s current offering lacks the human touch of a real curator
- They would like to allow their users to upload their own content
- This, they hope, will create an engaged community of listeners and creators
So, it became clear we were serving two users: listeners and creators.
Understanding our competitors
Conducting a competitive analysis allowed us to see what our competitors were doing; what they are doing well, what they are not doing so well and what features our users will expect.
We focused on 3 main groups of competitors: apps whose main offering was music, those whose main offering were podcasts and indirect competitors. Our main insights were:
- Music apps tend to have more content and features than podcast apps
- Sharing and recommendation features were strong across all platforms
It could be assumed that our users would expect to be able to share and recommend music they enjoy. We would also offer creators the opportunity to upload their content which would in turn be accessed by our listeners, enabling them to enjoy curated content chosen by them, not the platform algorithms. Our project was starting to take shape. But before we started sketching some ideas, we (arguably) had the most important part of the UX design process to conduct: User Research.
Understanding our users
To improve Deezer’s product for their users and potential users, it was essential to get under their skin; what is important to them, what are their needs and frustrations?
We conducted some in depth user interviews. We managed to interview 6 listeners and 6 creators and gathered lots of juicy qualitative data that we had to make sense of.
Enter, affinity mapping:
Affinity mapping allowed us to gather all our interview findings in one place and to identify trends and patterns in the research. With two users this was no easy task. But trends and patterns immediately become obvious, and we were able to draw some insights.
Problems & Opportunities
Creators
- Some expressed frustration at the complicated uploading software that they currently used
- They were highly suspicious of the big music platform’s curation process, confirming Deezer’s acknowledgement that their current algorithms do not suit all their users.
- They wanted recognition of their work, but felt they were competing with professionals and big names in music
“At the moment the current uploading software is far to complex, it puts me off” — Creator
Listeners
- They enjoyed feeling connected with a community; being able to share and to get recommendations from friends was a big part of this
- Discovering new music and/or podcasts was highly enjoyable
- But, like creators, they were distrustful of how the recommendation algorithms worked
“ Who decides what I like?” — Listener
Meet Heidi. She’s a persona — a synthesis of our users, which we created to help us to keep in sight the goals and frustrations of our user. She wants to feel in control of her music and brand, and not at the mercy of a faceless platform. She gets frustrated with overly complicated systems, so wants to be able to record and upload content easily and quickly for listeners such as…
Alfie, our listener. Alfie hates predictability and he finds playlists repetitive. He loves seeing what his friends are listening to and being connected to a community. But like Heidi, he doesn’t trust the algorithms— ‘Who are the curators?’
To focus on their core issues, we created problem statements for them both:
Heidi needs a way to get exposure because she wants more people to know about her shows
Alfie needs a way to discover niche and interesting new music shows because he doesn’t trust the algorithms of the big music platforms.
Design Studio
With these in mind, we held a design studio to help us to explore a wide range of ideas and create a shared vision in order to move forward.
Our Solution
The solutions to the problems of the creator and listener that emerged from the design studio were as followed:
- Creator Mode: A new feature for creators that allows them to record, upload and manage their content in a simple, streamlined way.
- Explore Feature: A new explore feature — the place for discovering new talent, made for the users, curated by your community and bypassing the algorithms.
- A New Way of Sharing Content: Our users will be able to save music privately and like music publicly, endorsing artists and showcasing them to their community.
Information Architecture
In order to visualise the information architecture of the site, we looked at Deezer’s current sitemap:
How would our new features sit within Deezer’s current app? We created a proposed sitemap:
Prototyping and Iterating
We iteratively increased the fidelity of the sketches, moving from paper prototype through to high-fidelity. Creating InVision prototypes allowed us to demo the experience and bring it to life, and we gave our users a scenario and several tasks to complete during usability testing.
We tested 18 users throughout the process — these gave us some interesting insights and enabled us to iterate with the user in mind. I will talk you through a few of them here.
Listener Mode
We mapped out the steps Alfie would take to achieve his goal of finding new niche music shows and sharing this discovery with his community on Deezer. This allowed us to understand which pages would be involved and at what step.
Listener Mode Iterations
In keeping with our users’ needs, we implemented a feature that would allow users to show their support to artists, meaning less well-known artists could be more easily discovered, and users could see what their friends have liked. Users could tap two buttons:
- A badge icon that would publicly show their community that they like the song
- A heart icon that would save the song privately
However, usability testing revealed that these icons were not intuitive for the user.
“I’m not sure if I can distinguish between the like and the badge button”
To solve this issue, we conducted A/B testing to find out what these icons meant to people.
Our key learning were:
- Although most users were clear that the megaphone icon had a public liking element, the heart icon has similar connotations so as a pair it didn’t work.
- Most users were very familiar with the heart and save icon and the relationship between them.
Moving forward, it was decided that the heart and the save icons would be used.
“I can see this button will save my music privately, and the like button will be public like on Instagram”
Creator Mode
We proposed that the new Creator’s area would be accessed by changing from one mode to another via a switch, for example, from ‘Explore Mode’ into the ‘Creators Mode’.
We mapped out how this may sit within the existing app:
Creator Mode Iterations
In keeping with the users needs, we implemented a feature that would allow users to upload and record content — a creator mode.
The creator mode feature changed the look and functionality of the navigation bar, but usability testing revealed that this was confusing for users.
This indicated to us that with so much change, the users would need a thorough onboarding process, to help get to grips with the new features and navigation bar.
Final Prototype
At the end of the 2 week sprint, we had produced a high-fidelity mock up of our design as well as a clickable prototype in InVision to bring it to life.
Click here to see the final prototype.
Reflections and Learnings
Interviews and Testing with Deezer users — as a concept project, we didn’t have access to current users of Deezers app (although we attempted to tap into their user base via a screener survey). In order to understand Deezer user’s pain points and to make something truely fitting to their needs, we ideally would have interviewed and tested with Deezer users as they would have given us insights we didn’t necessarily get with users of different music apps.
Don’t over complicate — given this was a 2 week sprint, we were limited to what we could accomplish. Our brief was complex and we interpreted it as serving two users; a listener and a creator. In hindsight, perhaps concentrating on one user would have allowed us to really delve deep into solving that user’s needs.
