Concert Buddies

Matchmaking for Concertgoers

Overview

Concert Buddies is a mobile app prototype created for concertgoers to find like-minded individuals/groups to attend concerts with when their current friends or family are not able to. This prototype was created as part of an Interaction Design II class taught at Kennesaw State University. Our team loosely employed the Lean UX methodology detailed in the book Lean UX: Designing Great Products with Agile Teams by Jeff Gothelf and Josh Seiden to create this prototype.

The Pitch

Nia, our team leader, was inspired to develop our project after attending a TWICE concert in the summer of 2023. There, she met a young woman who, lacking friends with similar musical interests, had bravely decided to attend the concert alone. Nia and her group empathized with the woman's apprehension in the large crowd and welcomed her into their company, easing her worries. They spent the night dancing, singing along, and bonding over their shared love for the music. This unexpected connection sparked the idea for our project: an app that connects solo concert attendees based on their musical tastes and interests, allowing them to find companionship and alleviate the feeling of loneliness at concerts.

Role

UI Design, UX Research, Branding

Timeline

Sep - Nov 2023

Approach

Lean UX (Agile)

Tools

Figma, FigJam, Microsoft Teams

Role

UI Design, UX Research, Branding

Timeline

Sept - Nov 2023

Approach

Lean UX (Agile)

Tools

Figma, FigJam, Microsoft Teams

Matchmaking for Concertgoers

OVERVIEW

The Pitch

Nia, our team leader, was inspired to develop our project after attending a TWICE concert in the summer of 2023. There, she met a young woman who, lacking friends with similar musical interests, had bravely decided to attend the concert alone. Nia and her group empathized with the woman's apprehension in the large crowd and welcomed her into their company, easing her worries. They spent the night dancing, singing along, and bonding over their shared love for the music. This unexpected connection sparked the idea for our project: an app that connects solo concert attendees based on their musical tastes and interests, allowing them to find companionship and alleviate the feeling of loneliness at concerts.

The team

Meet the Ones Who Made It Happen

Click on the pictures to visit my teammate’s portfolios!

Spoilers!

A Sneak Peak of Our Solution

Concert Buddies tackles the common problem of wanting to enjoy live music but not having someone to go with. Its key feature is a matchmaking system inspired by popular dating apps like Tinder and Bumble. Users swipe through profiles of other concertgoers interested in the same events, allowing them to choose who they'd like to connect with.

For maximum flexibility, users can opt to see profiles of individual attendees or pre-formed groups, catering to both solo concertgoers and those seeking a larger crew. Additionally, customizable filters allow users to refine their search based on distance, age, and even preferences like pre-concert meet-ups. This ensures users connect with potential concert buddies who share their interests and vibe, creating a more enjoyable and social concert experience.

Interact with the prototype here

→

Prototype

Hold on. How did we get here? Let’s go over the process...

Click on a number to jump to the section.

The Approach

Learning about Lean UX

Sprint one

Creating and testing MVPs

Sprint two

Creating and testing more MVPs

refinement

Finishing and polishing our prototype

Week Zero

Making Assumptions

Week Zero in the Lean UX process typically refers to the initial phase where the design team comes together to align on the project's goals, define the problem space, and establish a shared understanding of the project's scope and objectives. We used this week to discuss the project vision and fill out our Lean UX Canvas.

Through in-person and virtual meetings via Microsoft Teams, we brainstormed and outlined key elements:

Business goals: What are we aiming to achieve?
Problem statement: What specific challenge are we addressing?
Potential solutions: What initial ideas do we have?
Proto-personas: Who are our potential users (based on assumptions)?

Product Problem Statement

The current state of location-based matchmaking has focused primarily on romantic encounters. What existing products fail to address is making platonic connections for specific events. Our product will address this gap by creating a platonic matchmaking system for people planning to attend concerts. Our initial focus will be on making sure users can match with people of similar concert interests/intentions. We'll know we are successful when our users successfully match with and meet up with their concert buddies.

Proto-Personas

Proto-personas are typically derived from assumptions and educated guesses about the target audience. They are not based on extensive research or data but are instead used to guide initial design decisions and hypothesis testing. As more information is gathered through research, testing, and iteration, proto-personas can be refined and updated to better reflect the actual users of the product or service.

Our assumptions led us to creating three proto-personas: Lila, Diego, and Ivy. Lila, representing a budget-conscious and sociable college-aged person, was our envisioned primary user. Diego was created to represent the older demographic, while Ivy was designed to mirror our wealthier users.

Product Backlog

To gain deeper insights into our potential users, we adopted an empathetic approach. We considered each persona's perspective and brainstormed their desired outcomes from the app. This led us to identify potential features that could address their needs.

By combining these user insights with our business objectives, we formulated eight hypothesis statements. These statements articulated specific assumptions about user behavior or product features, providing a clear and testable foundation for the design and development process.

We evaluated each hypothesis statement based on risk (potential impact if proven wrong) and value (potential benefit if proven true). This prioritization exercise resulted in a product backlog, visually represented on the right. The top half of the backlog, marked with stars, became the focus for sprint one, while the remaining items were planned for sprint two.

Weeks One & Two

Time to Start Building and Testing!

Equipped with a completed Lean UX Canvas and a defined sprint one backlog, we began building MVPs and prepping for user interviews. Every Tuesday, Thursday, and Saturday, our team held a fifteen-minute stand-up meeting on Microsoft Teams. These meetings served as a platform for our team lead to delegate tasks, and for everyone to collectively review the progress made since the last meeting.

My tasks during Week One involved the following:

Complete lo-fi wireframes of the Home, Sidebar, and Create New Group pages.
Complete 3-5 sketches of a potential brand logo.
Come up with ideas for a potential color palette and typography.
Recruit users aligning with our proto-personas for interviews (if possible).

My tasks during Week Two involved the following:

Complete a lo-fi wireframe of Advanced Filters and Settings page.
Complete a lo-fi wireframe of the match card.
Begin creating hi-fi components for the header, footer, buttons, and icons.
Recruit users aligning with our proto-personas for interviews (if possible).

Pictured below are some initial low-fidelity wireframes I created. These wireframes underwent further refinement through feedback from both teammates and users.

From left to right: Sidebar, Advanced Filters, Match Card, Concert Information, and Create New Group

Week One Interviews

We conducted three online interviews through Microsoft Teams. During the interviews, we asked our interviewees (pictured on the right) general questions about their music and social connection preferences. This encouraged them to discuss their expectations for a music-based matchmaking app, compare our app concept to existing options like Bumble, Tinder, and Hinge, and share their experiences with forming connections through music and social media.

Two interviewees additionally tested a low-fidelity prototype of our chat feature, focusing on the functionality of reporting and blocking users. This allowed us to assess whether this feature effectively contributed to a sense of safety, satisfaction, and control within the envisioned Concert Buddies experience.

Following each interview, our team held an Affinity Mapping session to analyze the key takeaways. We focused on identifying valuable insights from the interviewees' responses by asking ourselves: "What resonated most with us, and why?" This collaborative process led us to identify the following key points:

Knowing if attendees are interested in pre- or post-concert activities is important for users.
Users felt icebreaker prompts and non-concert related interests would aid conversation and connection.
Sharing Concert Buddies on social media wasn't a priority for users.
Users successfully used the report/block feature and appreciated its contribution to their sense of control within the app.
Users desired the ability to set age range and group size preferences for matches.

Week Two Interviews

Week Two's interviews took a different approach compared to Week One. We focused less on general questions about concert-going habits and shifted the emphasis to in-depth testing of our Minimum Viable Products (MVPs).

This shift stemmed from a mistake we made in Week One. We realized that spending too much time on behavioral questions, akin to those used in Goal-Directed Design interviews, weren't as insightful as directly observing user interactions with the MVPs.

Having adjusted our interview goals, we dove straight into MVP testing. Participants explored core pages like the home screen, messaging, and profile. We employed the "Thinking Aloud" method, prompting them to verbalize their interactions, feelings, and any potential issues they encountered.

These interviews uncovered the following insights:

Users didn’t particularly care to be recommended “trending” concerts. They preferred the ability to choose favorite artists and have their concerts be recommended instead.
The idea of followers and friend requests might incite bias when deciding on whether or not to match with someone (meaning, someone with less followers might be less likely to find a match).
There was minor confusion with the placement of the number 4 on the chat page.
Users wanted the ability to specify desired or unwanted behaviors in potential buddies (e.g., no smoking, no drinking).
Users highly valued the ability to filter by age, distance, and gender.
Users appreciated the concept of a time limit for initial message exchange.

Official Branding

In between all the user interviews, we established the official brand guidelines for Concert Buddies. These guidelines encompassed key elements like our logo, color scheme, iconography, typography, and spacing. This comprehensive foundation provided us with the ability to maintain a cohesive visual language during the transition from lo-fi to hi-fi wireframes in the next sprint.

Retrospective

Our sprint concluded with a one-hour retrospective focusing on three key areas: successes, areas for improvement, and what to try next. During the discussion, we identified a pattern in our initial interviews – similar questions and repeated MVP testing. Reviewing our affinity maps revealed consistent, if not identical, user responses. While valuable, this limited our ability to gather new insights.

To address this, I proposed prioritizing user feedback integration before expanding the prototype. This would prevent testers from encountering repetitive usability issues and commenting on the same features, allowing us to gather fresh perspectives in future iterations.

Week Zero

Revalidating Our Canvas

Beginning Sprint Two, we revisited our Lean UX Canvas to assess potential adjustments based on Sprint One learnings. We asked ourselves: "Did anything in Sprint One prompt us to rethink our initial assumptions?" Through careful consideration, we identified the following areas requiring updates: our business outcomes, proto-personas, hypothesis statements, and MVPs.

Updating Our Impact Metrics

In Sprint One, we initially pinpointed growth and customer satisfaction as our key impact metrics. However, as the sprint progressed, it became evident that measuring growth was challenging with our existing product features. Moreover, we recognized an issue in our hypothesis statements, where "growth" and "customer satisfaction" could be used interchangeably, leading to confusion.

To fix this, we decided to replace the growth impact metric with revenue. This adjustment not only provided a clearer and more measurable metric but also allowed for the creation of new hypothesis statements that aligned better with the characteristics of our target personas.

Adjusting the Proto-personas

We concluded that it made more sense to drop Ivy as one of our proto-personas. While acknowledging the potential value our product could offer to wealthier users, we recognized that individuals like Ivy might constitute a smaller user segment compared to others like Lila and Diego. We determined that prioritizing personas like budget-conscious college students and older demographics, who more accurately represented the majority of our potential user base, would be more beneficial in guiding our design and development efforts. This shift aimed to ensure that our resources were effectively directed towards serving the needs of a broader audience. Consequently, hypothesis statements specific to Ivy were also removed.

New Hypotheses, MVPs, and Sprint Backlog

With the previously listed adjustments made, we created an updated version of our product backlog. All remaining MVPs that weren’t yet created became our Sprint Two backlog.

Weeks One & Two

More MVPs and Testing!

Prior to our interviews in this sprint, our aim was to transform our low-fidelity wireframes into more detailed high-fidelity mockups. Thus, the primary focus during our standup meetings revolved around accomplishing this objective.

My tasks during Week One involved the following:

Create a hi-fi mockups of the advanced filters page, create new group page, tour information page, and match card
Help create components for the tour and artist cards on the homepage
Create components for Lila’s public profile view
Recruit users aligning with our proto-personas for interviews (if possible)

My tasks during Week Two involved the following:

Prototype a flip animation for Lila’s public profile component
Create a hi-fi mockup of Beyonce’s artist information page complete with a biography and upcoming tour dates
Make sure all components have component properties (if necessary)
Help teammates with using auto layout

To the right is the component I made for Lila’s profile as part of my Week One tasks. This component is designed for displaying user profiles, offering a slightly different layout compared to the match card. Its primary function is twofold:

Viewing matched profiles from the messaging tab: Users can access detailed profiles of their matches directly from the messaging interface.
Viewing your own profile as others see it: This allows users to understand how their profile appears to potential matches.

The component, on the left side of the image, consists of various customizable elements (called “properties”) like text, icons, and images. Two examples of profiles built using this component are displayed on the right.

Lila's profile: As the logged-in user, Lila can access her public profile through the "view public profile" button on the edit profile page.
Sin Dizzie's profile: This profile belongs to another member of a group chat Lila participates in. It becomes accessible when clicking on the "share profile" or "report" buttons within the chat and then selecting the specific user's name.

Component

Profile cards made from the component

Week One Interviews

We welcomed two new interviewees this week, along with Heather, who previously participated in Sprint One Interviews. While we sought fresh perspectives, Heather's insights from Sprint One closely mirrored our proto-persona Diego. Curious about her interaction with the app, we invited her back for another interview.

Our questions for our interviewees mainly revolved around how they felt about the app, with specific emphasis on what they liked/disliked. We uncovered the following key points from the interviews:

Our UI choices were pleasing to look at.
The time limit rings under the match queue on the messages page was confusing until their purpose was explained. After the explanation, they felt that they liked that feature, but wanted the app to tell them what that ring meant (either during onboarding or after a match).
The ability to compare ticket prices or have a button linking to ticket vendor sites on the Concert Information page was preferred.

Some screens we tested during Sprint Two. From left to right: Concert Information, Messaging, Match Card, and Edit Profile

Week Two Interviews

Originally, we planned to invite Cincinnati back for a second interview, as he only saw the low-fidelity wireframes in the first session. However, unforeseen scheduling conflicts prevented his participation. Due to time constraints, we opted to interview Heather for a third time.

In retrospect, we recognize that this was not the optimal choice. While Heather provided valuable insights throughout the process, the design evolved minimally between her interviews, limiting the scope of new feedback. Bringing back someone else or introducing a new participant would have likely yielded more diverse perspectives and enriched our understanding of user needs.

Despite this small hiccup, our interviews uncovered the following new key points:

Participants felt all current features were exactly what they would expect when using an app like Concert Buddies; they had no suggestions on what functionalities should be added or removed.
Top Five Artists on the match card and profile should show the artists’ names and not just their pictures.

cleaning and polishing

Making Things Pretty!

During the refinement phase, our focus shifted to polishing the prototype for our class presentation. This meant ensuring meticulous file organization, with clear and consistent layer names. We also rigorously inspected spacing across screens, guaranteeing adherence to the established style guide.

Simultaneously, we incorporated valuable feedback from our interview participants, iterating on the UI to enhance its effectiveness. The following examples illustrate the evolution of key screens:

Home page

Edit profile

Match card

after the project’s completion

Improving Our Aesthetics

In an effort to modernize and enhance the visual appeal of Concert Buddies, I revisited the prototype a few weeks after the semester ended and made some aesthetic adjustments. Primarily, I focused on simplifying the color scheme, believing a black and white base with one accent color aligns better with current design trends compared to our initial approach using six different colors. Additionally, based on feedback from friends, family, and other classmates, the salmon color was toned down to reduce its visual dominance, and the cream color was replaced with pure white for a cleaner and more unified look.

Below are a few examples of the changes I made.

Home page

Match card

Successful match screen

The Final Product

Introducing Concert Buddies

Concert Buddies is an app designed to make sure no music enthusiast attends a concert alone. Say goodbye to the challenge of finding someone in your circle of friends who shares your taste in artists. Concert Buddies employs a matchmaking system inspired by popular dating apps like Tinder and Bumble. Users have the flexibility to filter preferences, choose interests, select favorite artists, and explore upcoming concerts. Whether it's connecting with an individual or forming a group, our user experience is tailored to be as customizable as possible. We're dedicated to helping users discover their ideal concert companion for a more enjoyable and shared musical experience.

You can interact with the full prototype in the window below ↓

Reflections, Reflections

What Did I Learn?

A well-defined design process starts with clear guidelines, minimizing inconsistencies and streamlining workflow. While we've encountered both successes and challenges in implementing this, it's essential. Deviating from these guidelines significantly extends project timelines, hindering our fast-paced environment.
Second-guessing can stall progress. In the dynamic world of Lean UX, I've learned to trust my judgment and make confident decisions. This isn't about impulsivity, but fostering assertiveness to keep projects on track.
Adaptability is key. Designs, even those favored by the design team, might not always resonate with users. We must be prepared to adjust course when necessary, prioritizing user needs.

A Challenge Faced

While enrolled in Interaction Design II (the class this project was created in), I also took Prototyping II (or Advanced Prototyping). This course heavily emphasized the importance of the 8-point grid and auto layout in user interface design. I was eager to apply this knowledge to our project. However, as the only Prototyping student in our team of four, explaining these concepts comprehensively within the timeframe proved challenging, particularly with auto layout.

Unfortunately, our final design doesn't fully adhere to the 8-point grid or utilize auto layout to its full potential. While I assisted teammates with auto layout, balancing this with creating hi-fi mockups and iterating based on user feedback limited my ability to address every screen without it.

Moving forward, I'll inquire about my teammates' familiarity with the 8-point grid and auto layout early on. This will allow me to provide relevant resources and assistance before diving into project specifics.