1. Overlapping elements
Overlays and panels stacked on top of each other, making the screen hard to use.
Bikebook’s booking widget sits on partner websites, so it is often a customer’s first contact with the company. Before the redesign, fewer than 5 in every 100 people who started a booking on one retail partner’s widget reached the final step. I redesigned the flow around funnel data, session replays and partner interviews, and kept the interface neutral enough for each partner to make it their own.
I prototyped the design and reviewed it with partners and engineers at every stage. It was not built before I left in August 2026, so this case study sets out the evidence and reasoning behind each decision, not post-launch results.
Google Analytics 4 data from one partner’s embed in March 2026, before the redesign, shows where people left the booking flow. Step 1 lost the most people, and step 4 was the worst of the later steps.
1. Postcode search (nearest mechanic)
2. Select a date
3. Select bike and services
4. Your information
5. Review
6. Confirm booking
I spoke to four bike businesses and a Japanese knife retailer about how the widget could be improved.
I did all of the research myself: funnel analysis, session replays and heatmaps, a screen-by-screen audit of the existing flow, partner interviews, a visit to a partner workshop, and conversations with the co-founders about which steps mattered most.
I also reviewed HubTiger, the main competitor. It handled progressive disclosure well, with one decision per page, but its progress bar was vague and its contrast was low. Google and Apple Maps informed the search page, and Shopify and SumUp informed the restrained styling and sign-in patterns.
Average time on the page rose from 9m 47s over the past year to 16m 11s over the last 28 days, an increase of about two-thirds. It suggested customers were struggling to get through the flow.
This step lost 82.9% of people.
Overlays and panels stacked on top of each other, making the screen hard to use.
Errors appeared as floating pop-ups, and key information was hidden behind tooltips.
Partial matches distracted from the task, and partial postcodes returned no results after search.
The placeholder “Enter location…” was not specific enough and disappeared on click.
The widget had to work at every breakpoint inside an iframe, stay neutral enough for partner branding, and use existing calendar and payment components that I could not change. The design system barely existed, and the direction shifted midway from Bikebook’s existing style to a Shopify and SumUp look. The knife retailer needed different copy and customisable fields, because the software now serves businesses beyond bikes.
The field is labelled "Postcode", with location and search icons and the instruction "Enter your postcode or tap a pin on the map."
Search runs on submit, and errors appear inline beneath the field.
The header card and legend are gone, so results show straight away. The map fills the screen on desktop with results beside it, and results sit in a panel below the map on mobile.
Each result shows distance, opening status, next available date and prices, in place of a collection area tooltip.
The original flow asked for a bike and then services, so one booking could not cover several bikes with different services. I reversed the order: choose services, add bikes, then assign each service to a bike. The order also suits the data. Not every mechanic can do every service, so the system can show only the mechanics and dates that can do the work, instead of a customer getting a phone call after booking.
Visual, but difficult on mobile phones, hard to make accessible, and it left out prices.
Familiar, with prices visible, but it takes more space and moves services between sections.
Chosen
I chose the single list on accessibility, ease of use and use of space, after trying the options myself and with colleagues and partners. If services are left unassigned, a dialog offers to go back or continue without them.
This step lost 52.5% of people. It came near the end, required both an email address and a mobile number even after the customer chose a contact method, and carried seven lines of small-print terms.
Earlier in the flow. My hypothesis was that people who have started are more likely to carry on, and partners can follow up if they leave. One partner described the ideal as a classic Shopify checkout that starts with an email address.
One field to start. The customer enters an email address. A returning customer sees "Welcome back", a new customer creates an account with Google, Apple or a password, and anyone can choose "Continue as guest", which did not exist before.
Only what is needed. The customer gives only the contact detail they chose, and the terms are one line with links.
Where single sign-on sat was debated. I proposed putting the Google and Apple options on the first screen. The co-founder leading development argued for email first, with "Continue with Bikebook" as the main action, to ease returning customers' journeys and build recognition as a login brand. We designed it that way, and the same label settled a debate about calling it a partner account
I built components, tokens and a monochrome palette in a Figma library so the widget works with most brand colours. Partners change only the buttons and progress bar, and body copy stays fixed to keep contrast high. Figma variables let me re-brand a whole prototype for several partners without breaking the file. Engineering confirmed that a tool turning one or two brand colours into an accessible palette was feasible, but it was not yet built. Main calls to action buttons are at least 48px high, and body text is at least 16px.
I built it with Figma, Ship Studio, Claude Code and Vercel.
I built the Figma file stage by stage, combined the stages into three versions of the whole flow, and adapted them for each partner, ending with a "Ready for Dev" page. Co-founders, developers and partners saw prototypes at every stage, and I asked them to vote on options and explain why. I checked constraints with engineers early, wrote the product Linear tickets and prioritised with the co-founders.
I left before the design was built, so I have no post-launch data. What I do have is the baseline above, feedback from partners who reviewed the prototypes (they described it as a clear improvement) and engineering input on feasibility.
Once it is live, I would measure:
Reducing drop-off at the postcode (82.9%) and details (52.5%) steps.
Increasing overall completion (under 5%).
Reducing time on the page (time to complete the booking flow).
Customer lead capture, which I expect to rise because details are now requested at the start
Session replays, for fewer errors and overlay problems
User testing feedback.
Partner feedback.
Agree the brief first. Requirements were scattered across historical Linear documents and some arrived very late into the project.
Settle the visual direction early. The midway shift to a Shopify and SumUp look meant reworking components. Tokens made that manageable.
Phase the release. Ship the postcode step first and measure it. It was the biggest drop-off, so improving it is likely to have the biggest impact.
Add edit links to the review step, so customers do not have to go back through the stepper.
Listening to partners shaped my priorities more than anything else. Involving them in the project made them feel heard, and more likely to support the change when the new flow launched. The result is a consistent, logical flow that can be adapted for a new partner without redesigning it. The copy is written in plain language. I drafted options with AI tools and edited the final wording myself.
