Overview
Hoop is a search marketplace connecting families with children’s activities and giving organisers a platform to list, manage and take bookings. The app listed roughly 90,000 activities a week, most of them from organisers on free basic listings. To actually take bookings through Hoop, an organiser had to “boost”: sign a partner agreement, hand over bank details, set ticket allocation. Of around 14,500 organisers, only 3,200 had ever boosted, and only 2,000 of those had made a sale. The marketplace was supply-rich and revenue-poor.
Note: Personal data in the visuals is illustrative. No real users, organisers, or activities are shown.
The Challenge
The honest read was that boosting asked organisers to do paperwork for a sale that hadn’t happened yet, and most weren’t going to bet their afternoon on a maybe. The team had surveyed every reason organisers gave for not boosting. 30.3% gave no real reason, 21.2% ran drop-in classes that didn’t fit Hoop’s allocation model, 21.2% cited marketing budget, and 15.2% already used their own booking system. The largest slice was effectively a shrug at the cost of signing up.
The brief was sharp: how might we get organisers to take a real sale without making them sign up first? The constraint underneath it was sharper. We had two weeks. We were one of several bets in the company’s quarterly GMV plan, and we needed something live and learning fast, not polished.
How I approached it
We agreed on a deliberately small MVP: iOS only, Apple Pay only (so we could skip strong customer authentication), one organiser-approved cohort handpicked by the partnerships team. The mechanic was a pre-authorised request, with a three-hour window for the organiser to respond before the request expired and the hold released. The system had to work for both sides. The customer was waiting in the app, the organiser was responding on the web platform, but the brief was specifically asking us to fix what wasn’t working on the organiser side. Most of the consequential design decisions sit there, with the customer-side experience designed in support. The flow below shows the shape of what got built.
The request
The mechanic was a pre-authorised request. When a customer tapped Request to Book in the app, their card was authorised but not charged. The funds were held while the organiser decided. That single decision made the whole feature possible. It meant the customer had committed financially without anyone yet asking the organiser to commit operationally. The sale existed as a real possibility before any paperwork was on the table.
For the customer, this opened a wait state we had to design carefully. A request that’s pending isn’t a ticket and isn’t a failure. It’s a thing the customer is waiting on, and for a time-poor parent, ambiguity is worse than rejection. The pending status had to work across three surfaces: a persistent status bar at the bottom of the What’s On home screen, the activity overview the customer landed on when they tapped through, and the tickets screen alongside their existing bookings. The state logic governed what the customer could do at each point, not just what they could see. Pending stayed visible every session until the organiser acted, with a Lottie animation giving it momentum and a sense of progression rather than letting it read as frozen.
For the organiser, the request arrived as an email with accept and reject buttons sitting directly inside it, alongside the 0% commission offer for their first 30 days. The email was the first place the organiser encountered the request, which meant it had to carry enough information to make the decision feel actionable from the inbox itself. Tapping through took them to the web platform where the actual response happened, but the email was already doing work to lower the activation cost.
The decision
The hard part of the system was the moment the organiser had to respond. They opened the web platform from the email, landed on the bookings table, and saw a list of incoming requests with everything visible except the customer. Names and contact details were blurred on any request that hadn’t yet been accepted. We did this for GDPR reasons. The organiser couldn’t see who was booking until they’d actually committed to taking the booking. But the blur was doing a second job that only became visible once I sat with the mockup for a while. It created curiosity. To see who wanted to book, you had to accept. A compliance line and an engagement nudge had quietly collapsed into the same piece of UI, which felt like the right kind of overlap. I flagged it to the PM and we leaned into it rather than designing around it.
Acceptance was where the bigger design decision sat. The brief was clear that we should only ask for payment and partner details after a sale, so the bank-and-agreement form had to live somewhere on the post-acceptance side. The design question was how to frame it so it didn’t feel like the same paperwork organisers had been refusing for months. We landed on “Congratulations on your first sale!” as the moment. Same fields, completely different psychological context. The form arrived with money already on the table, not as a gate in front of one. We paired it with a 0% commission promotion for the first 30 days, surfaced inside the very first request email so the organiser saw the deal at the moment of highest motivation.
While the organiser was deciding, the customer was waiting. Their card had been pre-authorised at the moment of request, so they’d already committed financially, but no money had moved. The three-hour window was the soft constraint. Long enough that an organiser running classes between school runs could reasonably respond, short enough that a customer didn’t have a week-long pending state hanging over their week. If the window expired, the pre-authorisation released automatically and the customer was emailed. If the organiser rejected, we routed them through a short survey so we could learn why. The partnerships team picked up the answers from there. The three outcomes all had to resolve cleanly on both sides, because a marketplace where requests disappear into silence is a marketplace customers don’t trust.
The resolutions
Each of the three outcomes had to resolve cleanly across both sides, with a designed surface for every state change.
Acceptance fired the post-sale system: payment captured, the organiser sent a confirmation email and notification, the customer’s three pending surfaces all flipped to confirmed, and the customer was emailed. The email layer matched the in-app status language exactly. Booking Confirmed, the same pill, the same tone, so the customer’s mental model held whether they were in their inbox or in Hoop. It was a small parallel-language decision that did real work in keeping the system feeling coherent across surfaces.
Rejection had to be handled with care because we didn’t want organisers feeling like a “no” was final. The rejection survey gave us structured information about why, with the data flowing to the partnerships team for follow-up. The customer’s pending surfaces resolved to rejected, and they received an email in the same matched language. We cleared the rejected state from the home screen status bar once the customer had acknowledged it, so the home screen never accumulated stale notifications. The wait had ended, and the UI honoured that.
Timeout was the quiet outcome. If the organiser didn’t respond within the three-hour window, the system released the pre-authorisation automatically and emailed the customer using the same template as the rejection: “Unfortunately, X couldn’t accept your booking.” The deliberate choice was that the customer didn’t need to know whether the organiser had actively rejected them or simply run out of time. The result was the same, and one close-out experience was kinder than two.
There were edge cases beyond the three main outcomes, and each got its own designed email pair so that no path through the system ended in silence.
Outcome & reflection
Request to Book shipped on the timeline, and the first requests came through within days: proof that the demand-side hypothesis was right. Families would request to book activities they currently couldn’t. The supply-side response was the harder story. Organiser response times were slower than we’d hoped. The organisers we’d handpicked were exactly the people the feature was designed for: small operators running classes between school runs, not sat at a desk waiting for notifications. The three-hour window that felt generous in a Slack discussion felt tight in the field.
We paused the feature after the initial run. It was too dependent on the partnerships team manually shepherding each cohort, and the company’s priorities were shifting toward web expansion and a planned US launch. Hoop wound down in early 2020 as COVID hit, and Request to Book never got the second iteration it needed: shorten the window, add push reminders, maybe auto-accept for trusted organisers.
What I took from it: the design wasn’t wrong, the system around it was incomplete. Designing a two-sided flow means designing for the side that can’t sit at a screen all day, and I’d treat that as a constraint to solve in the product itself next time, not a problem to hand to the partnerships team.
Two weeks from kickoff to a live feature was only possible because the UI library was already in good shape. I spent the time on flows and decisions instead of rebuilding components. That’s stuck with me as a working principle: a tidy system isn’t a vanity project, it’s what gives you the room to design properly when the deadline is tight.
