Overview
Hoop is a search marketplace connecting families with children’s activities and giving organisers a platform to list, manage and take bookings. When I joined, the app had strong retention and growing monthly users, but no way to actually transact. Families found an activity they liked and then got bounced out to an organiser’s website to book, often abandoning along the way. The brief was to bring booking in-app. The harder problem was that “in-app” had to mean something different for a parent on a phone in a school playground and an organiser running a class between school runs.
Note: Personal data in the visuals is illustrative. No real users, organisers, or transactions are shown.
The challenge
Hoop’s inventory ran from free toddler singalongs in church halls to paid half-term football camps run by franchises with their own payment systems. Organisers ranged from a single parent running a baby music class to institutions like the Natural History Museum. Any booking flow had to serve all of them without turning the app into Eventbrite.
On the family side, our survey of 200 parents pointed to two recurring blockers: not enough information about the activity, and checkout flows that felt overly complicated. On the organiser side, small businesses had no real tooling and medium ones had rigid, painful systems they had outgrown.
And then there was a problem that wasn’t in the brief at all. The app’s onboarding asked for sign-up before showing What’s On, which was where Hoop’s value actually lived. We had a funnel that leaked before anyone could find a reason to pay, and any booking work we did was going to land on top of that leak.
How I approached it
The project broke into three threads that ran in parallel rather than in sequence: fixing the onboarding funnel that was leaking before anyone could pay, designing the family-side booking flow, and building an organiser product that could take real money for the first time. The funnel work came first because nothing else was going to work without it, but the family and organiser threads had to be designed against each other, every decision on one side had a consequence on the other.
Fixing the funnel before the basket
Before jumping into booking screens, we mapped the existing funnel together. The onboarding flow had been built to capture sign-up data, and it was doing that well, at the cost of people ever seeing what Hoop was for. We agreed it had to be reordered: new users would hit the value first by browsing What’s On, and account creation would become skippable since we’d need payment details at checkout anyway. This felt obvious in hindsight, but registered users was the metric the business was reporting to investors, and any change that risked it had to be made carefully.
With the funnel sorted, we segmented families by child age: babies, toddlers, school-age. The segments behaved differently enough to shape pricing expectations, frequency assumptions, and eventually the copy we used across onboarding emails. Babies were our most promising segment, frequent bookings close to home and low commitment per session, and that shaped how we set defaults and which activities the home screen leaned into.
Those segments shaped real design work downstream. The onboarding emails became a personalised set: a welcome email that introduced the app, a referral email that turned existing users into a growth channel, a £5 first-booking incentive that made the activation event a paid one rather than a sign-up, and a segment-specific guide (“Getting started with baby activities”) that pointed each cohort at the activity types we knew they’d most likely book. The same family of decisions the funnel reorder had started.
Designing the basket
For the consumer app, I ran lightning demos against established booking patterns. Airbnb for the activity screen, where their fixed booking bar held the page together while you scrolled. Eventbrite for the transactional emails, because their receipt-plus-reminder cadence handled the anxious days between booking and showing up better than anything else I tested. The basket itself, our internal name for the booking flow, covered date, ticket type, child details, payment, and confirmation.
Ticket naming was the first thing that almost broke it. Organisers used every variation imaginable (“Full Term”, “Single Session”, “Taster”, “Sibling”), and it all had to fit on an iPhone SE, our second most common device. I designed the ticket row as a flexible component that could truncate cleanly and always expose the price, so the most decision-relevant information was never the thing that got cut.
Pricing on the cards had the same problem. A class with Full Term, Single Session, and Free Trial options couldn’t honestly lead with one price, so cards led with “From £X”. Approachable enough to feel inviting, honest enough not to mislead.
Buttons were the next problem, and they sat on two different surfaces. The cards in the What’s On feed had a button. So did the activity screen itself. They looked the same on the surface but had different jobs: the listings card button was a low-stakes affordance, “have a look at this”, and the activity screen button was a transactional CTA, “start the booking”. User testing on the listings cards kept surfacing the same problem: anything with “Book” in it made parents anxious. They thought tapping would commit them to something, even though all it did was open the activity screen. We changed the listings button to “View” and tap-through rates climbed. Small word, big read.
The activity screen got a different treatment. This was the surface where booking actually started, so the CTA had to feel transactional. We used Hoop’s red-orange for the button, which gave it visual weight and clear separation from the blue save and share actions on the same screen. The button itself had to support several states because the activities varied: “Book Now” on its own, “Book Now” alongside the “From £X” price, “Free Trial Available” as a longer alternative label when the activity offered one. The component had to flex around the activity, not the other way around.
The organiser side: Boosted Listings
The organiser side was the bigger shift, because most organisers had never taken a digital booking before. I worked on a feature called Boosted Listings, a free upgrade that unlocked bookings on a Hoop listing in exchange for a commission on each sale. The commercial framing came from the founders. Free basic accounts had to stay free, because the inventory was what kept families coming back to the app, and the upgrade had to feel like a step up, not a penalty for wanting to take bookings. My job was to design something that sat comfortably with both: a free product that didn’t feel crippled, and a paid product that didn’t feel like a paywall.
The upgrade also needed a place to live. I designed a marketing page that explained Boosted Listings in language organisers already used. Empty spots in your class, a way to fill them, a small fee only when you do. The page was where the commercial framing actually had to land, because no organiser was going to opt in based on a button label.
The Bookings page was where I learned the most about who I was actually designing for. The instinct from any e-commerce admin would be to lead with the customer name. But organisers didn’t recognise the parents. They recognised the children. A music teacher running a Tuesday morning class knew Theo and Maisie by name, not Theo’s mum. So the table got built around attendee names, with the customer and attendee shown side by side and the attendee given the visual weight. Small change in the spec, big change in whether the page felt useful.
Underneath the Bookings page sat a sale view with refund controls, ticket allocation per session, and the transactional email set we’d modelled on Eventbrite. The pieces were familiar. The work was making them coherent for someone running classes between school runs, on a phone, in a hurry.
Dailies
One working practice ran through the whole project. We did dailies, borrowed loosely from how Pixar’s animation teams reviewed work in progress. Most days, I’d share whatever I’d been working on, regardless of how rough it was, and the PM and engineers would react in real time. Sprints varied between one and two weeks, and waiting for a formal review meant feedback arrived too late to act on without rework. Dailies made feedback a shared responsibility rather than a handover event, and they’re probably the habit from this project I carry hardest into every team I’ve joined since.
Outcome & reflection
App Store reviews from real users started using the language the design had been built to support: “seamless”, “easy”, “one minute to book a class”, “literally book and pay for a class the night before”. The “new mum when everything is a bit of a mess” review in particular felt like the design talking back.
Booking launched in April 2017 and took Hoop’s first real sale within days. Over the next two years it processed enough bookings to become a meaningful revenue stream for the company. The number that mattered more, though, was a different one: for the first time, organisers could see what Hoop was actually worth to them in cash. The marketplace had a price now, and that changed the conversations we could have with them.
Two things I’d do differently. The first is “Book” versus “View”. I underestimated how much a single word could shape a parent’s whole read on commitment, and I started testing language with the same care I tested flows. The second is persistence. Parents re-entered the same details on every booking, and the fix was straightforward but kept getting deprioritised against new features. Convenience compounds, and I should have made that argument louder.
The thing I carry forward from this project is what designing for both sides of a marketplace actually demands. The family side and the organiser side weren’t two products living under one brand. They were two products whose decisions had to make sense together: a parent’s anxiety about a tap, an organiser’s relief at recognising a child’s name, a free-to-paid commercial frame that respected both. Most of the work was holding both sides in mind at once.
