Prototyping Vibes, a better music app

A understanding of human-computer interactions requires not only a deep understanding of human intuition and reaction, but also careful study of how computers follow the lines of that intuition to create a seamless flow for any task a user might ask of them. That deliberate look at both humans and machines forms the basis of most cognitive science projects, whether they involve back-end or front-end development of a product. When my team and I were asked to prototype a new music app, we started at the root of what we believed people wanted to see.

The contextual interview, in which designers interview a wide range of subjects about a specific topic, starting off with a list of set questions but going in the direction of the interviewee’s speech in order to gain a deeper understanding of what they want or need, forms the backbone of UX design. To this end, we interviewed a number of UC San Diego students, heavy music enthusiasts, about their chosen music streaming apps to get to the heart of WHY they used the app that they did. We asked our interviewees what they liked and did not like about the app, as well as having them simulate how they would perform a number of given actions (such as adding new music to a playlist) in order to get an idea of the flow of their interaction with the app. This in turn allowed us to infer what the interviewee liked or did not like about the way that the app worked. We also asked them about specific moods they emulated using their playlists, and scenarios in which they created, added to, or deleted songs from those playlists.

This told us a lot about several major music apps, including but not limited to Pandora, Spotify, and Apple Music. We formed the data collected in those interviews into a concrete list of scenarios for each user, showing individual idiosyncrasies as well as universal needs. Each scenario had a description that was lifted directly out of the interview transcript. For example, one interviewee noted:

I don’t make new playlists very often, but I do make specific playlists for various moods I am feeling. One of them is for when I want to remember a close family member. Another is for when I want to study, and I have one for when I’m doing laundry.

These could easily encapsulate three separate scenarios, but we chose to locate them all under the more general umbrella that the interviewee herself describes: creating a playlist for certain moods the user is feeling.

We had to whittle all of these scenarios- around 60 in total- down to ten, so that we could accurately create an app that managed a great number of specific scenarios effectively. The app had to be flexible, and in order to better understand how it could be, we compared the workflows of the various apps that we had seen in the interviews for ourselves. Each separate examination of flow was drawn from one of the general scenarios that we created.

These snippets show the flows of Spotify and Pandora, respectively, when deleting a song from a playlist.

When the user clicks the album artwork for a song, they have the option to then click on the three dots on the right side under that artwork. The option “I’m Tired of This Track” pops up on the screen.
When the user selects “I’m Tired of this Track”, Pandora displays a confirmation message telling the user that it will be removed from the playlist- and all other playlists- for “a while”- by which they mean 30 days.
The user can select the three dots on the right to delete a song.
A circular red “Delete” button pops up on the left side of the song.
However, the user can also select the three bars on the side to delete the song.

When the user attempts to remove a track thoroughly from all of their Pandora playlists, the process is simple: they click on the track itself, then click on the three dots on the right underneath the album artwork, and select “I’m Tired of This Track”. Spotify, by contrast, gives a series of conflicting options that mean the same thing. This is a clear breach of consistency and standards, since the user is used to seeing only one “Delete” button on the right in most apps. While the process is easy to perform, it is more difficult to explain and deduce which button is which.We thought that Pandora’s flow was streamlined and easy; it deletes a song from a station for 30 days, and is one of the more flexible features of Pandora given that Pandora is not a true music streaming app but a listening app. Nevertheless, we really liked having that one confirmation button, a potential design that was backed up by interviewees who cited this feature of Pandora in their interviews.

We also envisioned taking this feature and making it customizable for the user, by expanding the set of decisions that the user can make when deleting the song to propose different lengths of time as options when removing the track. We reasoned that this would allow the user to feel they are in control of the app, as well as giving Pandora feedback on the user’s desires and tailoring the algorithm to create a set of data that matches their own needs. It would also apply to a broad range of specific scenarios for which the user could feel the need to remove the song; it could be that the song reminded them of an ex-significant other, or that they felt the song was too overplayed on the radio. That generalization was especially important to consider.

We repeated this process for nine scenarios, and once we had a good understanding of what our interviewees (and ourselves, as designers) found useful in music apps, turned our attention to charting the sitemap for each major music app, using the main navigational labels found on the navigation bars of those apps and the secondary-level labels on each successive page.

Our sitemap for Spotify.

This mapping not only told us what navigational labels (like Home, and Search) each app had in common, but also helped us get an idea of the content of each app. For each, we also created genre lists:

This complete list of genres within Spotify showed us not only what the app contains but allowed us to imagine how it appealed to our interviewees.

Looking at those genre lists, we were able to imagine how the content appealed to many different music streaming app users, and how that content related to the ease of discovery for the user (ie, the flow of use which took them to the music they wanted to hear or discover). This also began our obsession with creating an easily discoverable and prominent set of “Discovery” features in-app, and that obsession fueled the customization of the homepage of the app as well as the nav bar labels we chose.

Having looked at the human wants and needs for an app, and the flow of the app itself, as well as some of the content each app provided, it was time to begin prototyping our own app.

We based our app heavily off Spotify, with the same intense color scheme and partially opaque icons that Spotify uses in their “Discover Weekly” section and that we integrated into our homepage. A lot of the decisions that we provided for users in-app matched Spotify’s and went even further in choice.

Our homepage

Our homepage, as you can see, includes many sections featured on Spotify but arranged in a different manner. Spotify’s “Discover Weekly” section, which many of our users professed to loving for its ability to utilize their past music tastes to curate new playlists tailored to those preferences with music they may not have heard before, is split up and integrated into the “Just for You” icon, and to a lesser extent “Featured Playlists” which the app categorizes by relevance to the user and specific scenarios in which it uses data to predict they might want to create playlists for at some point. We also have “Recently Added” and “Recently Played” in order to allow the user, who may have closed out of the app intentionally or unintentionally, to seamlessly continue from their last streaming section. We also added something new, the “Surprise Me” bar at the bottom of the page with its three subdivisions. Spotify does not have this, but with our interest in creating a versatile app that introduced the user to new music, we wanted to offer a spontaneous new song, artist, or album that would introduce the user to something new and outside their comfort zone.

We created two prototype “flows”; one for creating playlists and one for managing playlists. I will highlight the differences and similarities to Spotify for both, and how we believe we improved upon that existing app.

For the “create playlist” scenario, we decided to include a pop-up that felt like Spotify’s pop-up because we liked the fact that the app kept the user on the same page while creating a playlist instead of involuntarily taking them to their library.. We also mimicked their flow because we felt it involved the least amount of steps that could be taken to create and add music to a playlist. However, we diverged from Spotify with the layout and wording of the pop-up, as seen.

Spotify’s pop-up menu.
Our pop-up menu.

We felt that Spotify’s “save” option was too vague, and so then opted for the more specific label “Save to Library Songs”. We also wanted to display all of the options that the pop-up allowed, rather than making the user scroll to find them. Our pop-up allows the user to create a new playlist as well as add a song to an existing playlist for more user choice. It also allows them to go to the album of the song they are saving, or the artist. We included these choices, instead of “Share” or “Add to Up Next”, because we felt these options better reflected the flexibility of the app and allowed the user to easily find more similar music for their playlists.

We wanted to improve the functionality of Spotify’s confirmation when adding a song to a playlist, and this we did by giving the user the choice of closing the confirmation or going to the playlist. This was a huge talking point in our interviews, with arguments for and against the functionality of Spotify’s confirmation. Ours does not fade away, like Spotify’s confirmation message, but does let the user pick whether they would like to choose to go back to the “Jazz” page, or to go to the newly created (or ongoing) playlist to get a good overview of what they are creating. We felt this would enable the user to access the playlist at any point in time while creating it and adjust their vision for the playlist accordingly.

For our “manage a playlist” scenario, we made a few design decisions that we thought improved over the functionality of Spotify. Spotify makes the user click a button on the top right of the screen in order to even get to the pop-up menu with the edit option in it. “Edit” takes the user to the “delete” option to the left of the song.

In comparison and in contrast to this, we put an “edit” button in the top right corner of the screen on any playlist to eliminate the need for the pop up menu and to specify exactly what the function of the buttons in the corner were. That edit button came from Apple Music, which displays it prominently in pink in the top right corner of their app. We felt that this choice was user-friendly, in that it guided the user toward managing their music collection effortlessly and pointedly without making them guess how to edit the playlist.

We also improved our editing task by including an “add music” button all through the editing process. This was also a departure from Spotify’s delete only model, and we made the choice to include it because we didn’t want to preclude the user from adding to a playlist as well as deleting, and wanted to keep both management options easily in view on the same screen.

After deliberation and looking back at our user interviews for feedback on the process of deleting a song from Spotify (as some interviewees thought that the two “delete” buttons were too detailed a process), we reluctantly included them when we realized that the process of clicking on the button on the left and then confirming the button on the right provided much needed room for user error. In case of the user accidentally clicking on the “delete” button, a second “delete” option pops up on the opposite side of the screen to confirm that this is in fact what the user wants to do.

However, our app also differs and improves upon Spotify’s model by showing the user a confirmation model to ensure that they know the process of deleting that song has completed.

Our app also takes the user back to editing mode, wherein the user can still add music (or delete if they still have songs on the playlist). We made this choice because we wanted the confirmation to lead back to a screen that felt more continuous with the screens that were shown before the pop-up, and provided a flow to the entire experience of managing a playlist. The user can then click “done” to exit the “edit mode” completely, and be shown the new list of songs on the playlist that they were editing.

Overall, we designed this app with an eye toward creativity and customization for the user, and with an intuitive flow. We had to integrate the need for intuitive flow with a faster flow (ie having less steps in our design), and through the decisions we made came to a better understanding of what works best for mobile apps geared toward a wide range of music lovers. We learned a great deal about design and implementation during this process, the least of which was to stay extremely close to the original data in order to actually design the app for the target audience. We also got a great idea of all the aspects of design that have to work in tandem for the product to actually answer the needs of a user (ie, human intuition, the flow and flexibility of the app, and the content of the app, to name a few that came up over and over again in our design process). We had to make a few design decisions that we didn’t necessarily think were great- when we mentioned Spotify’s convoluted “delete” function back during the stage of comparing the workflows of different apps, we had every intention of changing it until we realized that this was the most effective way to make sure a user didn’t delete a song accidentally. That secondary delete button worked as a failsafe. Moments like this forced us, as designers, to go back to the drawing board over and over until we found a flow that we reasoned would truly work for the user. We redesigned the homepage itself three times before finally agreeing on the design that would give the user the most flexibility; we all agreed that displaying that flexibility right when the user opened the app was important in order to communicate its goals and potential to them. We also would have loved to explore our “Discover” section more, and really flesh out the content of the app, but we knew that designing the decisions for each scenario was the most important thing. This project was a valuable lesson in prototyping and design thinking. The clear vision that one communicates through design is what sets their work apart.

Like what you read? Give Amber Gallant a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.