Community product concept
Concert Connect
Verification before matching
Research showed concertgoers wanted connection, but safety had to come before every match.
At a glance
Role, timeline, tools, and scope
Research and testing
41 survey responses, 7 interviews, and 7 usability tests shaped the concept.
The research changed the product direction: Concert Connect moved from matching first to verification first, and usability testing then simplified how the screens looked and read.
Research and testing volume
- 41survey responses synthesized
- 7user interviews conducted
- 7usability tests on the mid-fidelity prototype
As a concept project, the results here are design results: a reordered onboarding flow, a clearer split between community and private messaging, and a calmer visual system that testers could read.
The challenge
People wanted company at concerts but would not meet a stranger without proof of identity.
Our survey found that people shared music taste with close friends but often had no one available for a concert. Interviews added the context the survey could not: meeting a stranger felt risky, and participants wanted proof that a potential companion was a real person.
That made safety, rather than discovery or recommendations, the first problem to solve.
Constraints
Six weeks, a mid-fidelity prototype, and no way to test verification for real.
This was a six-week sprint with a small cross-functional team, scoped to a mid-fidelity mobile prototype rather than a working product.
Constraints we designed inside
- Six weeks from first survey to final presentation.
- No live prototype or backend, so identity verification had to be designed as a flow rather than tested as a real system.
- A general-purpose audience of concertgoers rather than a single validated segment.
- Established social platforms already covered discovery, which pushed us toward trust as the differentiator.
My contribution
I led the research and testing track and presented the work.
I wrote and fielded the survey, ran the interviews, synthesized findings the team could act on, and turned testing feedback into specific design changes.
What I personally owned
- Survey design and synthesis of all 41 responses.
- Interview questions and 7 user interviews.
- 7 usability tests on the mid-fidelity prototype, plus the findings write-up.
- The trust-first onboarding argument that reordered the flow.
- The final project presentation.
AI-assisted workflow
AI clustered survey responses; I checked every theme against the raw data.
- Tool
- A general-purpose AI assistant, used as a research support tool
- Task it assisted with
- Clustering open-ended survey responses, drafting candidate interview questions, and speeding up competitor scanning.
- How output was reviewed
- AI output was treated as a first pass only. Themes were checked against the original 41 responses before any of them informed a design decision.
- Limitations
- AI did not conduct research, run interviews, test the prototype, or design any screen. It saved time on synthesis and scanning, which left more room for testing and decision-making.
What I decided, designed, and verified
- I wrote the survey and chose which questions to ask.
- I reviewed every AI-suggested theme against the raw responses and rewrote or discarded the ones that did not hold.
- I edited the drafted interview questions before use and ran all 7 interviews myself.
- I made every design and prioritization decision, including the trust-first reordering.
My approach
Survey, interviews, prototype, then seven usability tests.
Six weeks, run in sequence, with each stage narrowing the next.
Survey
41 responses on how people find company for live music.
Interviews
7 conversations that surfaced safety as the real barrier.
Ideation
Sketches across onboarding, home, profile, and event calendar.
Design system
Shared typography, color, icons, and components so screens stayed consistent.
Prototype
A mid-fidelity mobile prototype covering the core journey.
Usability testing
7 tests, then a refinement pass on navigation and visual language.
Research insight
Interviews showed that safety, not lack of interest, was what stopped people from meeting a match.
The survey established demand: shared music taste rarely translated into someone available to attend a show. The interviews explained the gap. Participants consistently described meeting an online match at a crowded venue as risky, and they wanted evidence that a match was a real person before agreeing to anything.
Competitive review showed the category already handled discovery well. Nothing addressed the trust problem specific to attending a concert with someone new.
What the evidence pointed to
- Interest in concert companionship was consistent; availability was not.
- Safety concerns, not lack of interest, stopped people from meeting matches.
- Users asked for proof of identity before conversation, not after.
- General social platforms were the incumbent, so trust had to be the differentiator.
Key decisions
Verification moved to the front of onboarding, and the visual system got quieter.
Three decisions came out of the research and testing.
Move photo and ID verification ahead of matching.
WhyInterviews showed users needed proof a potential companion was real before they would consider meeting.
TradeoffVerification adds steps before anyone sees a single match, so onboarding asks for trust before it delivers value.
Keep community spaces separate from direct messages.
WhyPeople wanted to build familiarity in a group before committing to one-to-one contact.
TradeoffTwo conversation surfaces are harder to explain, and testing confirmed the toggle between them needed work.
Simplify the visual system and clarify navigation icons.
WhyTesters called the navigation icons confusing and the gradient backgrounds overwhelming.
TradeoffWe gave up the gradient-heavy look the team liked in favor of screens testers could actually read.
The final concept
Photo and ID verification come before matching, and community spaces stay separate from direct messages.
Photo and ID verification happen before personality and music preferences shape recommendations. Only after that do profiles show compatibility, shared taste, and mutual connections.
Community spaces sit apart from direct messages, so people can build familiarity in a group before committing to a one-to-one conversation. Home surfaces upcoming events by location, recommended communities, and recommended events.
Outcome
The team delivered a tested mid-fidelity prototype, not a launched product.
Seven usability tests validated the core journey and produced a specific list of fixes, which we applied before the final presentation. The project ended at concept stage by design.
What shipped at the end of the sprint
- A reordered onboarding flow with verification first.
- A refined navigation model with clearer icons and labels.
- A documented design system covering type, color, icons, and components.
- A tested mid-fidelity prototype and final presentation.
Reflection
A live prototype and event-day coordination would be the next real test.
A live prototype and real-time coordination notifications would be the next steps toward testing this as a product in the context of an actual event.
I would also want to test the verification flow with people who have declined to meet an online match before. That group would tell us fastest whether verification-first changes behavior or only changes how the product feels.