A new music app that generates playlists for locavores

​

My role

My role in this project was broad, spanning from UX researcher to designer to tester. Since this was a solo project designed to reflect rapid prototyping, my work covered all stages of UX design from research, synthesis, redefinition, ideation, to delivery.

​

Timeframe

The project spanned four days, from January 19–22, 2018.

​

Limitations, Parameters, Resources, and Materials

The prompt was to design a mobile application around the theme of music. Given the limited scope and timeframe of this project, we were given clear instructions on the type of research, synthesis, and ideation to conduct. The research phase consisted solely of user interviews (omitting, for instance, competitive analysis), the synthesis phase was focused on affinity mapping (no personas, etc.), and ideation was done prior to learning any digital wireframing tools or UI, so it excludes visual design elements. No business or technology concerns were considered, as it was a pure design challenge. The final design expected was a clickable paper prototype consisting of a few screens.

​

Initial Problem Statement

Going into this challenge, I didn’t have many initial assumptions about how best to design a music app, or what kind of app to design. I did assume that if I created a music player, it would be a streaming app, because music streaming has overtaken library curation. This assumption was eventually borne out in research, and incorporated into the design. Therefore, I went into my interviews looking for generative research, and openly searching for a problem to solve.

​

User Interviews

I conducted four interviews with a set script I’d prepared ahead of time.

​

I had a few central questions I wanted to answer:

▸ Which areas of the music discovering, curating, or listening process are underserved or not served at all by technology?

▸ Which areas are currently well served functionally and emotionally?

▸ Habits and trends that play into either of those, and could be designed for/around

​

Given those organizing principles, I came up with the following script questions:

▸ What kind of music do you like?

▸ When do you listen to music?

▸ What platforms do you use to listen to music?

▸ How do you customize your music experience to your mood, activities, or location?

▸ What are your thoughts on new, up-and-coming artists vs. more established big-name artists?

▸ How do you find out about new music that you might like?

▸ What’s your experience with live music events and concerts?

▸ What is your biggest dislike or problem related to discovering, curating, or listening to music?

​

My first three questions were broad, framing questions, and the middle five were deeper and more specific to my subject. As I was interviewing, I made sure to ask “why?” whenever I heard anything that bore greater scrutiny. As I was getting good information from my interviewees, I didn’t feel the need to amend or add to my script.

​

I was pleased to gather lots of information from the interviews. Before I even began my affinity mapping, a few amazing quotes jumped out at me:

▸ “Word of mouth is more interesting than Spotify”

▸ “Spotify is not relaxing”

▸ “Music is amazing when I’m traveling or road-tripping”

▸ “The best is when you have a friend who’ll make a playlist for you, like a modern mixtape situation”

▸ “I’ve definitely been in some basements and discovered great talent, and followed artists as they got more famous”

▸ “Discoverability is so hard for the little guys. Spotify and a bunch of platforms are all about the big players ”

​

I had some notions of what these quotes revealed about the music landscape, but wanted to carefully adhere to each step of the design process.

​

How did you confirm or refine your initial assumptions?

After the user interview stage, I moved on to creating an affinity map. I wrote individual insights on post-it notes, color-coding for my four interviews, and moved them around on a whiteboard wall until they converged into themes.

​

These were my most prominent, large groupings: indie/local/smaller artists vs. mainstream/established artists, platforms (especially Spotify vs. others) and platform issues, friend recommendations, live music

​

Pictured below is the confluence of indie/local/smaller artists vs. mainstream/established artists

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Additionally, a few small groupings emerged: small venues, playlists (custom vs. suggested), emotional responses to music, music media, miscellaneous issues, usage patterns

​

From my interviews, I learned that many users are interested in hearing and learning more about indie/local bands, but lack the time and resources to research them. At the same time, they’re heavy users of Spotify and other huge music platforms, but feel a sense of disconnect and even find them impersonal. Here are the key insights I gleaned from my research:

​

▸ Lots of people want to be more into indie/local music and friends’ recommendations, but have a hard time walking away from Spotify and other aggregation platforms

▸ Aggregation is the enemy of discoverability — big-name artists get momentum and quash the little guys

▸ Spotify is the Amazon of music — convenient and it has almost everything, except a soul!

​

My new problem statement was coming into focus. I thought there was a great opportunity to design for the key dichotomy (indie/local interest, but reliance on big platforms) by making an app for the little guys that’s as frictionless and intuitive to use as the mega platforms. Hence, my ultimate choice was an app around local music that makes it more prominent and easy to listen to.

​

I decided to call my app Local Beats, and added the tagline “playlists for music locavores.” I wanted to translate the idea of a locavore (from the food world) for the music world, focusing on local, organic, authentic, less commercial, small-scale sound. I conceived of the app as using location services to create playlists from songs that are location tagged, allowing users to find local music in their neighborhood or music from other chosen locations. My target user would be people active or interested in the local music scene who want to connect to the zeitgeist of a neighborhood/town.

​

Then it was time to start sketching.

​

Sketches

My initial sketches focused on key screens. In order for the app to work, it needed three essential components:

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

 

 

 

 

 

​

​

​

The first is a location screen, which tells the app where the music should be coming from geographically. The second is a genre/mood/occasion selector, which gives the user control of what kind of music s/he wants to hear. Finally, a third screen shows the confluence of the two in a playlist form. The page allows users to play and pause, and add songs to a playlist or delete them.

​

I then decided to build out as robust a navigation as was possible in about two days. I created 22 screens total, a menu bar, and a keyboard. Each screen except the login has a navigable menu bar at the bottom. In the middle of my design process I began to pay more attention to the back button, which I wanted to have as a navigation option in addition to the menu bar. Most screens have both features.

​

I then uploaded my drawings into Marvel and added 170 clickable links on buttons that were operable at this early stage. About half those links are attributed to the menu bar.

​

In addition to the screens listed above, I designed some additional functions: login, location (current, selected, or saved), permission, change radius, genre/mood/ occasion, additional genres, generated playlists, additional info, custom playlists, search, and settings.

​

Prototype

To see detail on each feature, and to test out my paper prototype, please click below.

​

​

​

​

​

​

 

 

 

 

To see my digital prototype (made in February, post-project), please click below.

​

​

​

​

​

​

​

​

​

 

 

Usability Tests and Resulting Iterations

With my prototype in hand, I started thinking about usability testing. I created a script with three scenarios:

​

▸ SCENARIO You just moved to Greenpoint, and are looking to get to know the neighborhood. It would be nice if you could hear some local bands.

TASK Open the app and use it to generate a playlist from your current location. Then hit play.

▸ SCENARIO You’re taking a trip to Sao Paolo in a few weeks, and a friend suggested you meet up at a restaurant that hosts live music. You’d like to impress her with some knowledge of the local music scene.

TASK Use the app to generate a playlist of music from the Vila Madalena neighborhood of Sao Paolo. Play any song. Then, find more information about the artist you’re listening to.

▸ SCENARIO You went to a fantastic live music event and want to hear more music from the band.

TASK Search for the band on the app. When you find one of their songs, add it to a new playlist. Then, view that playlist.

​

The goal was to test the logic of the navigation, clarity of copy and buttons, and the general ease of use. I recruited four interviewees and watched as they moved through the tasks, asking some general questions at the end to get insight into their thoughts and feelings about the app.

​

From my testing, I was glad to find out that the users were able to complete the tasks, almost always in their first try. I received positive feedback on my navigation, with the common theme that it was clear and easy to use, and that the buttons were similarly intuitive. I was relieved to hear that the basic functionality was sound, and that users liked how much of the app was built out for testing. I was glad I’d put time into the menu bar and multiple navigation paths.

​

I did also learn about a few confusing bits of copy users pointed out. The most prominent was differentiating “search” and “chosen location.” I’d built the search bar for finding artists’ names, albums, and songs, but it wasn’t clear on first glance that it wasn’t for finding locations. A user also pointed out that disambiguating “local music” would be important. I’d intended it to mean music made in a certain location, but someone else could understand it as music that was liked or generally listened to in that location. Finally, a user pointed out that the “go” button on the map screens was too much like physical navigation apps (such as Maps), and maybe wasn’t best for a music app that was simply referring to locations. These confusions are fairly easy to fix, and would further reduce friction points in the app.

​

In addition, several people suggested additional features. The most requested was a home screen, rather than the location screen that currently serves that purpose. Users also requested the addition of a social function like sharing or liking, and details about live music like upcoming concerts or venues.

​

Getting feedback on my initial designs was incredibly helpful, and I’m looking forward to using the insights to iterate on Local Beats.

​

Reflection

Throughout this first project in UX, I went from trepidatious to relatively confident in my design. It’s the first time I’ve gone through the full double diamond. I’d heard “trust the process” in class but hadn’t gotten to feel out the process for myself. I’m happy to report that the process really did support me. I found a problem — something I wasn’t at all sure I would be able to — and was able to design a mostly effective solution around it. This project really highlighted that I’m not the user, because the the app is for demographic I don’t really fit in, so it was especially gratifying that I was able to tailor to it to the target user.

​

I found the UX research phase to be methodical and high utility. Wireframing I found to be exhilarating; my favorite part was considering the logic of each screen, and building out a flow. Testing was validating for me, and I will say I was pleased to get such a positive result. I think for a first taste of design, I was glad to have the opportunity to build a relatively comprehensive set of screens for my app. Overall it was a very positive experience, and I’m looking forward to doing it all again!

​

List of Deliverables

Discussion Guide for user interviews

Research Report of insights from interviews

Affinity Map

Paper Wireframes

Clickable Prototype on Marvel

Usability Testing Script

Usability Test Notes

Presentation Deck

Case Study