Nesting into Spotify

For this project, we were divided and into groups and given an opportunity/problem for an existing company. In my group’s case, it was Spotify.

“As the world’s leading social sound platform where people can find the right music for every moment, Spotify wants to expand the way users interactively share music. Spotify provides a platform for folks to create radio stations or browse through the music collections of artists, friends, and celebrities. Spotify users are able to “like” artists’ tracks, follow artists, create radio stations and playlists. Although users are able to curate their own playlists from songs they select, Spotify would like to create a feature that allows users to collaborate, DJing their select tracks with other users in real time”.

We realized our first challenge, as a group, was to ascertain how people interact with Spotify, and what the term “DJ” meant to them. [INSERT IMAGE OF GROUP DISCUSSION HERE]

Through our user interviews, we found that people found music primarily through one of two ways: Spotify’s Recommendation algorithms and by sharing directly with friends, usually in person or through links. When we asked users what DJing meant to them, we found they responded one of two ways:

A. The process of playing one song after another at a social gathering.

B. The person who selects and controls the songs being played; usually a professional.

We found that there was an extreme difference in the two terms, as in people found the first term accessible, and the second very distant from them. In other words, aside from adding songs to a queue or playlist, or controlling a queue or playlist, people saw DJing as something done by someone who practiced DJing as an art. They were unsure as to how DJs created flows. We concluded that the easiest way to make ‘DJing’ feel accessible to the average user was by creating a shared queue that users could add to and interact with in real time.

Thus, we created task 1:

And its flow:

Since we felt the feature was user-based (one user would create the set and then share it with others) that it should be located in the user’s profile.

Because our users were more likely to find music by sharing directly with friends rather than following famous people, we decided to create several privacy options that could be toggled on and off according to the preference of the DJ, allowing them to limit the set to users who they had ‘friended’ (contacts they were mutually following) to view the set and to add to the queue.

The “go live” option was added to ensure there was a distinction between live sets and those that have already concluded or have yet to begin. Ideally, this feature allowed the ‘DJs’ time to curate their setlist or the member’s of their room before beginning, so they could share with confidence and therefore more frequently.

We also felt, however, that creating a function that allowed users to more closely interact with both their peers and with famous artists was crucial to our business goals and to generating a greater sense of intimacy among users and artists. It was on these guiding principles we based our second task:

And its flow:

After concluding our first round of usability testing, we came across several problems. We found that users were confused by their inability to navigate the app through as many pathways as they normally could, and by the term “DJ set” as well as the ‘Go live” feature.

By pathways, I mean the way a Spotify premium user can create a playlist in several ways.



As you can see, these pathways are varied, intuitive, but also require a fair number of steps to create a playlist. This made usability testing with low-fidelity prototypes especially difficult because the steps were fairly limited, and each pathway meant several screens had to be replicated several times. In addition, a user can follow a pathway but achieve different results. For instance, because of time constraints in building the first prototype we could not allow users to navigate multiple pathways in the app. Although, in theory, the user could ‘begin’ a DJ set by adding either a song or a friend first, our pathway only allowed the user to add a friend. Some users didn’t understand why one would begin a playlist with a user rather than a song.

We also found that several users were confused by the term “DJ set”. They did not always understand that it applied directly to them, or that it was accessible to them as non-professional DJs. Nor did they understand that it entailed the ability to create a live queue.

We tried to address these issues in our second round of usability testing, for which we created a mid-fidelity prototype rather than a low-fidelity prototype. We hoped the increased fidelity would help guide the user.[IMAGES OF MID-FI 1]

We found, however, there was still some confusion. We had the same problem, where The feature was located in the profile dropdown section, but almost all users navigated immediately to their main library menu, but when they did not find the feature there, users would start trying to navigate to other sections of the app. However, when they accomplished the task successfully, their feedback generally became positive and they stated they’d like to use the feature in the real app. We also found that users were unclear as to what the name of the feature meant.

Users expected the “Create a shared stream” function be somewhere in the above menu.

In the third prototype we added another pathway, which allowed users to create a DJ set from a song, and then add a collaborator. We still had one problem, however. We added another pathway that allowed the users to create a DJ set via a single song, as one can create a playlist in the current app. But though the set creation was available through a song, users were immediately confused and discouraged when they could not find the application as quickly as they felt they should be able to.

One of the paths of navigation (along with the navigation from the profile) to stream creation.

The third round of usability testing also addressed the issue of name confusion. We also did some A/B testing to figure out a more intuitive name. We chose “Live Stream” and “Shared Stream” for the name of the feature and tested 3 users for each. We found users struggled significantly less to locate the feature in the second mid-fi prototype. Perhaps because of the higher fidelity of these prototypes and the changing of the wording to something that has a more universally understood meaning attached rather than “DJ set” which has a murkier definition, users had little to no issue discerning that the “Shared Stream” or “Live stream” was the feature they were looking for. We ultimately decided on “Shared stream” because Livestream already exists in colloquialism with an understood definition that is more broad than the feature we were applying it to.

In the fourth prototype, we addressed the major issue of users going to their library, looking for the feature, and going back to the home page in frustration by adding it to the library menu.

We found that this changed solved most of our problems, and our users were able to successfully complete the tasks we assigned them.