Tuned was an attempt to change the way we listen to music. Nearly all music services have been built from the perspective of focusing on the individual listening experience, then eventually build social features on top of the platform. Tuned tried to flip the script - what happens if we build a music platform around the social listening experience first?


Group Size

3 members



About 4 months (early 2016)



• UI/UX design

• Building prototypes

• Creating specification documents and product roadmap


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.


How might we make music selection more democratic in social settings?


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.

We ultimately landed on the idea of using an upvote-based system to suggest songs and then vote on what songs you wanted played. Whatever song that had the most upvotes would be played, then removed from the queue. Once the song was up, the next most-upvoted song would be played and removed from the queue, and this would repeat until the party was completed. A single device connected to this queue would be used to actually play the music, while attendees would use their own personal devices to suggest songs and vote on songs currently in the queue.


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.

For the actual test, one team member created a small get-together in his dorm. He told people how the cards were supposed to be used, while another teammate was in charge of playing the music based on whatever was the most popular. This “Wizard of Oz” testing protocol was perfect as we were able to simulate what we would eventually want our software to mimic without ever needing to write a line of code. The results validated our idea: people were excited to have the power to get their music into the mix without directly punching it into the speakers. They were also happy to have tangible support in the form of votes: they could see their ideas validated by the numbers. Not only did we mitigate any conflict over the next song played, but we also instigated much more conversation directly stemming from the prototype. Interesting dynamics appeared - people began plotting together and recruiting others to get their song more votes, or suggested more songs to prevent other songs from playing if they saw one was getting more popular that they didn’t like. This would lead to more people coming to the voting wall, often strangers that just walked into the party. We were thrilled that our test added a social component to the party scene, a place that sometimes relies on drinking games to ease social tension.


Better yet, one user specifically announced to the room she was leaving for the night, then noticed her song was third in the queue. She then said “I was ready to leave, but I’ll stay just a little bit longer to hear my song, I’m so excited!”. Not only did we give people vested interest to participate in the party and talk with each other, we actually kept the energy alive when party-goers normally would have wound down.


Obviously, the test wasn’t perfect and could have been easily abused by someone who voted multiple times or “accidentally” erased songs from the list. But it was close enough for what we wanted to test, and was reaffirming that we were onto something that people might actually want.


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.

"Please upvote the Avril Lavigne song I just suggested - my friend will go nuts if she hears it!"



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.


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.


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.