Musi: a Case Study
Musi is an iOS app which allows users to curate YouTube content and organize it into the app’s library or in user-selected playlists. This way, users are able to enjoy YouTube’s giant library with the same functions as their mobile music player. Users can create playlists of music, podcasts, Ted talks, cat videos, or whatever else they want from YouTube’s entire catalog, without ever having to deal with YouTube’s mobile app. Most importantly, users can play YouTube content in the background from their lock screen! Oh, and it's free.
In doing preliminary research, I found that no one in my network had heard of this app. I wanted to figure out why, from a product design standpoint, is this app not more popular. The more I used Musi, the more it irritated me. Creating playlists was confusing, I never knew where in the app I was, or what options I had in front of me. Certain key features were difficult to find, and it took a happy accident for me to find out Musi’s greatest feature: the ability to play YouTube tracks from the lock screen. A part of me just wanted to complain about this app and end it there, but instead I decided to see how I could make this powerful app just a little bit better, so I started interviewing users.
The Design Process
To improve Musi, I followed a well-defined, objective based approach. If you are a designer, I bet you’ve seen something like IDEO’s human-centered design process in a post just like this, and I’ll also bet you’re getting pretty tired of reading about it. If you are interested in how I interpreted and implemented this design process, stay put, but if you can feel yourself getting bored already, please feel free to skip this section and check out the pictures and my prototype down below.
Phase I: Empathize
In the empathy phase, I begin with tinkering. I figure out what I like and what I don’t like about the app. I imagine myself as someone else, somewhere else, and I create a narrative around that. I allow myself to go through a range of emotions, from thrilled, to kind of interested, to irritated, angry, even. When I get angry, I know I’ve found a pain point. This is really where my daydreaming really skills come in handy.
This initial tinkering step allows me to really understand the app with its strengths and weaknesses, and to come up with a few real world scenarios I can test on users. This leads me to my second stage...
Guerilla Usability Testing:
I took my usability testing Yerba Buena Gardens in SOMA area of San Francisco. I was able to find 5 users to test and was allowed record them on video so I could review their responses. I asked them to imagine a few scenarios to lead them to use specific features of the app.
You are preparing for a long road trip and want to listen to music of your choice, but you do not want to have to pick up your phone while you are driving to change songs.
To get users to utilize search, create a playlist, add song to playlist, play songs out of playlist, and to find out if users realize they can play music from their lock screen.
Imagine you are at a party, and you don't know what people want to listen to, and you don't want to spend a lot of time creating a playlist.
To get users to find pre-curated playlists.
At the party, people are complaining the music quality is bad, what do you do?
To get user to find Musi's app settings and audio quality settings.
Based on my usability testing, I was able to create a personas that both modeled the individuals I interviewed, and who represented my target market. These personas were synthesized from key features of the people I interviewed, but were boiled down and depicted as two specific people. As counter-intuitive as inventing people may sound to someone who isn’t familiar with creating these personas, they allowed me to focus on my target market and to gain clarity into key pain points, allowing me to clearly define the problems I needed to solve.
Phase II: Analyze
The next step was to review and synthesize my findings from the usability tests. While reviewing the tests on video, I wrote down every one of the users' comments on Post-It notes. I created an Affinity Map by placing these insights on a whiteboard and sorted them based on their similarities. Visualizing them this way allowed me to easily see the repeating pain points I should focus my redesign on.
The major pain points I found from my usability testing all revolved around clarity within the app, although there were a couple minor aesthetic comments a few users shared.
- Users were not clear what value Musi had over their other options. Yes, Musi gives them free music, but they can get that almost anywhere.
- Users were never clear where they were at inside the app, and were consistently confused over having to press back so many times to get to their desired location.
- They were consistently thrown off by the “M” button at the top, as well as the + “import” button, which never seemed to do what they wanted.
- Nobody knew about Musi’s key feature, lock screen playback of YouTube music.
Phase III: Define
Because of the problems all of my test subjects had with clarity, i had to remember that my job was to decide how to best present information within Musi, while avoiding major redesign.
My primary objective was to solve user’s confusion within the app. I had to ask myself:
“What information is missing? Why do we need it? What are the underlying problems with the task flow? What are my key objectives?”
Since every user who created a new playlist first had an easier time understanding the app than those who started off by using the search function, I wanted to make a simple changes to the design to encourage users to create a new playlist first. Furthermore, I wanted to solve the issue that users had getting back to the playlists if they were elsewhere in the app. I discovered that issues with the task flow, which necessitated the use of both “back” and “done” buttons to find the playlists after using search, confused users immensely.
Information on where playlists live was missing. That information is needed because the majority of users who did not initially find the playlists found themselves lost in the app. The underlying problems were that it was not clear where people were in the app and users were easily “lost.” My key objectives are to simplify the task flow and to clarify the playlist function with as little redesign as possible.
Words about the above thing.
Task Flow for building a playlist and adding songs to library
As you can see, the user is faced with two greatly diverging task flows. User researched showed that the majority of users found themselves stuck down the "Search Detail View" flow, and a few were unable to make their way over to the left side of the flow where playlist management occurs.
My primary objective is to allow users to move about more freely within the app, while also giving them more clarity as to where they are. Ideally after the redesign, users will not find themselves "stuck," and unable to perform simple audio playback functions.
Phase IV: Ideate
Now that my user’s pain points have been defined, through analysis of user research, it is time for me come up with ideas to solve thes problems. The key here is to do this as simply as possible, or as a wise old surfer friend named Hunu once told me, “Do Less!”
I sketched a few options to fix the clarity issue, all other major issues, I was able to to solve with the addition of a bottom navigation bar.
Phase V: Hi-Fi Mockup and Prototype
I was able to move rather quickly and translate my lo-fi sketches into hi-fi mockups in Sketch. I wanted to make simple, yet significant changes to the UX of Musi, first being the welcome message. Since everyone who I interviewed that created their playlist first before searching for videos on YouTube had no trouble with the app's playlist functionality, I wanted to provide some encouragement to future users to explore the New Playlist path first. Part of the reason why this was the case was because once a playlist is created, it is visible in the add songs menu when searching YouTube.
1. Replace the vague icon on the top left with text that reads "New Playlist."
2. Modify the welcome message to call attention to playlist functionality, as well as differentiate between the app's library and it's playlists.
3. Add a bottom navigation bar that allows free movement between major portions of the app so users do not get "lost."
4. An alert message notifies the user of the app's key functionality, Background Play.
A small issue I had with my bottom row navigation was that it necessitated a redesign of the "Playlists" window as that lived in a off-screen slider. See below:
An aesthetic change to the playlist view which offers greater clarity, and more information. It also allows some functionality previously available only in the song detail view in the playlist view. All of these changes are a result of minor minor issues from multiple users.
Prototype and Validation:
Unfortunately I ran out of free Marvel prototypes and chose to keep my actual client work active instead of this case study. As far as validation goes, all of the users who tested both original app design and my prototype preferred the tab bar over the existing design. Combining the tab bar and replacing vague icons with clear text, new users expressed no problems navigating throughout the interface, creating new playlists, and importing YouTube tracks into those new playlists. One repeat issue that came up was that the "Play" button on top of the album artwork was unreadable with white covers, so if I were to redesign this, I would make a change to that option.
As this was my first exercise in the art of user experience design, I was surprised how often my gut creative choices were wrong. It really made me respect the process of user research and taking my emotions out of the design process. It was humbling to see how often I was wrong, but by listening to users, how easy those mistakes were to correct. I also found that I get the most satisfaction out of spending time to really understand a problem, to understand that problem deeply, and to use this knowledge to make simple, elegant changes, without over-complicating the interface. It may sometimes look like designing "less" is avoiding extra work, but I find that the work that goes into pulling off a subtle, yet powerful design happens before the even pen hits the paper or the mouse to the pixel.
I hope the recommendations of this case study find their way into the hands of Musi's designers, because I really love using their app, and with a couple simple tweaks, those who are used to using apps like iTunes and Spotify will be right at home. I would like more people to use this app, because I want it to stay around. I use it almost every time I drive long distances. However, if nothing changes on their end, I have gained greater insight into the true value of user research and the style of design I want to push moving forward.