Podcasts for the people! Designing a social network for Deezer
Our first group project on General Assembly’s UX Design Immersive course found us in a two-week sprint, imagining a prototype social media function that could be incorporated into the global music and podcasting giant Deezer.
The brief was to build a social network and discussion around podcasts into their platform. It had to do the following:
- Users should be able to comment on and discuss podcasts or podcast episodes with people in their networks
- Users should be able to find people with similar tastes to them
- Should users see everyone’s comments, or just those in their network? Should those be differentiated at all, and if so, how?
It was left up to our four-person group as to whether we wanted to focus on the web or app side of the experience — a key point of focus for our research.
Our group used the double-diamond approach, splitting the sprint into four phases — discover, define, develop, deliver.
Discovery: Our podcast habits
Our competitive analysis examined both podcast platforms — Apple Podcasts and Spotify — as well as indirect competitors with a strong community aspect: Instagram, Soundcloud and Discord. As well as being able to comment and react to podcasts, we decided our users should be able to share and recommend podcasts within the parameters of their community.
Much of my focus on the project was on the research side. I devised a 12-question survey on the subject of podcasting and social media. We got in excess of 100 responses by leveraging our immediate networks, the General Assembly London cohort and members of Reddit’s Sample Size community. The survey revealed that a majority of respondees enjoyed discussing media they consumed with others (58% choosing ‘I like it’ or ‘I love it’); and that respondees felt that the best recommendations came from friends and family (35%) rather than other sources.
Our group also conducted 15 interviews with podcast listeners active on social media, grouping key insights into an affinity map.
Using our affinity map, I distilled four key points.
Discovering good podcasts is difficult. Algorithms are hit and miss, and podcasts can be really long. It takes a while to decide if you’re into it.
Online communities can be unpleasant places. Who are all these people, and why are they telling me their opinions? Some people lurk — a lot of us just don’t go there.
Listening to podcasts is a secondary activity. You do it while doing something else — cooking, jogging, cycling, dozing. (Our brief gave us the option of designing for desktop, tablet or mobile — this is the point we knew this had to be a mobile app.)
Podcasts are personal. No wonder, really, that algorithms can’t give us what we want.
Definition: What podcast listeners want
To refine our learnings, we began synthesising our research using a number of UX techniques. First, the persona — please meet Natalia.
We also created the following problem statement:
Natalia wants to connect with others around podcasts because she’s lacking inspiration and she knows the best recommendations come from people of like mind
Then, we created the following How Might We’s, a UX technique used to inspire and provide focus for our sketching work.
How might we…
…make a curated list of recommended podcasts for Natalia based on her tastes?
…connect Natalia with family and friends to share and get podcast recommendations?
…create a safe place for users to share and discuss podcasts?
As we were working remotely, we conducted our Design Studio individually at home and shared our sketching in a shared Miro canvas, voting on our favourites using coloured dots.
Finally, we created a user journey with a “Happy Path” that squared the wants and needs of our persona with the questions laid out in the brief. Natalia receives a notification that a friend has posted in her private Deezer discussion group; she joins the thread, and listens to a clip of a podcast that a friend has highlighted via timecode and shared with her; enjoying it, she checks out the full podcast episode, leaving a comment below; and finally, she returns to the private discussion group to let her friends know her thoughts.
Development: Designing and iterating
While many of our earlier General Assembly projects found us building a brand from the ground up, this project posed a different problem: the work we created needed to fit neatly into a set of tightly pre-defined brand guidelines.
For this, we had an invaluable resource in DeezerBrand.com — a website that hosted all of Deezer’s so-called “brand DNA” in one place — from free-to-download fonts and colour palettes to a media library and steer on imagery and tone of voice.
Following several rounds of user feedback at the lo-fi and mid-fi stage, we implemented a number of iterations.
Notifications. After experimenting with icon and placement, we positioned this in the top right of Deezer’s interface, accessible from the ‘Shows’ page.
Activity feed. User feedback suggested it was taking too many clicks to get to the chats page, so we decided to lose this step altogether.
Pop-up podcast clips. Users found this distracting, so we redesigned, giving users the ability to listen to podcast clips within the message itself.
Sizing and hierarchy. We made a number of cosmetic changes, enlarging text and box size to make the best use of screen real estate and aid accessibility.
I also used the Deezer brand DNA to create some clear onboarding pages describing our new features. Check out three of the screens below.
Delivery: The final prototype
Above you can see a minute-long walkthrough of the finished prototype on Invision.
Below, you can see four screens from our final prototype, showing how the community icon is integrated into the existing app frontpage, and showing off the comment and group chat functionality.
As an MVP, we delivered the following features:
- Users can comment on podcast episodes, using threaded comments
- Users can create private group chats
- Users can share timecoded segments of podcasts into their group chats
Next steps
User testing. In particular, the ability to share a timecoded podcast clip with friends is a fresh idea, and not one we’ve seen elsewhere — would users take to it? It’d be interesting to test this out using Wizard Of Oz techniques to see if the concept works with users.
Activity feed. We removed this entirely while iterating, but an activity feed might be something to add back in and test later, as a means of alerting users to new podcast episodes, replies, recommendations, etc.
More features. Allow users to select favoured topics as part of onboarding. Allow listeners to create podcast ‘listening parties’. Allow listeners to create podcast playlists and share with friends.
Key learnings
Our group project threw up two key learnings about collaborative work.
Consider the right tools. A four-person team, all working in Sketch can provide organisation challenges, with a lot of versions floating around — my teammate Dana stepped up to distribute and keep track of files in one centralised folder, but a tool like Figma which allows for group work might have been a better choice.
Think bold to navigate blockers. We spent too long theorising around ways to make the activity feed work, even though user testing clearly revealed it added unnecessary steps to the user flow. After a lot of prevarication, I suggested we remove it entirely, and suddenly the flow worked a lot smoother — definitely one of ‘Why didn’t I suggest that earlier?’ moments.
Thanks for reading. If you want to talk to me about this project or anything else, you can find me on LinkedIn.
