<- Return to Portfolio

ConcertBuds: A Social App for Concert Goers

Concert-goers often want to meet up with others who have the same music taste to go to live performances together, but do not have any convenient, reliable way to do so.

ConcertBuds connects you with fellow concert-goers who are taking a similar route to the venue so you can plan meetups, share the ride, and start the party on your commute! Our app focuses on fostering real life interactions and building community. Primarily designed for solo concert goers, users can see and chat with other people going to concerts and find shared routes to venues on public transportation. By fostering meetups on public transportation, we promote sustainability and personal safety while designing for fun.



Need Finding For this class, we were under the broad guise of “design for movement.” We needed to find solutions to people‘s needs in the movement categoy, and so we chose to narrow in on public transportation. To better understand users’ pain points with public transportation systems in the Bay Area, we decided we would interview people on the Caltrain. On a Saturday morning in September, our team members boarded the northbound Caltrain at the Palo Alto station. We spoke with 9 riders on the Caltrain and an additional person in San Francisco upon arrival to the city. We found that because riders were eager to share their experiences and had nothing to do as they rode the Caltrain, it was surprisingly easy to recruit participants.

We approached interviewees in pairs with one person taking the lead on interviewing and the other responsible for note taking and/or recording. We introduced ourselves and ensured that interviewees felt comfortable and at ease before continuing with pre-written questions. We allowed the conversation to flow naturally, following inquiries and curiosities we had about participants’ answers.

Our Caltrain participants ranged in age from mid 20s to late 60s. Some of these interviews did not yield many tensions, but there were several that did. For example, we met Michelle, a mom with kids in tow, who expressed reservations about bringing children on public transportation due to safety concerns and not wanting to bother other passengers with young children. Crowds intimidated her, and it was another layer of stress to bring her children into the mix. We also met Tanvi, a dentist living in SF and a first time Caltrain rider, who revealed herself to be skeptical of autonomous transportation options, such as Waymo. She expressed to us that “technology is too involved in mundane tasks.” We talked to John, an NBC Universal sports executive, who felt that even though he was outgoing, the social norms of public transportation dictated that he shouldn’t talk to strangers on the train. As he described, “I’m quite gregarious but I don’t feel the need to talk to people while I’m riding the Caltrain.”

We asked these interviewees about their relationship with public transportation: how often they use it, what they do to entertain themselves, what excites them about public transportation, and what causes them pain. We asked questions to get at specific memories, like “do you remember the first time you took the Caltrain” or “do you have a memorable experience on public transportation.” We asked about the tools the participants used to plan their route and whether their experience as a passenger had changed over time. We ensured to let the conversation flow and follow inquiries/curiosities that arose during the course of the interview.

After synthesizing our 9 Caltrain interviews (and 1 SF one), we still felt our scope was too broad. We didn’t have a specific direction or idea, and so we decided we needed to further refine. So, we recruited two additional interviewees: one from the Palo Alto Peets Coffee and another is the head of the Stanford Transportation Club. We wanted to narrow in on how we could improve the transportation experience via entertainment channels.

Our conversation with Istvan, a product manager at Oracle, at the Peets Coffee proved to be the most fruitful. We went in with an intention to get more emotional and intrapersonal responses. This interview lasted much longer than all the others, and so there was time to probe into his relationships with others, his future predictions for technological change, and his nostalgia for the past. During this interview, we learned about Istvan’s strong desire to connect with others, especially through music. He expressed frustration over wanting to go to a concert but having no one to go with.
Empath Mapping: In order to synthesize the many hours of interviews and pages of interview notes, we got together as a team to create empathy maps for our standout interviews. Each individual participant got their own empathy map. For each map, we outlined different things our participants said, did, felt, and thought in four distinct quadrants. Below are example empathy maps for Michelle, Tanvi, and John.








Through the empathy mapping process, we discovered insights such as: public transportation systems in the Bay Area are very disconnected, entertainment on trains is important for parents travelling with children, and safety/convenience features, like monitors and intercoms, were essential to an easy ride. However, these felt like issues too broad to tackle. That’s why, after talking to Istvan, we realized we could focus on transportation as a means to an end goal. We wanted to think about the entertainment experience and how transportation could play an important role.




POVs and Experience Prototypes
In synthesizing our interviews, we created POVs for our most important interviews: Michelle, John, and Istvan. After POV creation, we brainstormed “How Might We’s” (HMWs) to critically analyze tensions discovered in our interviews. Our HMW generation was done in rapid fire to get a vast set of ideas. We then combed through our HMWs to extract 2-3 of the most promising ones.

Below are our standout interview POVs:


POV #1: Michelle

       We met… a mother riding the Caltrain with her two toddlers.

       We were surprised to realize… that she often takes the Caltrain with her family on the way to weekend events, but is still overwhelmed on public           transit when it is crowded.

       We wonder if this means… she is anxious about losing her toddlers and crowds make it difficult to keep them safe

       It would be game changing to… ease her anxiety about traveling with children in crowded public transportation


Questions for Michelle...      

  •        How might we make the commute with her kids less stressful?
  •        How might we reduce the feeling of unease on crowded public transportation?
  •        How might we engage/distract her kids?
  •        How might we make public transportation feel cleaner/safer?



POV #2: John

       We met… a gregarious Bay Area fellow who takes the Caltrain for his commute to work

       We were surprised to realize… he acts antisocial in his commute.

       We wonder if this means… that the design of public transportation fosters this behavior.

       It would be game changing to… remove/mitigate the feeling of isolation while traveling on public transportation.


Questions for John....

  • How might we make commuting socially robust rather than isolating?
  • How might we remove/reduce the stigma of talking to strangers on public transportation?
  • How might we create social environments through design?
  • How might we foster connection during a commute?



POV #3: Istvan

       We met… a middle-aged man from Hungary who enjoys going to coffee shops alone

       We were surprised to realize… even though he enjoyed going to concerts with his daughter in the past, he feels sad that he doesn’t anymore

       We wonder if this means… he would be more inclined to go to a concert with a new friend to experience nostalgia

       It would be game changing to… bridge the generational divide by helping older generations feel comfortable going to live entertainment


Questions for Istvan....

  • How might we connect him with people who have similar interests?
  • How might we bridge the generational divide in going to live
  • entertainment events?
  • How might we make social outings feel more worthwhile to a middle
  • aged, working adult?


After thinking about the problems facing our interviewees, we decided the most motivating questions were:
  • HMW make commutes socially robust rather than isolating?
  • HMW make social outings feel worthwhile to someone who doesn’t know of anyone else to go to social events with? 
  • HMW help bridge the generational divide in attending live entertainment?


With these questions in mind, we began to brainstorm possible solutions to these problems. Our 3 standout solutions include:
  1. What if we create an app where people can meet others nearby to commute with to shared destinations?
  2. What if we made a trivia or action game for users nearby each other on transportation to compete in fun digital games against each other (regardless of age) and get rewards?
  3. What if we made commuting worthwhile for users by asking them to upload before and after photos with each other as a sort of promotion for the event and in turn get discounted tickets.


In order to test our solutions, we created experience prototypes. For the first solution, our experience prototype involved making posts on various social platforms (Nextdoor, Fizz) asking whether anyone in the area would be interested in attending a concert with one of our team members.

   
Prototypes to test solution #1  on Nextdoor and Fizz


Through this experience prototype, we were testing the assumptions that existing apps are too broad to fulfill the niche need we found in our needfinding interviews and that people want company to attend fun events but may have no one to go with. Our experience prototype reinforced our assumption that existing apps are too broad for this, in that we didn’t receive many responses because we were using apps with broad utility. We also believe that there was not enough time for our posts to rack up a meaningful amount of interactions, and that a Weezer concert may have been too specific of an event to attract a Palo Alto audience. We also believe that because these apps have such a broad audience, users of these apps may be hesitant to meet up with strangers. Overall, this experience prototype did support our belief that current location-based apps (i.e. Nextdoor, Fizz) are ill-equipped to fulfill the need to meet others in the area with the purpose of going to a concert together.


For our second solution, we approached strangers on public transportation for a game of rock, paper, scissors as our experience prototype. With this experience prototype, we were testing the assumption that people are often bored and lonely on public transportation and a friendly game would help those fearful of breaking the stigma of socializing with strangers on public transportation. We received a range of responses, including those who were eager and excited to play a game against one of our team members and those who flat out rejected the offer. Ultimately, we saw that there was indeed a desire for some to socialize and engage with others on public transportation through lighthearted game play. However, not all people held this belief. From this experience prototype, we believe that it’s easier to break the stigma of talking to strangers on public transportation when people are able to establish initial trust and rapport through lighthearted gameplay. Though this experience prototype showed the greatest support for our hypothesis, we ultimately decided that developing a smartphone game to play with others while on public transportation would be outside the scope of this class.

For our third solution, we tested our assumptions that taking photos and sharing recorded memories is a good incentive for making meaningful connections, commuting with others is better than commuting alone, and it’s all about the journey rather than the destination. We created an experience prototype whereby one of our team members held up a sign that read “Are you going to [insert name of place]” in a common space. Any passerbyers that approached were asked whether they wanted to walk together to a destination, and, at the end, were asked to take a selfie together. We found that most people did not acknowledge nor approach the sign. People were also reluctant to share an individual selfie but were much more excited by taking a picture together with the sign holder. Due to these results, we hypothesized that it is more encouraging to take photos with others when it is for the purpose of memory-sharing. We also learned that people are less likely to share a picture of themselves with people they don’t yet know. The results of the experience prototype showed that some were willing to walk places with strangers and get to know each other, but that photos of the event were less appealing.

The SolutionOur final solution was ConcertBuds, a smartphone app that connects nearby concert-goers who are going to the same show on a shared commute so that the concert going experience could be social and fun for those who have no one to go with. This was primarily inspired by our interview, POV, and HMWs from Istvan where we saw a need for concert goers to connect with one another. Our experience prototypes confirmed to us that people want to be entertained while commuting and are happy to meet up with others, strangers or not, on a shared commute.

The intended audience is anyone who attends concerts and wants to find other people to go with. However, those who are not technologically savvy and solo concert-goers who live in isolated areas and therefore do not share a commute route with others who are attending the same event.

There are inherent privacy implications due to the location-based nature of the app. There are also safety concerns with regards to meeting up with strangers, though these are reduced by meeting up on public transportation which is inherently in the public eye. Our app has the potential to perpetuate systemic biases as well, due to the nature of having profile pictures and names attached to users’ profiles.

Designing Task Flows

In order to begin designing the app, we had to determine the primary user tasks. These tasks were split into simple, moderate, and complex tasks. Below is a sampling of task flow as designed on Figma.

Simple Task: Users can search for a concert using a location based search and RSVP to any concert. Once RSVP’d, users can see other ConcertBuds who have RSVP’d to the same event. This is the simple task because it will be the most commonly used feature of the app and is required in order to complete both the moderate and complex tasks.




Moderate Task: Users can connect with others going to the same concert by joining the group concert chat or individually chatting with other users listed on a concert’s RSVP page. This task is accessible once a user has RSVP’d to a concert. If a user chooses an individual profile on the RSVP page, they can direct message that individual. They can also join the bigger group chat of all ConcertBuds who have RSVP’d to the event.




Complex Task: Users can plan their commute to the venue and connect with other users on a shared commute. On the navigation bar at the bottom of the screen, a user can plan a commute to one of their RSVP’d concerts. They can input their location and planned arrival time as well as their preferences on what types of public transportation they want to use (i.e. bus, train, subway, etc…). The app then plans a commute for them based off the given information and checks to see whether other RSVP’d ConcertBuds will be sharing a similar route. If so, these ConcertBuds are connected along their shared route so they can meet ahead of time and share the commute to the venue.



Low Fidelity Prototype

We first created a low fidelity prototype on an iPad so that we could iterate our app quickly and efficiently. We sketched out our simple, moderate, and complex task flows as shown below.

Simple Flow



Moderate Flow


Complex Flow



Usability Testing
With these low-fi prototypes of our three tasks, we set out to do some usability testing. Some members of our team recruited people on Stanford’s campus (no students) while another member tested the low-fi prototype in San Francisco. We asked each participant to complete one or two tasks and then had them reflect on their experience using the prototype. We also made sure not to provide any guidance on the app’s usability/functionality since we wanted to ensure that the app was intuitive. If participants were confused, that would help us understand what functionality was not intuitive.

Before testing, we outlined usability goal posts to focus on, including time it took a user to complete a task, whether the interface was intuitive with visual cues and uncrowded, how curious each participant was to explore the app by joining chats or planning commutes, and lastly the number of errors or misclicks a participant made.

We aggregated our findings from our participants (Jason, Janelle, Sarah, and Ben):
  • Generally found the functionality intuitive
  • Confusion/hesitancy surrounding the motivation behind our moderate task, specifically in joining group chats
  • All participants were pretty quick in completing tasks
  • Didn’t understand why we included a “maybe” button on the RSVP page
  • Wanted a visual cue of the marked RSVP status
  • Thought that a status page with all planned concerts on the homepage would be helpful for users
  • Confusion about “ETD” (estimated time of departure) label on complex task
  • Confusion surrounding the “swirly button in the top left” (our settings button)

Ultimately, we found that our participants had confusions around the RSVP and group chat features. There was also a desire for additional features that our three tasks did not incorporate. There were only 4 misclicks across all participants, but everyone quickly completed the task flows. For each participant, the simple task was the easiest to navigate and the moderate and complex tasks were more difficult due to ambiguities with the buttons. We found that the social features of our app (i.e. the chats) were most engaging to our participants. Many of our screens looked too similar for their different functionalities, leading to confusion. Through our low-fi usability testing, we were able to catch common mistakes that were much easier to fix going forward than they would have been if testing on a medium or high fidelity prototype.

Regarding our medium fidelity prototype creation, we wanted to focus on:
  • Updating the RSVP functionality
  • Adding back buttons and ways to undo actions
  • Differentiate between the goals of finding ConcertBuds and joining a group chat
  • More visually intuitive navigation bar

Before building our Medium Fidelity prototype, we updated the low fidelity iPad drawing prototype to implement the discussed changes.


Medium Fidelity Prototype
Our medium fidelity prototype was built using Figma. Below are snapshots of completed task flows.


Medium Fidelity Prototype










After building our medium fidelity prototype, we completed a thorough heuristic evaluation of our product using the Nielsen Heuristic test. We found 79 violations and evaluated each one to determine the appropriate action (if deemed necessary) to fix the violation. We mainly focused on heuristic violations that had a severity of 3 or 4, as these were the most severe categories, therefore deserving the most attention.


Severity 3 Violations Summary:
The below summary only captures violations we felt were justified and thus implemented changes to our prototypes based off the violation feedback.

  • [H1]
    • Users don’t know how to populate upcoming shows
      • Fix: We included a text prompt on the home screen below the search bar that says “You upcoming concerts will show up here.”
    • No way to know whether “Going” or “Interested” has been selected
      • Fix: We removed the “Interested” option so that there is only an option to select “Going.” We felt the “Interested” button didn’t enhance our app functionality or experience.
  • [H2]
    • “Create route” icon is a mismatch with its intended functionality
      • Fix: We changed the icon to instead be a map icon.
  • [H3]
    • Back button on route planning has wrong functionality
      • Fix: We implemented the correct functionality on our medium fidelity figma prototype.
    • No way to undo RSVP
      • Fix: We added the ability to undo an RSVP by clicking the “Going” button again, which reshades it to the original color and marks a user as no longer going.
  • [H4]
    • Different home and icon button used between pages
      • Fix: We made our icons consistent across pages.
  • [H5]
    • No error checking if clicking a route that conflicts with concert timing
      • Fix: We added error checking in the high fidelity prototype.
    • No indication that a user joined a large chat
      • Fix: The “Join Chat” button takes a user to the chat and joined chats are saved and can be accessed from the toolbar.
    • No obvious difference between “Interested” and “Going”
      • Fix: We removed the “Interested” option.
  • [H6]
    • No preview of how many ConcertBuds are going
      • Fix: We included the number of RSVP’d ConcertBuds on the ConcertBuds page once a user has RSVP’d to a show.
    • Tour dates don’t include day of the week
      • Fix: We included a day of the week in the tour information.
  • [H8]
    • Add photo of artist to make visuals more interesting
      • Fix: We added a visual of the artists tour from the TicketMaster API when RSVPing to a concert.
  • [H10]
    • No estimated route time
      • Fix: We included an estimated route time.
    • No explanation of different route colors on map
      • Fix: We made the color differences obvious by encircling a ConcertBuds profile in a circle that matches the color of their route on the map.
  • [H11]
    • Genre tags lack contrast
      • Fix: We enhanced the contrast.
    • No alternatives to visual map icons
      • Fix: The google maps API has visual alternatives.
    • App relies on color for RSVP statuses
      • Fix: We removed color as part of this functionality since it was unnecessary.
  • [H12]
    • No way to report chats
      • Fix: We included an information icon in chats that allows you to report other users in the case of abuse.


Severity 4 Violations Summary:
  • [H1] There is no indication if other user accepted shared route
    • Fix: We added a text prompt that pops up if other user’s accept the route
  • [H6] The text on the top of the chat page is just “chat”
    • Fix: We renamed chats to be specific to the concert in question (i.e. “Billie Eilish Chat”)
  • [H12] No safety features visible while finding concert buddies
    • Fix: We included an information icon on the chat pages that allows a user to report another user for abusive conduct. 
  • [H2] “We you found 2 ConcertBuds” uses unnatural language
    • Fix: We fixed our typo!


High Fidelity Prototype
After incorporating design changes based on feedback from the heuristic evaluation, we began to build our high fidelity prototype.


Notable changes we made included darkening the background to increase contrast with white text, adding a trash icon to un-RSVP to a concert, and more features (e.g. leave a chat) feature on the chat. Below are some screenshots of the various task flows using the final product.

Simple Task:


Moderate Task:




Complex Task:





Profile Page:


Values in Design:
The core values guiding our design of ConcertBuds: playfulness, inclusivity, simplicity, personalization, and community oriented. Throughout the design and iteration process, we kept these values at the forefront of our minds as they reflect the internal motivations for our features.
Playfulness
Our app is inherently geared towards fun, as live entertainment events are just that. We wanted our design to reflect this playfulness and fun through our color palette and visual aesthetics, which have an vibrant and ambient vibe.

Inclusivity
It was imperative that our app be inclusive to all people, regardless of demographic characteristics. We made sure that, though our aesthetic is fun, we didn’t alienate anyone by making it feel “too young.” All people are encouraged to use our app and meet up with other ConcertBuds. Because our app is primarily built around public transportation, it also encodes economic inclusivity.

Simplicity
We opted for a more bare-bones, intuitive design that would be simple to use and navigate. This value supports our other value of “inclusivity” as it allows ease of use for all generations. We encoded this value into our design by using as few icons as possible while still enabling a user to easily complete a task, and by choosing icons that are widely recognizable.

Personalization
Our app allows users to customize their profiles, input preferences for potential ConcertBuds matches, and keep track of their upcoming shows. Personalization is critical to our app design since it matches strangers together, and for safety and personal reasons, users should be able to customize the type of people they want to meet up with by sex and age.

Community Oriented
The goal of our app is all about creating connections and building community. Because users are matched with others’ along the same route, it inherently fosters connection between people who live near each other, or are part of the same community. This value is encoded in all of our tasks, where you can view other people going to the event, chat with them, and plan shared commutes.



Tensions in Design:Personalization and inclusivity are inherently at odds with each other because personalization is catered to an individual’s needs whereas inclusivity appeals to a broad spectrum of people. We attempted to balance these values as much as possible by allowing some personalization that we thought was necessary for safety reasons (i.e. age and sex of ConcertBuds matches) while limiting it to just the essentials.

We also found there was some tension in our values of playfulness versus inclusivity. Playfulness is somewhat subjective based off of generational preferences, and as designers in our early 20s, we recognize we likely embedded play into our design in the way that we perceive it to exist. This may not wholly translate to other generations which may seem playfulness embodied differently. However, our stripped back design helps compensate for this by appealing to a wide variety of people.


Final PrototypeAll code is written in React Native on Expo Go. Ticketmaster API was used for searching/fetching the information on upcoming concerts. Google Maps API in the Google Cloud Console was used to display a live map as well as to fetch routes to a concert. For pixelated avatars, we used the xsgames random users API. Supabase was used to authenticate and store profiles as well as information on user’s concerts and to manage chat message data. AI tools used included ChatGPT and Claude AI.

What Next?
We would firstly want to reiterate on our current draft of reporting features and implement robust safety features, perhaps using AI facial recognition to confirm identities and chatbots to moderate chats.

Regarding safety – based on our feedback in studio and in reviewing expert judges' feedback at the CS147 Expo, we acknowledge that safety may be a concern for users, especially for women using our application who have their own right to be concerned about meeting others on our application. To reduce their worry and concerns, we could introduce preferences for age, gender, and proximity in addition to ensure users on the platform have an enjoyable, fun experience without worrying about harm.

In our medium fidelity prototype, we discussed implementing a feature that would allow a user to sync their contacts so that there’s a possibility of matching with friends or mutual friends for shared commutes. Because of the tight timeline of this class, this feature was not able to be implemented. It also wasn’t necessary for any of our three tasks, so we chose to exclude it.

If possible, we would want to implement a custom made algorithm to match ConcertBuds that we think would be compatible. This could be based on user data and user preferences, such as their listening habits, past shows, age, gender, and proximity.

Technical next steps include utilizing AI in our matching algorithm to optimize the groups and routes of users. For our complex task, we would implement the BuddyChat which is a chat that users who are matched together can join and communicate in to get their commute started. Then, within each chat, we would implement a more robust info control icon: when clicking, a user would be able to visualize and have other user profiles accessible to them and be able to report them in each chat for community chat moderation and safety. For more accessibility, we would engineer the ability to view past concerts in the profile page for users to reminisce and appreciate their experiences with other ConcertBuds. Lastly, for production, we would implement a minimal and aesthetic, at-minimum 2-page signup and signin process that uses supabase’s build in authentication protocols.