Client-reported before-and-after analytics. These figures describe the change following implementation; they do not isolate the redesign’s effect from other influences.
01 · problem
Interest was not becoming a booking.
Royal Nawaab Pyramid is a buffet restaurant in Stockport. The client wanted to understand why website visitors were leaving before completing a booking. Client analytics showed 64% bounce, 60% menu-screen drop-off and 38% booking completion. These are different measures of the journey, rather than interchangeable definitions of conversion.
The business problem was to turn existing interest into reservations. The user problem was to establish whether the menu suited their visit and find a clear route to booking. I connected them in one design question.
02 · research
Understanding where guests lost their way.
I interviewed eight participants across four paired sessions and combined the findings with client analytics. Participants were recruited through the client’s own social channels and offered up to 25% off their next order. No usability testing was carried out.
Recruitment through the client’s followers, with an incentive, produced a biased sample. The findings help explain those participants’ experiences; they do not represent all potential guests.
The short delivery window led me to pair participants. Restaurant decisions often involve pairs or groups, so the format reflected part of the context, but participants could influence each other’s answers. I regard that as the weakest part of the study and would interview people individually given more time.
Guests described difficulty finding relevant dishes on a long menu and locating the booking action once they were ready. The issue was the connection between finding information and acting on it, not simply the visual appeal of the page.
I used those findings to prioritise the menu-to-booking journey. The client’s existing booking provider constrained what could change downstream, so the design needed a clear boundary as well as a clear user goal.
The study also highlighted the social context of booking: guests were checking whether the venue worked for a group. That made dietary choices, per-person pricing and an easy transition to reservation particularly important.
Design for a group decision, on a phone.
The original analytics showed weekday sessions clustering between 5pm and 9pm. Interviews added context: people were coordinating with the family or friends they planned to visit with.
I used that context to prioritise three questions: is there something suitable for everyone, what does it cost per person, and how do we book? The design needed to support those decisions without a long search through the menu.
03 · decisions
Make the menu easier to scan. Keep booking within reach.
I designed category navigation so people could move to the part of the menu they needed, and a persistent booking action so they could proceed when ready. Each intervention addressed a different point of friction in the journey map.
The menu needed to support scanning across choices. The booking control needed to remain visible at the point of intent. I refined content hierarchy, contrast and readability alongside those structural changes.
- Category jump links let guests move directly to starters, mains, sides, desserts or drinks.
- Dietary filters support checking options for different members of a group.
- A persistent Book Now action keeps the next step available from the menu.
- Per-person buffet pricing helps the group judge cost before entering booking.
What I deliberately did not do
No per-dish pricing. It is a fixed-price buffet; pricing added a decision nobody needed. Per-person pricing went on the venue page instead, ahead of the menu.
No search. Tempting, and wrong for the job — people were not hunting a named dish, they were checking the range covered a group. Categories answer that at a glance; a search box does not.
No photography, rebrand or new copy. All would have pushed the build past what the engagement could deliver, and none were what the research pointed at.
Retrospective service view
From choosing a venue to arriving for dinner
Scroll across to explore all stages → Lane labels stay in view.
01Find the venue
Is this place any good, and is it near me?
Searches for a buffet in Stockport. Sees a social post or a recommendation. Lands on the site, usually on a phone.
Search result, social profile, site homepage.
Owner posts to the venue's social channels.
InferredPARTLY VALIDATEDSite hosting, social accounts, business listing.
InferredWeekday sessions clustered between 5pm and 9pm.
—
02Assess the menu
Is there food here that suits all of us?
Opens the menu. Scrolls looking for particular dishes. Checks for vegetarian and halal options. Hunts for the price.
Originally one unsectioned list of 120+ dishes. No booking action anywhere on this page.
THE PAGE THEY CAME FORVenue updates menu content when the buffet offer changes.
InferredMenu held as unstructured content. No dish categories or dietary attributes to navigate by.
InferredINFERRED FROM THE PAGE'S BEHAVIOURMenu-screen drop-off. Client analytics identified the menu as a point of friction before the redesign.
Category jump navigation (starters, mains, sides, desserts, drinks). Dietary filters. Per-person buffet price on the venue page, before the menu.
03Decide as a group
Can we agree, and what will it cost each?
Leaves the site to message the group. Screenshots the menu, sends the link, waits for replies.
Nothing. The service offered no support for this at all, and the guest is off-site when it happens.
None. No one at the venue is aware a group decision is in progress.
Group messaging apps, entirely outside the service.
Interviews identified group coordination as a barrier — participants described coordinating with family and friends before committing.
Addressed indirectly: the two questions a group asks — what does it cost each, and is there something for everyone — were answered across the venue and menu pages before they left the site.
04Book
Get a table for the night we want.
Comes back, looks for a way to book, taps through to the booking journey, enters date, time and party size.
Stampede booking journey. Different look and feel from the site. Outside my design scope.
PROVIDER BOUNDARYBooking arrives with front of house. A table is allocated.
InferredStampede, third-party booking and payment. The one system I could not change.
Booking completion baseline. Client analytics covered the reservation journey; Stampede itself was outside my design scope.
Persistent Book Now, so the next step stayed available from the menu rather than requiring a hunt.
05Confirm and wait
Know it is confirmed, change it if needed.
Receives a confirmation. May need to change the party size later.
Confirmation from the provider, by email or SMS.
Covers checked against capacity for the night.
InferredProvider notifications only. No venue-side communication designed.
InferredNot instrumented.
—
06Arrive and dine
Turn up and be expected.
Arrives, gives the name on the booking, is seated, eats.
Front of house greeting, table, buffet floor and signage.
Table management and kitchen replenishment.
InferredOUTSIDE RESEARCH SCOPEBooking sheet or EPOS at the venue.
InferredNot instrumented.
Out of scope. Included for journey completeness.
What the wider service view makes visible
The gap was a phase, not only a button. The interviews described guests leaving the site to consult the people they planned to eat with. Mapping that group decision alongside the service exposes a gap: the website did not support the coordination happening away from it. Analytics alone described where guests left, not the discussion behind that decision.
The provider boundary moved the work upstream. Booking ran on Stampede, outside my design scope. The work therefore focused on helping guests reach that handoff with fewer unanswered questions. This preserves the key finding from the original journey map: improve the information structure and keep the next action available together.
The content structure needs its own lane. The menu behaved like an unstructured list. Categories and dietary filters addressed that guest-facing problem. The underlying content model is an inference from the page’s behaviour, not something I verified through backstage research.
04 · delivery
From concepts to a delivered journey.
Two AI tools, then my own hands
Wireframing speed was the binding constraint at three to four hours a week, so I generated the flow twice and compared the results rather than defaulting to one tool.
Figma Make assembled a continuous flow quickly and kept everything in one file, but the hierarchy inside the menu screen stayed flat — it reproduced the problem I was trying to solve. Claude, given the interview context, produced a more usable step order and grouped the menu itself. I exported that to PDF, brought it back into Figma as a base, then renamed every layer, re-spaced the grid and gave the booking CTA its own persistent region.
I used the better one as a starting point, not as a deliverable.
Designing around a provider boundary.
Booking and payment relied on Stampede, an existing third-party provider. I could improve the journey leading into that service, but could not redesign the provider itself.
I refined prototypes with the client and technical colleagues, supported handover and stayed involved through implementation. My focus was to preserve the menu hierarchy and the route into booking as the design became a working experience.
That boundary shaped the solution: improve the information and navigation I could influence, and make the transition into the existing booking service understandable.
Use early concepts to establish direction, then refine the design.
I reviewed the prototypes with the client and technical colleagues, using their input to refine feasibility and implementation. These reviews supported delivery; they were not a substitute for a separate usability-testing round.
Inspect the interface at the point of decision.
The high-fidelity sequence connects the venue and menu experience with the downstream reservation journey. My redesign scope ended at the existing booking provider; the later screens are included to show the complete user journey.
The complete composition shows how the menu and the booking journey connect.
05 · outcome
An implemented design, with reported improvement.
Client-reported before-and-after results: bounce fell from 64% to 12% and booking completion rose from 38% to 78%. Menu-screen drop-off fell from 60% to 20% in the same client-reported comparison.
Client-reported before-and-after comparison
Bounce rate
Menu-screen drop-off
Booking completion
Bars use a shared 0–100% scale.
How these numbers should be read
This was a full replacement, not a split test. The client’s setup could not run one, so the comparison is before-and-after on a single site — which means seasonality, marketing activity and the Stampede provider’s own changes all sit inside the result alongside the design.
Two things make me confident the design carried most of it. Traffic volume and the 5–9pm shape were flat across the two periods, so the gain is not more visitors. And the movement is concentrated where the research said the failure was, the menu screen, rather than spread evenly across the funnel.
That is a strong correlation, not proof, and I would present it that way to any stakeholder.
06 · learning
What I would strengthen next time.
The original study identifies two limitations I would change: interviewing participants separately to reduce the influence of a partner’s answers, and making time for task-based usability testing before launch.
The redesign shipped without a separate usability-testing round. Client and technical reviews helped delivery, but did not replace observing people use the proposed design.
With more time, I would test the critical menu-to-booking task before implementation, including finding a suitable category, locating the booking action and understanding the transition into the provider.
I would also agree the analytics event definitions and comparison periods in advance. That would strengthen the evidence for interpreting a change after launch, while still distinguishing a before-and-after comparison from a controlled experiment.
The backstage lanes for booking, confirmation and arrival in the retrospective blueprint are inferred rather than researched, because front of house and kitchen staff were never interviewed.