TUNED

PROBLEM

The Tuned group came together as a group of three friends connected by the undergraduate Product Design program at Stanford University. We loved listening to music, discovering new artists, and sharing our favorite tracks with friends. When reflecting on this, we found that enjoying music often occurred in a social setting where one person has control over an entire speaker system. For example,  a team would share a speaker in their locker room, or a house would have a central speaker for events or parties. On the other end of those speakers was always a single phone.

The problem with connecting a personal device to a shared sound system is that bias always occurs when sharing music - someone who loves rap has a higher tendency to play rap, and the same happens with fans of other genres like EDM, alternative, or showtunes. That might not be a problem if everyone has the same music tastes, but in a diverse world with fluctuating moods and feelings, that simply doesn't happen. Moreover, with a single connection, this means it is nearly impossible for everyone to have the opportunity to share the music that they wanted to listen to. Frequently, we noticed that listeners that were disappointed with the music being played in their environment often felt tempted to (and in some cases, actually did) unplug the currently playing device and replace it with their own, creating a discontinuous stream of music that ultimately resulted in some bitter feelings between members of the same community. We wanted to tackle this problem and reimagine new ways music could be shared socially.

IDEAS

Our initial ideas came as a result from what we had heard when talking to music lovers, people who hosted parties on campus, and our own personal experience. From this initial exploration, we realized that the problem was fairly widespread. While many people felt confident about their music choices when sharing songs with a group, many felt reserved and downright scared about sharing their new favorite song with another person. Ultimately, it seemed this was a result of how personal music preferences are - people who were more reserved were afraid of playing a song they really liked, only to have it booed or rejected by those who were listening. Especially in a party-like setting, they didn’t want to be the person that played a song that wasn’t enjoyed, and would begin questioning their own music choices if no one else seemed to appreciate it.

We thought about having a feedback system that would allow for whoever was running the party to understand what songs people liked and which songs people disliked, so that whoever was DJing the music for a party could understand what kinds of songs should be played. This feedback system could be manual, or could be sensed automatically by using the accelerometers in the attendee’s phones to see if people were dancing to the beat or not. We also thought that there could be an app that was a “kill switch” app - if too many people disliked the song, the next song in the queue would play. However, we realized that there were ways we could prevent the bad song from ever being played to begin with, and that “killing” a song midway through would be jarring for those at the event and would likely destroy a DJ’s confidence.

PAPER PROTOTYPES

Realizing that developing an app would be expensive and take way too long, we tried to figure out ways of quickly testing our idea. We settled on paper prototypes that consisted of half-sheets of paper with a song field, an artist field, and a votes area for people to cast votes. We “laminated” these with packaging tape and put double-sided tape on the back of each card so that people could place them on the wall and easily move them around. People would use dry-erase markers to actually write on the cards, which could then be erased and re-used after the song was played. These prototypes were perfect for initially testing our idea and required less than $2 of materials and only about an hour to construct.

SOFTWARE PROTOTYPES

Given feedback from our first test, we were excited to test even more and try out different features. For our next test, we had a number of goals and decided to attempt a more digital prototype for a number of reasons:

• Test scalability - how would having even more people affect how our idea fared in a party setting?

• Test anonymity - would allowing people to use their own phone lead to different songs being suggested and more comfort in suggesting songs?
• Get more feedback - we knew that more feedback could only help us moving forward

We knew that we weren’t quite ready to build an entire app, but still likely needed something that was easy to distribute and get onto people’s phones. We found a web service called Bubble.io that was perfect for our needs. It allowed us to create a fairly robust web-app using mostly drag and drop components in less than an hour. A teammate in the group organized another party, and we set out to test our app again.

The users were a bit rowdier than in parties past, but that audience gave us our best insights to date. They broke the app in every way it could break. Once our users discovered they could vote more than once on a song, they began furiously finger tapping their way to corrupting the very nature of democratic music selection.  The party lost all of its momentum when the fastest tapper, one person whose fingers worked twice as fast as anyone else there, flooded the queue with classical music and show tunes. This quickly confirmed our hunch that every user should only vote on each song exactly once if they choose to vote, yet reaffirmed that the ability to control the music around them was something partygoers really wanted. All this unexpected voting caused inexplicable behavior in our app, like when votes reached higher than 999 votes, as we were unprepared to display a vote count that high. Essentially, the app fell apart. Even though it was more robust than a stack of half sheets, it was not engineered to work for 20 finger tap spammers.

Luckily, this audience was very vocal about feedback and what we could do to improve. A lot of their feedback matched with our suspicions about voting privileges and song suggestion mechanics. In our first software app prototype, we did not have the option to filter song inputs so one could enter anything into the text box, leading to hilarious descriptions of songs when someone didn’t know the title (Like “Happy Birthday” as performed by “Everyone”) or messages to the group as a whole.

Thus, our Bubble apps prototype was worked on further to address some of these issues. Now, people could only vote once on each song to prevent spamming. UI improvements were made to make it look more clean, friendly, and to encourage upvoting. We were quickly able to integrate with an iTunes API so that people could only suggest songs that actually exist. If a song was suggested twice, it wouldn’t add the song so that the queue was kept at a minimum. Lastly, we added an “Admin” side of the app so that we could easily remove the most popular song after it had been played so that it was always clear what was on the top of the queue.

With our new prototype in hand, we were ready to test our new prototype. We were actually contacted by someone who was excited about our idea to host an end-of-year party for the staff of a publication on campus. Using my laptop with a side-by-side view of both a Spotify playlist and the live queue from our app, we simply plugged into the speakers at the party and were ready to go.

This time, users were sent the link beforehand to vote on songs before the party even started. This allowed for a fairly long queue to develop before the first song had been played. Still, participation at the early stages of the event was not as high as we would have liked. However, once people knew that our system existed and heard a few songs, they got more involved. The social dynamics we observed in our first tests also began to appear in our most recent prototype - users continued to rally support for songs from each other that they wanted to hear. Yet one of the most intriguing observations came from a guest: “Please upvote the Avril Lavigne song I just suggested, my friend will go nuts if she hears it.” When we originally came up with the idea of Tuned, it had never occurred to us that people would suggest songs for not just themselves, but for their friends as well. This exciting development reaffirmed our desire to be an aid to a party, rather than a crutch that sucked people into their phones unnecessarily.

During this test, we took note of the music played in an attempt to understand what music people were suggesting. We were pleasantly surprised at how the kinds of music played at the party varied heavily and how it changed throughout the duration of the party. Interestingly, the party started with more electronic/EDM songs and as the party progressed, people started suggesting and upvoting a greater variety of different kinds of music, including throwback and country songs. We thought this was a result of people getting more comfortable with the system and suggesting music that they may not have otherwise suggested due to the anonymous nature of the app.

Using this feedback, we are more confident moving forward with development that our app will accomplish what we hoped for since the beginning. The early testing of our app allowed us to easily iron out the wrinkles in our idea before moving forward into native app development, where it likely would have taken longer to make changes. Even though they weren’t perfect copies of all of the planned features and functionality of our iOS app, these paper and web app prototypes were the perfect way to put our idea into users’ hands to test our idea.

UI/UX ITERATIONS

As these “works-like” tests were going on, I started imagining how this would actually look and feel like in an app. These “looks-like” prototypes were meant to add additional clarity to our ideas and figure out how the app would be structurally laid out.  I took the lead on the UI/UX design as this was my first foray into digital design and thought this would be the best way to learn.

The first iteration of the Tuned app consisted of a series of location based queues. Essentially, these were almost like radio stations. Our initial target audience was college campuses, and our thought was that each college campus would have its own style of music that it enjoyed. People would only be able to suggest and vote on songs in their own “zone” as determined by a radius around wherever they were currently located. Users would also be able to view other areas and tune into what they were listening to.

We realized from our feedback that people didn’t want a downvote option given how personal music was, so only an upvote “Like” button was included next to each song. Our original thought was to tap into multiple services so that people could add music from SoundCloud, Spotify, YouTube, or other services. We thought making the album art more prevalent would create more recognition for each song, so each song was given a fair amount of real estate. Lastly, we showed who suggested the song only for the songs that were actually played, since we knew that people wanted recognition for “good” songs but didn’t want to be called out for suggesting a song that people didn’t like and therefore wasn’t uploaded.

Feedback for these initial mockups was that the album artwork was given way too much real estate on the screen, so it was difficult to see all the songs that were currently in the queue. Only being able to “Like” songs was appreciated, but it was clear that the “Like” option was too similar to Facebook’s “Like” option and that the UI as a whole was a little too complicated and cluttered. Overall, I was happy with this feedback and it was a perfect learning experience to figure out how to design for mobile.

The second iteration of the UI took advantage of the realization that there were three main ways people listened to music socially. Thus, the app contained three main areas to facilitate these different scenarios: "Events", "Groups", and "Around Me".

Many times, it was event-based - this was essentially what we were testing in our in-person tests. These events were time based and location based, so users would only be able to suggest and vote on songs if they were invited to an event or if they were within a certain radius of wherever the event was taking place. Because everybody in a certain event was listening to the same song from the same set of speakers, songs that were at the top of the event were played and then removed. These queues were called “Events” queues.

Other times, people sent music they liked to friends through Spotify playlists, through YouTube links, or through text. This music was then either enjoyed individually, or compiled into a list that was played over the speakers at work or during a workout. These groups of people were connected through some kind of common interest, typically a sport, club, dorm, or friend group. Because people weren’t necessarily listening to the music at the same time, we wouldn’t want to remove the top song after it was played by someone in the group. Thus, the life of a song on a group queue was based off how long since it had been submitted. It would still collect upvotes just like songs in an “Events” queue. These queues were called “Group” queues.

Lastly, people listened to songs that were popular on their campus or in the local area, either shared through large groups or over radio. These often featured local artists or artists that were actually students. Thus, listeners were connected to each other due to similarity in their location, despite possibly not knowing each other personally. We wanted to address this situation, so we called this “Around Me” queues - queues that were defined by suggestions that were made within a few miles of your current location. Like “Group” queues, songs were removed after being on the queue for a certain amount of time.

MOVING FORWARD

After collecting this feedback, we decided we were ready to start thinking about the structure of our app and what it would take to make it real. I constructed functional requirements document that reflected what the most important aspects of our app was and what should happen in each area of the app. This was critical for when we approached different people and groups to figure out what it would take to actually develop the app.

After hearing back from six different companies and groups of people with quotes about the time needed and money needed to develop the app, development of a native app eventually stalled. This, paired with inconsistencies of the Spotify API for iOS and each member of our group graduating and moving into other job roles and opportunities, led to a halt in the continuation of the project.

Despite this, we were thrilled with all we had learned about the development process and in testing out ideas and getting feedback.