Product Designer
Role
4 months
Timeline
A meaningful gap
Dojo's Restaurant Management System (RMS) helps independent restaurants, pubs, and cafés manage bookings, walk-ins, and queues. When I joined, it had one meaningful gap: no way for venues to protect themselves against no-shows.
What is a No-Show?
A restaurant no-show occurs when a guest makes a booking but fails to arrive, without cancelling or notifying the restaurant. A table blocked for a party of six that never shows up might not be filled at 8pm on a Saturday night and that revenue is gone.
For Dojo's venues, this wasn't a theoretical concern. It was a weekly frustration. And it was costing the industry at scale: the UK hospitality sector loses an estimated £16 billion a year to no-shows and late cancellations. For Dojo, addressing this represented a potential 30% TAM expansion and approximately £3.5MM/year in additional revenue.
No-shows sit at the intersection of guest trust, venue operations, and payment technology.
My Role
End-to-end product design: research, strategy, UX, UI, handoff.
I ran a structured research process which included 25 participants across discovery, concept validation, and usability testing.
How do venues currently handle no-shows and what workarounds have they built?
What's the guest experience of being asked for a deposit or card? Where does trust break down?
What do venues in adjacent markets (accommodation, events, beauty) do, and can hospitality learn from them?
Venues were managing no-shows through a mix of manual follow-up (calling guests to confirm), overbooking (accepting more reservations than capacity to account for expected no-shows), and absorbing the cost. None of these worked cleanly.
Overbooking risked service quality. Manual calls took staff time. Absorbing the cost meant the problem never had a number attached to it, so it was hard to escalate internally.
Guests, meanwhile, had mixed feelings about deposits. In hospitality — unlike hotels or theatre bookings — a deposit still felt unusual to most UK diners. The framing mattered enormously: "card on file" felt lighter than "deposit." "Cancellation policy" felt fairer than "penalty."
Competitive analysis surfaced a range of approaches across OpenTable, Resy, DesignMyNight, and non-hospitality verticals. The common failure mode: policies that were technically correct but communicated in ways that felt adversarial rather than reasonable.
More about each research steps below:
Some Numbers
Target Customers
Competitive Analysis
The guest experience
Work with the team early for best results
Tech and Ops considerations
Payments
Leverage the existing company products to take Deposits as an upfront payment.
Reconciliations
No EPOS integration means that reconciliation must be done manually by the host.
G Reserve
An integration with Google reserve has been flagged as a potential problem.
Underwriting
Manual process that will need to evolve into scalable and sustainable.
More about the process below:
Workshop
User Flow
The design challenge
Dojo's RMS didn't have payment infrastructure at the venue-setup level. This project was introducing a new concept to the product: that booking settings could include financial obligations.
That created two distinct user groups to design for: I designed both flows in parallel, constantly checking how the venue configuration choices would surface to guests. A policy that was easy to set up but alienating to read on a booking confirmation wasn't a solution.
The solution: four key decisions
Deposits vs. card-on-file: two products, not one
A deposit takes money now and refunds it (or keeps it).
Card on file takes nothing now but charges a cancellation fee later.
The trust dynamics, the guest communication requirements, and the venue operations implications are different enough to warrant distinct setup flows.
Deposits were easier to achieve from a technical pov, with no dependencies with other part of the business. As per customers preference both deposits and cards on file were seen as an important step to prevent no-shows. For consumers, both policy types were seen as painful depending on context.
Self-service setup
A key constraint was that this had to work without a Dojo CS rep on the call. Previous payment-adjacent features in the product required human setup assistance. I designed the policy configuration flow to be fully self-service and tested with venue operators who had no prior knowledge of how it worked.
Edge cases as primary cases
What happens when a guest disputes a charge? What if a venue misconfigures their cancellation window? What if a booking is modified after a deposit is taken? I mapped these scenarios early and built them into the spec, rather than deferring them to "v2." Payment features with unresolved edge cases generate chargebacks and support tickets and both were metrics the business cared about.
Impact within the initial rollout period
31,932 transactions
processed through the booking policies feature
Less No-Shows
Venues reported meaningful reduction in no-show rates (specific percentage data not captured in rollout instrumentation — an identified gap)
What I learned
Payment UX is trust UX
The technical plumbing of charging a card is less than half the design problem. The other half is making the transaction feel fair, expected, and easy to reverse if something goes wrong for both the venue and the guest.
Research depth pays for itself in edge case coverage.
The scenarios we found in sessions: the guest who disputes a charge, the venue that sets a deposit and forgets, the diner who books on behalf of a group and doesn't know a deposit applies. They would have become chargebacks and tickets without design coverage.
Language alignment with the rest of the product areas
Dojo RMS in part of Dojo payments. The two systems are not belongin one product and the user has to go through two different logins and products to manage their restaurants and their pyaments provider. Aligning with the Payments squads was however vital to create a coherent language across the two platforms.