Guest / Pending
Your request is awaiting a response
Keep the requested date and guest count visible. Explain that this is not yet a confirmed reservation.
DINING MARKETPLACE / Project overview
4 min readPalate Local
Connecting discovery, reservations and host coordination.
Interfaces in development, using example content. Launch outcomes and user-test results are not yet documented here.
The design challenge
Guests need to understand an experience, check availability and make a reservation. Hosts need a clear way to respond to requests and manage changes. The product has to connect both sides of the booking.
The project includes discovery, dining details, checkout, host notifications and account flows across web and mobile.
- Discover
- Review details
- Reserve
- Host response
A closer look at the choices
A retrospective review of the interfaces, the trade-offs they raise and what to test next.
October 2026 · Proposed tests have not been run.
Choice 01
Put booking conditions beside the commitment
Hours, capacity, date, time and guest count sit close to the reservation action.
- Why it matters
- Guests can check whether the experience fits their plans before starting checkout.
- The trade-off
- Showing every condition at once can crowd the form. The essential constraints need priority; longer explanations can sit nearby.
- How to check
- Ask a guest to choose a suitable time and explain the guest limit before proceeding.
Choice 02
Separate a request from a confirmed reservation
The wider design includes pending, confirmed, declined, expired and cancelled notifications.
- Why it matters
- A guest needs to know whether to make plans, while a host needs to know whether action is still required.
- The trade-off
- More states add clarity only if both sides interpret the labels consistently. A generic “success” message can hide that difference.
- How to check
- Use one pending request and one expired request. Ask each participant what happened and what they would do next.
Choice 03
Carry the same details through checkout
Discovery, experience details and checkout are represented across web and mobile.
- Why it matters
- The experience, date, guests and payable total need to stay recognisable as the guest moves toward payment.
- The trade-off
- A short checkout reduces reading but can conceal a changed selection or cost. A concise review step is worth testing.
- How to check
- Check whether guests can spot a changed guest count or total and correct it before payment.
Design exploration · October 2026
One request. Two perspectives.
A small interaction study built for this portfolio review. It explores how existing booking-state labels could guide guests and hosts; it is not the client’s implemented flow.
Host / Pending
A request needs your attention
Show the requested date and party size alongside the actions to accept or decline.
Design considerationThe same state creates different needs: reassurance for the guest, a decision for the host.
Guest / Confirmed
You can prepare for your visit
Show the agreed date, time and guest count, with directions and a way to contact the host.
Host / Confirmed
Plan for the expected guests
Keep the confirmed details accessible so the host can prepare for the visit.
Design considerationConfirmation should move both people from waiting to preparation.
Guest / Declined
This request could not be accepted
Use clear, considerate language and offer a route back to other experiences.
Host / Declined
The guest needs a clear response
Make the decision explicit and keep a record of the request and response.
Design considerationA recovery path matters more than a generic error message.
Guest / Expired
This request is no longer active
Distinguish expiry from a host declining. Explain that the guest must check availability again.
Host / Expired
This request cannot be confirmed as-is
Separate inactive requests from those that still need a response.
Design considerationAn expired request must not look like an active reservation on either side.
Guest / Cancelled
The reservation is no longer going ahead
State what changed and where to find the relevant cancellation and payment information.
Host / Cancelled
Update the plan for this booking
Show the cancellation clearly in the booking record so preparations can be adjusted.
Design considerationAvoid promising a refund or released capacity until the actual product rules are agreed.
Proposed communication only. Timing, payment and cancellation rules need confirmation with the product team and testing with users.
What to validate next
Priorities for the next iteration.
Start with comprehension of availability and booking status. Then test whether guests and hosts can recover from a request that cannot proceed.