Music Playlist Management
This project was over a 4-week period for a Usability and Information Architecture course at UC San Diego. I was in a team of 4 with both design and computer science students. The assignment was to create a prototype for features of a mobile music app that specifically focus on tasks involving making and managing playlists.
We first started with user interviews to get an understanding of how people use their music apps. From this, we extracted various scenarios to use when running our user experience tests. We had users run through these scenarios on two different, currently existing apps to piece out what aspects of each constituted as good design and less good design. Then, we looked at the information architecture of three apps as a start to thinking about how to organize all of the music information in our own app. Finally, we drew out a few different design options, and used our results from the previous steps to narrow in on one final design. Our final interactive prototype was created with the websites Proto.io and InVision.
Phase 1: Interviews
The first step was to interview people who fit within our targeted user group, in this case college students who regularly use music streaming platforms on their phone. We wrote out our interview questions as a group and then split up the interviews to 2-3 per person.
Looking back, although it might have taken more time, it would have been more effective to have two of us per interview. Our questions covered a wide range of topics, and it’s tricky to keep track of it all while simultaneously listening to the interviewee to make sure you’re asking the appropriate follow-up questions. In addition, I quickly learned during the first interview that some of our question weren’t phrased as well as we thought. Some questions were too broad or vague, so people had a hard time grasping what we wanted to know. Others were too specific, and people answered in one word. Both required me to rephrase questions and add follow ups on the spot to make up for it.
Regardless, we were collectively able to reveal a variety of scenarios to consider for the next steps, and we noted down how to improve our question writing for later in the project.
Phase 2: Comparing User Experiences
With our scenarios in hand, we proceeded to testing out the workflows of two prominent but distinct music platforms, Spotify and SoundCloud. By doing this, we would be able to compare different user experiences to see what worked and what didn’t, and adapt what worked into our own design. I had never started the design process around specific scenarios before but found it incredibly useful. It allowed me to focus in on features of the design without getting too overwhelmed or distracted by all the other potential features.
The workflows of the first create scenario, creating a playlist tailored to your personal tastes for getting ready for a night out, and the last management scenario, organizing a playlist that had grown to be too big by taking out multiple songs, are shown below. These are the scenarios that we decided to tackle in our own design.
Scenario 1: Create a playlist for your personal taste for getting ready for a night out
For the first scenario, we found that both apps had a similar workflow, but that Spotify had some shortcuts that quickened the process. Although you start with running a search in both apps, with Spotify, you can create a playlist directly from the search page whereas with SoundCloud, you have to open a playlist or song first. Spotify also appears to have more confirmation popups, so users are assured that their request was carried out.
Scenario 2: Organizing a playlist that had grown to be too big by taking songs out
For the second scenario, although both were inefficient we found that SoundCloud had a slightly faster workflow. Both apps allow you to delete by individual songs, but under SoundCloud’s edit playlist option, you can delete songs by swiping them to the left. This allows you to scroll through and delete songs as you go, saving the use from having to go back and forth. However, neither app allowed you to select multiple songs and delete them all at once.
Phase 3: Comparing Information Architecture
There’s a lot of information to handle in a music app: artists, playlists, albums, songs, genres, and the list goes on. Instead of inventing a completely new information architecture from scratch, we instead looked at three different music apps of varying popularity to see how they did it: Spotify, Google Play Music, and Napster.
We divided them into their first, second, and third levels of information. Spotify packed a significantly larger amount of information into its first two levels than the other two, and Napster had the least. On the other hand, Napster had significantly more genre categories, due to it being the only app out of the three that went as far as to have subgenres.
We noticed that four or five navigation tabs on the first level seemed to be the norm, and noted this down for our own design. In addition, these tabs were more or less the same categories. There was always a Home and My Library or My Music navigation. Some had a Radio option but because this isn’t directly related to the focus of our design, creating and managing playlists, we knew not to include this in our navigation. Some apps also had recommendation features, which we found to be surprisingly important when creating playlists as we found out from our initial interviews and user experience testing sessions; we noted this as a potential feature on our app as well.
Phase 4: Designing the Prototype
With all of our information and ideas in hand, it was time to start putting our designs down on paper. We decided to do this by redesigning a workflow for each scenario specifically, rather than going about designing an entire app.
With the first workflow, creating a personal playlist, we had to decide on how to design a lot of the main components of the app: the navigation, the home screen, and the create playlist page.
Navigation
With the navigation, the first major design decision we ran into was where to place it. In all of the apps that we saw, the use of a navigation bar was consistent. Some apps like Napster and Google Play had a pull-out navigation; many others went with a persistent navigation bar at the bottom of the screen. We were able to see the merits of both, so had a hard time deciding in the beginning.
We first considered including both, in an attempt to include as many options as possible. But a reference to our information architecture research showed that this would be unnecessary, and likely impossible. Remember, four or five navigation tabs was the norm and the categories were more or less the same between apps. So, we realized that it was a matter of choosing one or the other. We looked at what more popular music apps tended to use as well as the basic usability heuristics defined by Jakob Nielsen. Both leaned towards the persistent bar at the bottom. In terms of heuristics, this was better for “Visibility of System Status” and “Recognition over Recall” because the persistent visual cue of the navigation bar would help keep users oriented to where they were in the app at all times.
After choosing the type of navigation, we needed to narrow down what to include in the navigation itself. We already knew from our previous research that we needed to keep Home, My Library, and Search and that Radio wasn’t necessary for our use cases. But the rest of the tabs were up in the air. Should we have a Recommended page? Discover? Browse? Connect and Share? We tried out a first iteration with a Home, Library, Search, Recommended, and Share since these seemed to be things notably liked by users during interviews.
After looking at it, we decided that a Share option in the main navigation was out of place. Even though it was liked, it never really came up during the run-throughs of our two target scenarios, which are the main focus for our design. Any social features would be better served if they were integrated into lower levels of the app, such as under Recommended or My Library.
Secondly, we renamed the Recommended tab to Discover. We realized that just having it be Recommended would severely limit the scope of what we could put on that page, leaving things like browsing without a place to stay. Definitionally, Discover could not only encompass recommendations but also exploring current trends or genres that may not be under your typical listening habits. This left us with our final navigation bar:
Home Page
Figuring out the homepage was probably the hardest part of our design process. We struggled with deciding on what users would most want to see on the landing page. We noticed that most music apps consistently presented some sort of banner at the top and considered including this on our home page as well. We also noticed that the titles of categories on the homepage were often arbitrary and users needed to scroll through what was included in the section to understand what the title meant. This more often than not caused a cognitive overload, and people gave up on using the homepage--instead going straight to their library. We wanted to make the homepage less cluttered and more intuitive, hoping that it would make the page more appealing to users again.
A part of making the homepage less cluttered and more appealing was figuring out how we wanted to display the information on the homepage. More than this, we had to decide how the users would interact with the homepage. We decided to use elements of both a vertical and horizontal scroll, enabling us to still have a wealth of information available to the users--but without severely cluttering the page. We decided to show actual pictures of the albums/artists/playlists rather than just a stack of their names because this would be more visually appealing and immediately recognizable.
Figuring out the content of the homepage was difficult because it felt like we always needed more opinions or feedback on what people generally wanted to see. Our interviews did not give us a very cohesive picture of what people wanted; there was a lot of contradictory feedback, and this made it difficult to decide on what to include on the homepage. More than this, from our reading (Don’t Make Me Think), we learned that there is in fact no such thing as a general user. This made our task seem even more daunting and difficult.
The way we decided to solve this, within our scope of feasibility, was to have a mix of what was preferred by multiple kinds of users: Recommended, New or Trending Music, and Recently Played. However for possible future iterations, we think it would be interesting to test a homepage that is customizable. Ideally, in their settings, users would be able to select certain streams that they would like to be included. These options could include things such as Recently Played, Recommended, Top Hits, New Playlists, etc.
We were split on whether to have a Welcome banner at the top to make the app feel more personalized and welcoming. After comparing the two, we decided that the second option felt less cluttered with text. In addition, we were already able to create a feeling of personalization with the recommended section so having the Welcome banner was not as necessary.
Create Playlist Page
Because this is the create playlist scenario, of course the create page was essential to our design. Though there are a variety of pathway options to create a playlist, we decided to focus on one that takes the user to the Playlist page on the My Library tab. On the Playlist page, we added a large, bold Create button at the top so it stood out from the other possible interactions on the page.
The Create Playlist form allows the user to not only name the playlist but also classify it as private, public, and collaborative. One complaint that came up during interviews was that it wasn't evident whether the playlist was public or private and it took too long to confirm, and change it. So we made sure that this information was clearly presented to the user as soon as they create a playlist.
We also made it possible to allow the user to add songs immediately from their own library or from the “Discover” page. Going back to the workflow comparisons, Spotify faired slightly better because it allowed people to add music to playlists at an earlier step compared to its competitors.
Managing Playlists
Although we were focusing on the specific workflow of deleting multiple songs from a playlist, we still had to put in some consideration on how to organize the different management options within our app.
There are so many functions associated with managing a playlist, and the space needed to display these numerous options are limited. We did not want to clutter up the page with too many options, however we did not want to exclude any of the functionality that we thought was pivotal to good user experience. Playlists could be edited, deleted, moved, shared, downloaded, added to a queue, renamed, made collaborative, etc. We kept most of these features but organized them into groups based on frequency and type of use that we found from our interviews.
The Shuffle and Sort By are included as buttons at the top of the playlist because these have to do with how you want to play the playlist and are needed as more immediate options. We wanted them to be noticeable buttons because from our interviews, we found that these options are often hidden or hard to find. The rest of the features, the ones that tend to be used less frequently or are more editing specific, are available in a pull-out menu at the top corner of the playlist. These include Edit, Rename, Delete Playlist, Merge, and Share. Although features like download are important, we decided not to include it in this version of the prototype because it’s not used in the specific scenario workflow we are enacting.
Under Edit, we added the ability to delete, move, or copy multiple songs rather than the one-by-one approach given by other music apps. Although other apps have many options to edit, they are only able to be done one song at a time. From the interviews, this is seen as a major issue, so we decided to make it possible to do these edit options with multiple songs to drastically shorten the workflow and repetition for the scenario task.
