Two sides of one night out

Finding something to do in Toronto means checking too many event hubs, and when a group does find something, the plan dies in the group chat. On the other side of the door, smaller venues book nights without knowing what people want. Sidequest turns individual tastes into shared plans, and turns what people ask for into signals hosts can act on. Our north star: "Connecting users to other like-minded people through worthwhile events in their area." I led the team and the product: the research framing, the positioning, the flows and features for both sides, and how we'd measure success. I made the low-fi wireframes and the design system the screens are built on.

Problem

Event info is scattered, friend groups can't agree, and hosts guess at what people want.

Deliverable

Product strategy, flows and features for attendees and hosts, the low-fi wireframes, the design system, and a 70-screen team prototype.

Tools & timeline

Figma, Claude, Claude Code, GitHub, Render

Sept to Oct 2026 · U of T team project

Outcome

• 70screens in one team prototype, attendee and host journeys connected end to end
• 4product decisions, each answering a barrier from research
• Oct 22midpoint, presented to guests and professors

No usage results yet. Peer usability testing with about four teams and interviews with two or three venue bookers come next.

Context

Three people, one Friday

We designed for two user groups. Attendees come solo or as a crew, so they need different things from the same app. The host side comes from industry research; host interviews are still to come.

• Solo attendees

  New to a scene or a city. Want to find their people without scrolling five apps.

• Crews

  Two to six friends with different tastes, budgets and starting points. One person usually does the planning.

• Hosts

  Venues, promoters, collectives and community groups. Book nights before they know who'll come.

Problem

Three barriers between interest and going

Our two interviews pointed to the same three barriers: cost, whether friends are in, and getting there. The last three steps below are where a night out dies.

1. 01Hear about it on Instagram
2. 02Screenshot it to the group chat
3. 03Too far or too pricey for someone (where it breaks)
4. 04Nobody decides (where it breaks)
5. 05Host plays to a half-empty room (where it breaks)

Discovery

What we heard, and what it changed

• “Like the ticket sells like $200. Oh no, that's a big no.”

  Participant 2, film festival-goer

  What it changedBudget is a hard filter. A crew's budget is the lowest anyone set.

• “I need to take TTC, then go train, then Uber. That will be a lot.”

  Participant 2, film festival-goer (TTC: Toronto Transit Commission)

  What it changedEvery pick shows trip time and transfers, for each person in the party.

• “it's usually based on if your friends are interested”

  Participant 1, Fan Expo-goer

  What it changedCrew Blend and the party vote: one place to see what everyone's into and lock it in.

Two attendee interviews and no hosts yet, so the host side is still a hypothesis.

Constraints

The rules we matched by

• 2user interviews: a Fan Expo regular and a film festival-goer
• 15products in the competitive analysis: discovery, ticketing, group planning, messaging

• Never pick by chance

  • For a group, a night everyone enjoys beats one person's perfect pick.
  • Each pick says why, per person.

• Budget and travel first

  • Nothing over budget or too far is ever shown.
  • A crew's budget is the lowest anyone set.

• Be honest about gaps

  • If nothing fits, say so.
  • That gap becomes a signal for hosts.

• Count what happened

  • Only a "yes" to "Did you go?" counts.
  • No ticket sales: we link out.

Landscape

Who else is in the room

From my competitor analysis. Inspiration: Radiate (event group chats) and Wander.

• Motivez

  Toronto group plans, but picked by a dice roll.

• Fever

  City guide and tickets, no group taste.

• DICE

  Music taste from Spotify, no host demand data.

• Eventbrite

  Where hosts already list, so a partner, not a rival.

Structure

Four decisions, one loop

We answered the barriers with four product decisions: combine the group's tastes and constraints instead of sharing separate picks; make commitment visible, so confirming or declining turns interest into a plan; leave room for unmet demand with requests; and turn those requests into opportunities for hosts. That last one is the bridge between the two sides. One principle runs through all four: AI suggests, people decide. AI blends group preferences and drafts event briefs; attendees and hosts make every final call.

The Demand Signal loop

1. 01crew search
2. 02picks and gaps
3. 03request
4. 04host insights
5. 05claim and publish
6. 06notify
7. 07"Did you go?"
8. 08recap

Design

From grey boxes to a live app

Four steps across both sides of the app, from my low-fi flows to the high-fidelity design built on the design system I set up. Scroll to follow along.

1. 

   Step 1 · Attendee

   Teach it your taste

   Onboarding asks for vibes, past events and how far you'll travel, so day one isn't blank. Every step can be skipped.

2. 

   Step 2 · Crew

   Blend the crew

   Pick who's in this time. Crew Blend ranks nights everyone would enjoy, inside the lowest budget, with one line on why. Then the group votes.

3. 

   Step 3 · Attendee

   Request the night

   Nothing fits? Say what you'd go to: vibe, when, where, budget. Each person backs a request from their own account, so every account counts once.

4. 

   Step 4 · Host

   Show hosts the demand

   Hosts see what people nearby want, and when. A request opens with an AI-assisted brief as a starting point; the host edits every detail, publishes, and the people who asked hear first.

Tradeoffs

From an events feed to a two-sided loop

I pushed back on our first proposal: it didn't look any different from other apps. Each pair below is one decision, the version we tried first and the one that held up.

01Crews and hosts, not another feed

We narrowed a general events feed to two features no competitor had together: Crew Blend and Demand Signals.

Why

A feed was a solution in disguise. Crew Blend and Demand Signals were a pair no competitor had.

02A match label, not a percentage

Top, Strong and Good tiers, with one plain line on who each pick is for.

Why

Percentages read as false precision. A tier and one plain sentence say who it's for and why.

03An idea brief, not a tally

A request opens as a brief: when, where, budget, group size, and who else is planning.

Why

A count tells a host people care. A brief tells them what to book, for whom, at what price.

Handoff

What leading a team of six taught me

• Push back on your own idea first

  • Our first proposal was a better events feed. I reviewed it and said it didn't look different from other apps.
  • That review is what got us to Crew Blend, Demand Signals and hosts as a second user group.

• Pick a number that can't be faked

  • Saves and downloads fail the test of "if this doubled overnight, would anything good have happened?" We chose confirmed attendance and satisfaction.
  • It also told us who pays. Attendees won't, so hosts pay for demand data and we link out for tickets.

• Label assumptions as assumptions

  • Crew Blend came from a brainstorm, not an interview, and I logged it as an assumption.
  • We interviewed two attendees and no hosts, so the host side is still a hypothesis. Next: peer usability testing with about four teams, and two or three venue bookers.

Where it stands

Done, and not yet