Case study · B2C marketplace · iOS, Android & web
Simplifying how customers discover, customise and book professional treatments at home.
Overview
Urban is an on-demand wellness marketplace. Customers book professional practitioners who come to their home for massage, physiotherapy, osteopathy and beauty treatments.
Unlike a typical appointment app, every Urban booking coordinates several variables at once. The customer isn’t just picking a slot: they choose a treatment, a time and a practitioner, and the practitioner has to be free, able to travel to them, and priced right.
My work focused on reducing friction from intent to completed booking, across optimisation and new-product work. Often, what looked like a small UX issue was tied to much larger operational, technical or commercial dependencies.
Design systems ownership
How practitioners manage availability, bookings, customers and their day.
The main way customers discover, book, manage and review treatments.
The same core customer journeys on a responsive web experience.
Urban’s internal operations tool, built on Material UI with a substantial layer of custom components and patterns.
Parking information optimisation
Before and after
Parking is a real problem in London and the other UK cities Urban serves. Practitioners need to know where to park before they set off.
Urban already asked customers for parking information, but most never gave it. Practitioners could also end up paying for parking or receiving a fine, so a UX gap became an operational and financial problem.
The chain reaction
Practitioner survey
What Urban practitioners told us about parking information, and what they do when it’s missing.
Asked which parking problem they face most often, 63 of 97 practitioners chose “I didn’t receive any parking information from the client”, more than four times any other answer.
63 of 97 chose missing information
01Most frequent problem
Asked which parking problem they face most often, 63 of 97 practitioners chose “I didn’t receive any parking information from the client”, more than four times any other answer.
63 of 97 chose missing information
02How often
65% of practitioners hit a parking problem at least once a week, and more than a quarter at least once a day. Only 3% have never had one.
65% at least weekly
03Every problem faced
Across every parking problem they had faced, no information led again, followed by suggested parking that was too far away or too expensive.
78 had received no information
04How they respond
The most common response was to remove the problematic area from their profile. A booking-flow gap was shrinking supply in the places that needed it most.
40 remove the area from their profile
The input already existed. But after paying, customers think “my booking is done.”
So I didn’t just make the field more visible. I tested placement and timing in Maze around three questions, and each answer shaped the final flow.
In the flow, as a dedicated bottom sheet. Out of a secondary tab and into the moment customers are still engaged with their booking.
Between payment and confirmation. Earlier adds friction to a high-intent step. After the success screen, customers feel done and leave.
Whenever the practitioner isn’t driving. Travel mode from the Pro App decides, so customers are never asked for details that won’t be used.
Outcome
The problem was never a missing input. It was the visibility, timing and relevance of the interaction.
Small UX problems can create disproportionately large operational ones. The fix came down to three simple questions: where to place it, when to show it, and when not to.
This became a recurring principle in my work at Urban: good product design is often less about adding functionality and more about putting the right interaction in the right context.
Add-ons
The business wanted a higher average order value. Customers wanted lower-cost extras to personalise their treatment. Add-ons could serve both.
But add-ons weren’t a simple bolt-on. Whether one could be offered depended on a web of existing variables, and a customer could book several services from the same practitioner, each with its own set of compatible add-ons.
Adding an add-on wasn’t as simple as displaying a list of optional services. Each recommendation had to respect a set of practitioner, service, and availability rules to ensure customers could only select add-ons that could actually be fulfilled.
Certain add-ons required specific practitioner qualifications, meaning they could only be offered by practitioners certified to provide them.
Practitioners had to explicitly opt in to offer an add-on from their app before customers could select it during booking.
Some add-ons, such as oils and aromatherapy products, were product-based rather than service-based. The relevant products therefore had to be available to the practitioner before the add-on could be offered.
Not every add-on was compatible with every treatment. The experience needed to prevent customers from selecting combinations that could not safely or practically be delivered together.
Some add-ons increased the length of an appointment. If a practitioner had committed availability from 2:00–3:00 PM and the existing booking already occupied that entire window, adding a duration-based service could exceed their available time.
Add-ons also had to respect availability blocks set by practitioners, ensuring that an additional service could not be added when there was insufficient time within the practitioner’s schedule.
Customers could book multiple services with the same practitioner, with each service having its own set of compatible add-ons. The experience therefore needed to evaluate add-on eligibility at the individual service level rather than treating the entire booking as one service.
The duration problem
If a practitioner committed 2:00–3:00 PM and the booking already filled that hour, a duration-based add-on would run past their availability. Where add-ons appeared could change which practitioners showed as available at all.
The decision
The availability screen was one of the most commercially important parts of the journey. Add-ons there would shrink the pool of practitioners and add a decision before customers had even chosen who would treat them.
After several iterations with engineering, add-ons moved to the basket, and only appear once a booking item is complete. That kept them a low-risk enhancement rather than another gate in the core flow.
The second problem
Dropping the add-on component into the old basket exposed a usability issue: the page was visually heavy, add-ons landed below the fold, and they looked detached from the treatment they belonged to.
A sticky checkout button, designed to speed up conversion, worked almost too well. Customers saw it and paid without ever discovering add-ons.
From the original basket to the new one
Research · Maze test
Only 4 of 20 participants found add-ons in the old basket; after the redesign, all 20 did. The full Maze log, task by task.
Asked to find details of a complementary service, 10 of 16 testers succeeded directly. Two-thirds of clicks missed, and the task took 42.5 seconds on average.
62.5% direct success · 66% misclick
01Task 1 · Find an add-on
Asked to find details of a complementary service, 10 of 16 testers succeeded directly. Two-thirds of clicks missed, and the task took 42.5 seconds on average.
62.5% direct success · 66% misclick
01Task 1 · Find an add-on
“I didn’t realise I had to scroll down.” The sticky checkout button let people continue without ever reaching add-ons. The proposed fix: declutter the basket so add-ons sit in the first viewport.
01Task 1 · Find an add-on
This tester’s first move was the sticky button, not scrolling. They got stuck, went back to the basket, and only then found the add-ons.
Heatmap 1 of 3
01Task 1 · Find an add-on
Probably unsure of the task, this tester tapped duration and location first, then selected several add-ons before opening one.
Heatmap 2 of 3
01Task 1 · Find an add-on
Like the others, this tester selected an item before opening it to learn more, a path Maze didn’t count as success.
Heatmap 3 of 3
02Task 2 · Apply an add-on
Asked to apply the heated blanket, 14 of 16 testers did it directly, in about seven seconds.
87.5% direct success · 7.3s
02Task 2 · Apply an add-on
One tester would rather add a scalp massage than a heated blanket on price. Another suggested ordering add-ons from high to low to anchor price expectations.
02Task 2 · Apply an add-on
Interest in a scalp massage led this tester off the direct path and into an indirect success.
Heatmap 1 of 2
02Task 2 · Apply an add-on
The tester probably tapped the card instead of the add button, closed the modal, then added the heated blanket.
Heatmap 2 of 2
03Task 3 · Remove an add-on
Every tester removed the heated blanket directly, and only one of 16 did it from the checkout page.
100% direct success · 5% misclick
04Feedback & questions
Testers found adding easy but removing less intuitive, and asked for a confirmation when removing an add-on from the carousel.
04Feedback & questions
An open question for the business: customers who bring their own oils or massage gun.
Redesigning the basket
What started as a feature became a basket redesign. The goal wasn’t just a cleaner page: it was to surface add-ons without slowing anyone down.
Before and after
After launch
Weekly notes from the post-launch report, with the charts we tracked in Looker.
Week 1 converted around 10% of impressions. By week 2, add-on sales were up 35% and about 8% of customers shown add-ons bought one. But only around 28% of baskets were eligible, so supply became the lever.
+35% week on week
Baskets eligible for add-ons
Eligible Not eligible
Conversion
~10%of impressions · week 1
~8%of customers shown add-ons · week 2
1 in 12.5potential orders sold an add-on
Supply
20% → 24%of working pros offering at least one add-on
01Weeks 1–2
Week 1 converted around 10% of impressions. By week 2, add-on sales were up 35% and about 8% of customers shown add-ons bought one. But only around 28% of baskets were eligible, so supply became the lever.
+35% week on week
Baskets eligible for add-ons
Eligible Not eligible
Conversion
~10%of impressions · week 1
~8%of customers shown add-ons · week 2
1 in 12.5potential orders sold an add-on
Supply
20% → 24%of working pros offering at least one add-on
02Week 3
The backend team added add-ons to every eligible practitioner who hadn’t opted out. 59% of pros with hours now offered them, up from 20%, and 69% of pros active in the last 28 days had add-ons.
20% → 59% of pros offering add-ons
02Week 3
Daily sessions show the share of checkout entrants shown an add-on climbing sharply once supply increased, reaching 52% in the week of 15 July.
52% of checkout entrants saw add-ons
03Week 4
A month after launch, 294 add-ons had been sold, adding £3,316 in gross transaction value and £1,015 in fees retained by Urban.
294 sold · £3,316 GTV · £1,015 fees
04Week 5
126 add-ons sold in a single week, up 110%, and more than the previous two weeks combined.
+110% week on week
Request to Book
Urban relied on practitioners committing availability in advance. A customer’s favourite practitioner could be free, and still not appear in search.
The existing workaround involved several steps:
This created unnecessary back-and-forth. If either person responded slowly, the booking opportunity could disappear altogether, as requests like these tend to be last minute bookings. The result was friction for the customer, lost bookings for practitioners, and missed revenue opportunities for Urban.
Let customers request a time the practitioner hasn’t committed, while the practitioner keeps control of whether they can do it.
Designing around uncertainty
Instant slots were confirmed bookings, because the practitioner had already committed the time. A request wasn’t, so the existing pay-to-book model didn’t translate. I designed Request to Book as a new booking state across the system, answering what the customer needs at every step: has it been sent, is the practitioner reviewing it, has it been accepted, declined or expired, when does payment happen, and what can they do while waiting.
The Urban product redesign
After several optimisation projects and new features, I was asked to lead design for a full product redesign, in about three months.
It ran alongside a major technical migration from Urban’s legacy system to ServiceOS, a third-party platform-as-a-service. This wasn’t a greenfield project. The internal Manage X platform was out of scope.
months
Redesign timelinesurfaces
Pro app, Customer app, Customer web app and responsive webplatform migration
From Urban’s legacy system to ServiceOSDesigning within platform constraints
ServiceOS had an established component framework for booking platforms, but no Figma design system. Its documentation lived in Zeplin, mostly as component images.
I translated the platform into a usable design foundation, and identified where Urban’s experience needed custom components or patterns. ServiceOS was open to new components, but every deviation added implementation work and migration risk.
Does this improve the experience enough to justify the implementation cost and migration complexity?
The booking flow challenge
The question wasn’t “how do we make Urban fit the new platform?” It was: which parts of the existing experience are essential, and how do we keep them within the platform’s constraints?
Search and availability had a direct line to booking conversion, so I didn’t settle it on stakeholder preference. I tested multiple versions in Maze, evaluating:
The results told the team which parts of the legacy experience to preserve, adapt or redesign.
My role
I drove the customer and practitioner experience end to end: understanding the existing product, finding experience gaps, running research, defining interaction patterns, creating the new design system foundations, and shaping it all into something engineering could ship within the migration timeline.
That meant systems thinking across product, technology, operations and customer behaviour, not just screens.
The final product
Design system
Rather than a collection of UI components, I used the design system to keep products consistent while reducing design and implementation overhead: visual foundations, components, states, interaction patterns and layouts that scale across every surface.
Outcome
A fully redesigned customer and practitioner product suite, delivered within the three-month design window.
A new foundation for Urban across mobile and web, built to work within the constraints of ServiceOS.
What this work taught me
Parking looked like a missing input. Add-ons looked like a new feature. Request to Book looked like a new booking option. Each was tied to systems, behaviours and business constraints that had to be understood before designing the interface.
The parking input and the add-ons already existed. The challenge was getting them in front of customers at the right moment. Visibility, context and timing decide whether a useful feature succeeds.
The booking flow wasn’t just a UX journey. It shaped availability, conversion, revenue, practitioner utilisation and retention, so decisions had to account for customer needs and business mechanics together.
Instead of working around the ServiceOS constraints, I used them to find which parts of the experience were truly valuable and which could be simplified. The work moved from redesigning screens to redesigning the product within a real-world system.
My work at Urban grew from solving individual UX problems to treating the product as a connected system. From one post-booking prompt to a full product redesign, the question stayed the same:
How do we make a complex marketplace feel simple for the people using it, while keeping it viable for the business and the systems behind it?
Other case studies
