Designing the first Build IRL experience for both sides of a club community

Build IRL was a 0→1 platform for starting, running, and joining in-person clubs.

At first, that sounded like one product problem. Research revealed two: builders were overwhelmed by the work happening behind their communities, while potential joiners struggled to tell whether a club would actually feel right for them.

Over 10 weeks, my team and I helped define the MVP around both sides of that experience. We moved from interviews and product framing into core user flows, mid-fidelity exploration, and high-fidelity web and mobile prototypes.

Through more than 10 interviews with club builders and joiners, two problems kept surfacing on opposite sides of the experience.

💡 Builders needed less work. Joiners needed more confidence.

Build IRL could have gone in a lot of directions: events, messaging, discovery, club management, profiles, onboarding, creation tools.

But trying to solve everything at once would just recreate the same complexity we were trying to reduce. So we narrowed the product around two questions:

01 Does this remove meaningful work for builders?

02 Does this give joiners enough context to feel confident joining?

A club created by a builder eventually became the experience evaluated by a joiner. That meant decisions on one side of the product affected what was possible on the other.

We mapped the core journeys in mid-fidelity first, using them to work through hierarchy, dependencies, and scope before committing to polished UI.

This stage was intentionally loose. As we reviewed the product with stakeholders, screens moved, flows changed, and some ideas were reworked once we could see the experience end to end.

💡 Mid-fi gave us room to make those changes quickly without getting too attached to polished UI too early.

The joiner experience couldn't just answer what, where, and when. Research showed people were also trying to figure out whether the community actually felt like a fit.

So, we brought more of the club's personality and context forward — things like interests, visuals, and community details — before committing.

Before

Club name

What · Where · When

A basic listing

From logistics to a sense of fit→

Build IRL

Club imagerySee the community

Interest tagsFind shared interests

About sectionGet a feel for the culture

A community-rich profile

💡 The goal wasn't to add more information. It was to surface the information that actually helped someone decide: Can I see myself here?

01 Discover

02 Understand

03 Join

Builders came into Build IRL with very different levels of momentum. Some already knew exactly what they wanted to create. Others had an idea but needed help shaping it. And existing communities might already have a visual identity somewhere else.

Instead of forcing everyone through one setup path, we designed three ways builders could begin:

💡 We adapted onboarding to different starting points instead of treating every builder like a blank slate.

The builder and joiner experiences weren't separate design problems. The information a builder added during creation became the context a joiner relied on later.

A club's visuals, interests, description, and activities had to be easy for builders to provide and meaningful for joiners to evaluate.

→

Over 10 weeks, we defined and prototyped the core Build IRL experience across both sides of the community. The final direction was approved by the team and presented at a conference, where it received positive feedback.

Since I didn't have access to long-term product metrics, the next things I'd want to understand are below — this is a measurement plan, not measured results.

Build IRL changed frequently while we were working on it. Flows I thought were settled would shift after a stakeholder conversation or once we saw the entire experience together.

Earlier in the project, those changes could feel like moving backward. Over time, I started to see them differently. In a 0→1 product, changing a design because the reasoning evolved isn't lost work — it's part of defining the product.

I left the project more comfortable changing direction when the evidence changed, even when that meant letting go of something I had already designed.