The music industry has been transformed since Spotify was founded in 2008. Music streaming has become so successful that many people wouldn’t even consider owning a physical format of music.

For some—aside from live events—the entire experience of music is online.

So when Spotify started beta testing a new feature called ‘Group Sessions’, which lets friends listen to music together remotely, I expected their UX to be world-class.

But is it? Well, let’s take a look.

Note: if you don’t have time to read the full article, there’s a summary of UX tips at the end.

Tip: Try using the arrows on your keyboard to navigate the slides.

Although they’re often confused, there are two types of ‘name’ for your users:

Username: typically unique, and references a specific user.

Display name: friendlier and can be anything, such as ‘James’.

And there’s no better place to demonstrate the importance of this distinction than Twitter.

Only one account can have the handle @jack, but many people on Twitter can have their display name as ‘Jack’.

Display names serve an important function: they allow for personalised experiences within large databases, without the incumbency of everything being unique.

For example, the version on the right is better because it’s immediately recognisable as a real person.

Yet, if you connect to Spotify through Facebook, then you’re arbitrarily assigned a display name—which is my case was a random 11 digit number.

Spotify would improve their UX by prompting the user to change their display name to something more genuine before creating a Group Session.

1: It’s a task that only needs to be done once, ever.

2: Avoids any confusion over who ‘11142311180‘ is.

3: Creates a more ‘real’ and personalised Group Sessions experience.

Imagine if every time you clicked on a link, it opened in a new tab, but didn’t then set that tab as active. i.e., you had to then click into that tab.

It’d be infuriating to use, and is a brilliant example of a subtle UX trick that turns a 2-step process into a single action.

This works because browsers have correctly assumed that if someone opens a new tab, they probably also want to be on that new tab.

Or rather: they’re confident that they know what your next action would be (going on that tab), and so they just do that for you.

And Spotify nail this technique when copying a ‘Session’ link to share with your friends.

They’ve combined the actions of copying a link, and clicking to go back into the group lobby.

The result is a pretty seamless and uninterrupted experience, which works because they understand that once their users complete Action A, they’re incredibly likely to want to do Action B.

Tip: Don’t just assume what your users will want to do. Instead, look at the data. If less than 80% of your users complete both actions in perfect succession, you should probably leave them as two separate steps.

As soon as you’ve clicked on someone else’s link, you’re faced with a decision: how do you want to connect to this session?

These are totally different group experiences. So you’d hope that the selection screen is primed with enough context about each option, that you can comfortably make a decision.

But unfortunately, it’s not.

It’s practically a law of UX: if you’re asking the user to make a decision, give them enough information to actually be able to decide without the fear that they chose the wrong option.

And Spotify could do this fairly easily, with a few additional lines of text.

There are many approaches to onboarding, but let’s look at two:

Clearly, sometimes you need to onboard users before they do something—to explain the consequences of an action.

But, if you’ve got a product with lots of functionality, it’s often not appropriate to attempt to onboard every possible action or feature. 

Another technique is reactive onboarding: explaining why something just happened.

And—unless they add more proactive onboarding—this is the bare minimum of what Spotify should be doing while people are using the Group Sessions feature.

To be specific, any participant can pause, skip and play songs, for everyone in the group. And yet, it neither explains how this works in advance, nor does it explain what’s just happened.

So by adding a simple notification when another member of the group takes one of these actions, it’d do a few things:

1: It teaches the user that anybody can take control.

2: It clarifies why the music has stopped / skipped.

This case study took me ~40 hours to put together. If you’ve enjoyed it, please head over to Product Hunt and give me some feedback.

It’s absolutely the best way that you can support Built for Mars right now, thanks.

*Product Hunt is an amazing community of people who love start-ups and internet products.

Here’s what we’ve covered:

1: There is a difference between usernames and display names, and they have different use cases.

2: You can often combine steps to remove unnecessary actions.

3: Make sure that your users have enough information to comfortably make a decision without the fear that they chose the wrong option.

4: Consider using ‘reactive onboarding’ to ensure that your users know why something just happened.

And that’s it, head over to Product Hunt and let me know what you think!