Fine Tune Music App (Conceptual)
Project Overview:
Product type: App | Duration: 3.5 days | Tools: Marvel | Status: Ongoing
My role(s)
Despite my teachers at GA and multiple published sources insisting designers are not the user, I started out as the user. I did quickly step into a researcher’s role, interviewing people to better understand the universe of their habits, pleasures, and pain points surrounding music; And when it came time to synthesizing the rich information gathered, I stepped into my newest role, UX designer and usability tester. Ultimately, I became a presenter on why the solution I had come to in the given time needed further work/iterations and is very much needed by the wide community of music listeners.
Limitations, parameters, resources, and materials
Without a doubt, the biggest limitation was time and the low fidelity of my prototype. Creating a full-fledge solution to my target user’s problems with paper wireframes demanded more time. The linked and interactive drawn wireframes using Marvel is the highest type of fidelity prototyping my cohort has been trained in thus far, making this a limitation and the best means to communicate my solution to the perceived problem.
Initial problem statement
I started by making an affinity map of my own habits, motivations, and frustrations.
Drawing from my time-boxed ideation session, my initial assumption was that people have so many songs in their music libraries, organized objectively by genre/artist/album or into playlists, they don’t have a means to pull from their library based on their mood and end up skipping around. This lead me to wonder how might we enable people to easily listen to music that suits their immediate mood?
Confirming and refining my initial assumptions
Determined to test my assumptions, I spoke with six people, all of whom use at least one music app (all use Spotify and perhaps two other music apps). The questions focused on music-related behavior to determine music-listening habits and any pain points. There was a fascinating wealth of information, some that nearly directed me down a completely different path given their frequency/potency. That said, the overwhelming evidence pointing to this frustration with getting sick of songs and desire to find music to fits one’s mood/activities confirmed my original assumptions.
User Interviews
Here are the questions I asked my six users:
- Could you tell me a little about yourself? What do you do? Do you have a long commute?
- Do have a favorite genre of music?
- How do organize your music library? Do you use any apps?
- How do you go about choosing what to listen to?
- How do you curate your playlists? Do you update your playlists often?
- Could you describe a time where you were frustrated trying to find something to listening to?
- Is there is anything we have not touched on or that you’d like to talk about regarding music?
What did I find out? Music is powerful, it’s a reflection of our personality, and many times a journal of precious memories. The interview questions prompted conversations that were as informational as they were exciting. I started and ended with the same questions for all six admittedly because I was insatiably curious to hear what the next person would say; how did they organized their music, did they go back through playlists like they would go through photo albums, reminiscing about summers driving to the beach or falls spent in the library at college? As one user put it, it’s almost as if “you get to relive [those memories].”
With all the data pulled from the interviews, the glaring problem, the one I had originally started out with, shone through.
Some key info included:
- 6 out of 6 participants uses Spotify; only 1 refused to build playlists (a proud outlier)
- 5 out of 6 participants choose music to fit their moods and/or what they were trying to do at a given moment (eg., workout or focus)
- 1 out of 6 (the same proud outlier without playlists) do not seek new music through Spotify’s recommendation features
- 2 out of 6 participants complained Spotify’s recommendations relied too heavily on the artist and/or genre, and less on the mood(s) songs fit; as one person put it, he wanted songs that “evoked the same emotional response”
- 3 out of the 5 who make playlists end up removing songs or retiring entire playlists after getting sick, or annoyed (as one person put it), of the song(s)
There’s a clear honeymoon phase with playlists/songs; as soon as that phase is over, people get sick of songs, fall into a spiral of skipping since the songs don’t fit their needs, until the people ultimately file for a divorce and begin developing a new playlist. Rinse and repeat. Looking back at my original problem statement, I confirmed much of it and refined it further:
Initial: People have so many songs in their music libraries, organized objectively by genre/artist/album or into playlists, they don’t have a means to pull from their library based on their mood and end up skipping around. How might we enable people to easily listen to music that suits their immediate mood?
Refined: Playlists are perfect for curating songs people currently like, but often times the songs don’t fit people’s immediate needs (moods/activities) or it results in people getting stuck listening to the same song until they get sick of it. How might we expand what people are listening to given their wealth of liked songs and immediate mood and/or activity?
Sketches
The user interviews highly charged some of the original features I intended to prototype and test.
For example, one screen was a search function where users could find a “station” of sorts that fit the mood they’re in and/or their current activity/activities. The concept was that after importing songs from Spotify, users would incrementally tag (or all at once if they were really bored one weekend) their existing songs to moods and or activities. The app would then learn their preferences and tag new songs and add those to the “station”.
Note, neither of these (nor the snooze button) ever made it to the interactive prototype.
In addition to the search function, users’ complaints about getting sick of songs inspired the “snooze button” that removes a song for a significant time period (long enough for the user to essentially forget the song ever existed).
The original intention was to test the entire app experience, consisting of: finding a playlist that fit a mood/activity and providing feedback on songs the app recommended.
While envisioning the testing experience, I realized I needed much more time and possibly a higher-fidelity prototype to successfully test an immersive app experience. In the interest of getting feedback, I scraped much of my original screens and focused on crucial learning curves that would act as a proxy for key experiences. Therefore, I ended up creating entirely new sketches focused on the onboarding process, involving a step-by-step guide to import a music library and tag the initial set of songs to moods/activities.
Usability Tests and Resulting Iterations
The goal of the usability tests was to ascertain whether users could successfully complete crucial tasks that served as a proxy for the envisioned primary features of the app. The created screens and tasks were important as well since onboarding is so critical to a great user experience.
In the first round of usability tests, 5 of the 6 tasks were completed successfully and 2 out of 2 of the primary task (tagging songs to moods/activities) were completed successfully. The one issue with the onboarding process was one interviewee skipped uploading her Spotify playlist, a failed task. To address this without major changes, I added a simple warning note to prevent any further failed tasks.
In the second round of usability tests, 6 out of 6 tasks were completed. That said, while the second-to-last test only had the usual bit of awkwardness, the last test was knee-deep in it. The participant insisted the app concept was great but the onboarding experience was too contrived; all he wanted was an overview of the features and to get to the homepage to navigate to complete the tasks. While one data point wasn’t going to change the entire design, this sparked a realization for me. 4 out of 5 participants had in a sense tried to navigate to a homepage during the usability tests indicating this last participant wasn’t alone.
Synthesizing test findings, there were several ideas I entertained for next iteration, such as the brief features overview as well as a fuller app experience. This would then allow me to include the “snooze button”, search function, as well as other potential features to better understand how user-friendly the app concept is.
Prototype
Reflection
The first hour after receiving the brief was spent planning/giving due dates to each task in a Trello board for the project. This ultimately ensured I was fully prepared for the presentation which was given as much priority as the research and design processes. To paint the picture as clear as possible, I originally planned to complete everything up until preparing the presentation deck by Saturday night, allowing all of Sunday to be focused on the presentation deck and practicing. Naturally, not everything goes as planned, and everything but the presentation was completed by Sunday afternoon, which still allowed for an entire day to be devoted to preparing for the presentation. The biggest surprise was how well Trello kept me on tract and freed up headspace during the research and design process to focus on the tasks at hand. Were I to go back and do it over, I’d have tried to squeeze one more iteration in, re-doing much of the prototype. This was a risk I needed to take to really experience the iterative design process, and much of me believes I played it a little too safe; that said, the designs were still a good proxy and the designs were performed pretty well during the user tests, so there’s a lot of great material to work with for future iterations.
