Musi: a Case Study

Overview

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.

Scenario 1:
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. 

Purpose:
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. 

Scenario 2: 
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. 

Purpose:
To get users to find pre-curated playlists.

Scenario 3:
At the party, people are complaining the music quality is bad, what do you do?

Purpose: 
To get user to find Musi's app settings and audio quality settings.

Building Personas

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. 

affinity map above. 

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. 

Import problems 

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

A couple sketches leading into how to fix this app.