Skip to content
EN
EN RU
Previous Case

Case study / Mobile banking

Handing over a shared booking

Shared bookings in a UK mobile bank helps a group pay for a booking such as a sports venue or class. One person organises it and keeps track of everyone’s payments. I designed a handover so another participant can take the role and agree to cover any unpaid amount. The booking, places and existing payments stay in place.

Role
Product Designer
Team
1 designer / 2 developers
Project
Rovelle
Platform
Mobile app
Shared booking. The organiser sees the group’s payments and can start handing over their role.

01

Problem

Each participant pays their share of a group booking. The organiser keeps track of the payments and covers any amount the group has not paid.

When the organiser can no longer manage the booking, the group may have to cancel and collect payment again. My task was to let a willing participant take over while keeping the booking and everyone’s existing payments. The feature is available for venues that support a change of organiser.

To cover a possible shortfall, the bank sets aside the new organiser’s own money. It stays in their account but is temporarily unavailable to spend. The outgoing organiser’s place and payment credited to them stay with the booking.

02

Research

Product goal

Keep the booking when the organiser changes

Help the group keep the service and paid shares while a willing participant takes over. The interface needed to explain future costs and temporarily unavailable funds, separate them from a personal share and show when the handover is complete.

I reviewed how banks split shared costs and how booking services change participants. I checked what happens to the booking, paid shares and unpaid amounts when its organiser steps down.

I then examined what the sender needs to understand and what the recipient accepts. Across 19 scenarios, I checked acceptance, insufficient funds, declining, cancellation and delayed confirmation. This separated personal payments, the organiser’s future costs and the conditions for a completed handover.

Products compared
4
Monzo, Starling, MATCHi and Playtomic: shared payments and changing the organiser.
Roles
2
The organiser sends an invitation; another participant accepts or declines it.

The intended outcome was keeping the booking with clear responsibility for the remaining cost. Changing a name or transferring a share does not provide that outcome on its own.

  • Product comparison
  • Booking-rule review
  • User journey map
  • UX review
  • Figma scenarios

I looked first at familiar ways to split a cost, then at the booking services’ restrictions. These materials defined the conditions the interface needed to explain before a handover.

Monzo and Starling

Monzo and Starling let people split a cost and request shares. I placed Shared bookings in the familiar Payments section and focused this case on changing the organiser of an existing booking.

MATCHi and Playtomic

Under the MATCHi rules, the organiser covers unpaid shares but cannot transfer that responsibility. Playtomic’s help page directs an outgoing owner to cancel and make a new booking. I made keeping the booking and existing payments the central outcome of the feature.

How the money works

Payment documentation helped separate a reserve from a payment. Money set aside has not yet been paid to the venue. I showed the amount, expected restriction period and possible delay before the new organiser accepts.

03

Insights

An invitation does not change the organiser

The recipient may accept, but the handover is complete only after the venue confirms it. I separated sending, accepting and completing it so each person knows what they are still responsible for.

BasisUnder the rules reviewed, the organiser covers payment for the whole booking. Agreement between participants does not mean the venue has confirmed a new organiser.

The current unpaid amount is not the maximum

Another participant may still get their share refunded while the booking’s total price stays the same. The new organiser may need to cover more than is unpaid today. I showed the maximum and explained its breakdown.

BasisI reviewed a scenario with unpaid shares and a permitted refund of an existing payment.

You can hand over the role and keep your place

Someone may stop managing a booking while still attending. I showed their place and payment separately so the handover would not look like a refund or a transfer of their place.

BasisOne person both organises the booking and participates in it. Handing over the first role should not automatically change their personal place or payment.

04

Jobs and hypotheses

The research led to the organiser’s and recipient’s jobs, followed by hypotheses about the value of the handover and the clarity of its terms.

The organiser’s job

When I can no longer manage our shared booking and the group wants to keep it, I want to agree who will organise it and cover any missing payment, so the event can go ahead without cancelling and collecting money again.

The recipient’s job

When I am asked to take over a shared booking, I want to understand what I will need to do and how much money I may need to cover, so I can decide whether to accept.

Value hypothesis

B1

Handover without collecting payment again

If another participant can take the organiser’s role and agree to cover future unpaid costs while keeping the booking and paid shares, the group will not need to cancel the event and collect money again.

Basis
The Playtomic route reviewed leads to cancellation and rebooking when the organiser leaves. A well-run manual handover with the venue remains an alternative.
How I tested it
I compared the outcome with a good manual route: keeping the time, payments and places. I would reconsider the flow if the venue cannot confirm a transfer or the manual route takes less effort.

Checked in the prototype

The route keeps the booking and the group’s payments. A fully and finally paid booking transfers the role without a new reserve.

Design decision

I kept the action inside the existing booking and added a separate route with no future payments.

Interface hypotheses

I1

Terms are clear before acceptance

If the maximum, available balance and expected restriction period appear before acceptance, the recipient will be able to explain the amount they are accepting and distinguish a reserve from a payment.

Basis
The recipient agrees to make personal funds temporarily unavailable to cover possible unpaid costs for the booking. They need the maximum, available balance and expected settlement time to assess that decision.
How I tested it
I asked for the maximum, available balance, timing and difference between a reserve and a payment. All four had to be correct without a hint. Repeated errors meant revisiting the order and wording.

Supported in validation

10 of 12 participants answered correctly after the changes, compared with 6 of 12 in the early version.

Design decision

I moved the financial summary to the top, named the action and amount in the button, and explained the maximum nearby.

I2

The role is distinct from a personal share

If the review separates the new organiser’s responsibilities from the sender’s personal share, the sender will not mistake the handover for a refund or a transfer of their place.

Basis
The organiser covers the shared cost while remaining a participant with a personal share. Changing responsibility does not transfer their place or refund their payment.
How I tested it
I asked what happens to the personal place, existing share and remaining cost. All three distinctions had to be correct without a hint. Errors meant revisiting the invitation review.

Supported in validation

11 of 12 participants explained the distinction after the changes, compared with 8 of 12 in the early version.

Design decision

I separated the new organiser, their responsibilities and the sender’s personal place. The updated booking shows the previous organiser’s paid share unchanged.

I3

Waiting is distinct from completion

If an invitation, a confirmed transfer and an unconfirmed result have different wording and actions, people will be able to tell whether the handover is complete and what to do next.

Basis
The invitation, the recipient’s acceptance and the venue’s confirmation happen at different moments. Accepting the role does not yet confirm the handover or release the previous reserve.
How I tested it
I asked for the result and a safe next step. The answer had to avoid claiming a changed organiser or available funds before confirmation. Errors led me to revise the status and main action.

Supported in validation

11 of 12 participants identified the outcome and next step in the revised version, compared with 7 of 12 in the early version.

Design decision

I separated a sent invitation from a confirmed handover. If the recipient does not yet know the outcome, they check the same request without accepting again.

05

User journey

The map follows the person handing over the organiser’s role. At each stage, I connected their difficulty with my interface decision.

Role
Organiser of a shared booking
Situation and goal
Hand over the role to another participant while keeping the booking and the group’s existing payments.
Previous journeyMy design decisions

  1. Decide what to do with the booking

    Goal
    Keep the event for the group.
    Actions and touchpoints
    Opens the booking and discusses changed plans with the group.Booking / group chat
    Difficulty
    One person’s changed plans may lead to cancellation for everyone.
    What they need
    Find a way to hand over managing the booking.
    My decision
    Added Change organiser to the existing booking.
    Screens

  2. Agree with another participant

    Goal
    Find someone willing to take over.
    Actions and touchpoints
    Asks who will manage the booking and cover the remaining cost.Group chat / participants
    Difficulty
    A friend’s agreement in a chat does not change the organiser at the venue.
    What they need
    Know who can accept the role and what it involves.
    My decision
    Showed an eligible participant and the terms before sending an invitation.
    Screens

  3. Send an invitation

    Goal
    Get agreement to clear terms.
    Actions and touchpoints
    Passes on booking details and checks them with the administrator.Messages / venue administrator
    Difficulty
    Terms, amounts and deadlines are scattered across messages.
    What they need
    Review the handover terms in one place.
    My decision
    Grouped the new organiser, payment and deadlines in the invitation review.
    Screens

  4. Wait for a reply

    Goal
    Know whether the participant is willing to take over.
    Actions and touchpoints
    Checks whether the participant agrees to become the organiser.Messages / participant
    Difficulty
    Without an explicit reply, it is unclear whether the handover can continue.
    What they need
    See the invitation status and reply deadline.
    My decision
    Showed the pending invitation, reply deadline and withdrawal before acceptance.
    Screens

  5. Check the outcome

    Goal
    Confirm the other participant is now the organiser.
    Actions and touchpoints
    Checks the venue’s response and the money.Confirmation / account
    Difficulty
    A new name does not explain whether funds are still unavailable.
    What they need
    See the new organiser and release of their own reserve.
    My decision
    The confirmed outcome shows the new organiser and release of the sender’s reserve.
    Screens

  6. Return to their own participation

    Goal
    Keep the place and paid share.
    Actions and touchpoints
    Checks their payment and place at the event.Booking / personal share
    Difficulty
    Handing over the role can be mistaken for leaving the booking.
    What they need
    Know what stayed unchanged.
    My decision
    Kept the personal place and payment in the updated booking.
    Screens

Changing the organiser does not replace a personal refund or cancellation of the service. Those actions keep the venue’s separate conditions.

06

Interface decisions

I placed the handover in Payments. From the current booking, people move through an invitation, acceptance and confirmation without creating a new booking or requesting everyone’s payment again.

Understand the amount before accepting

The recipient sees how much the bank will set aside and what remains available to spend. I included the expected settlement date and a warning about possible delays. The maximum includes unpaid shares and a possible refund of another share while the venue allows it. Insufficient funds show the amount needed. No new reserve is created when all payments are final and no future costs remain.

Screens by stage

Choose a screen or scroll the row. Open any design to inspect the full screen.

The organiser sees the group’s payments and can start handing over their role.
Shared booking. The organiser sees the group’s payments and can start handing over their role.

The organiser sees the group’s payments and can start handing over their role.

On the screenChange organiser / People / Still to be paid

An eligible participant can be selected. No invitation has been sent yet.
Choose a new organiser. An eligible participant can be selected. No invitation has been sent yet.

An eligible participant can be selected. No invitation has been sent yet.

On the screenBen / Review invitation

Invitation review. The new organiser’s responsibilities are separate from the sender’s personal place and paid share.
Review the invitation. Invitation review. The new organiser’s responsibilities are separate from the sender’s personal place and paid share.

Invitation review. The new organiser’s responsibilities are separate from the sender’s personal place and paid share.

On the screenNew organiser / What Ben will take over / Your place and paid share

Before accepting, the recipient sees the reserve, available balance and expected settlement time. Insufficient funds show the amount needed.
Accept the invitation. Before accepting, the recipient sees the reserve, available balance and expected settlement time. Insufficient funds show the amount needed.

Before accepting, the recipient sees the reserve, available balance and expected settlement time. Insufficient funds show the amount needed.

On the screenAccept and set aside £90.00 / Add money / Decline

An invitation can be withdrawn before it is accepted. Sending it does not transfer the organiser’s role.
Invitation sent. An invitation can be withdrawn before it is accepted. Sending it does not transfer the organiser’s role.

An invitation can be withdrawn before it is accepted. Sending it does not transfer the organiser’s role.

On the screenInvitation sent / Withdraw invitation

Ben is now the organiser and keeps his reserve. Alice sees that her previous reserve has been released.
Handover complete. Ben is now the organiser and keeps his reserve. Alice sees that her previous reserve has been released.

Ben is now the organiser and keeps his reserve. Alice sees that her previous reserve has been released.

On the screenBen: Booking transferred / Alice: Your £90 has been released

Of the £90 reserve, £60 was paid and £30 released. The settlement date does not promise release of the entire reserve.
Reserve and payment outcome. Of the £90 reserve, £60 was paid and £30 released. The settlement date does not promise release of the entire reserve.

Of the £90 reserve, £60 was paid and £30 released. The settlement date does not promise release of the entire reserve.

On the screenWhat the reserve covers / Paid to Northside Padel

The organiser has changed, while the personal place and paid share stay intact.
A personal place after the handover. The organiser has changed, while the personal place and paid share stay intact.

The organiser has changed, while the personal place and paid share stay intact.

On the screenOrganiser / Your place and payment

The recipient checks the result of the same request. While the outcome is unknown, no repeat acceptance or new payment is offered.
Checking the result. The recipient checks the result of the same request. While the outcome is unknown, no repeat acceptance or new payment is offered.

The recipient checks the result of the same request. While the outcome is unknown, no repeat acceptance or new payment is offered.

On the screenChecking the result / Check status

When all payments are final and no future costs remain, only the role changes. No new reserve is created.
A fully paid booking. When all payments are final and no future costs remain, only the role changes. No new reserve is created.

When all payments are final and no future costs remain, only the role changes. No new reserve is created.

On the screenTake over organising / Organiser changed

07

Design validation

The prototype tasks tested three distinctions: a reserve versus payment, the organiser’s role versus a personal place, and acceptance versus a completed handover. I asked people to explain what an action would change and name the next step.

Reserve terms

Difficulty
The early review could show the acceptance button before the amount, available balance and timing. The recipient could mistake the reserve for payment and miss why the maximum exceeds the current unpaid amount.
What I changed
I moved the financial summary up in the acceptance view and explained the maximum. Reserve details separate unavailable funds from the later payment and release of the remaining amount.

A role and a personal place

Difficulty
“Hand over the booking” could mean giving away a personal place or refunding a paid share. Someone may still attend after they stop organising it.
What I changed
The invitation review separates the new organiser’s responsibilities from the sender’s personal participation. The booking after the handover retains their place and paid share.

Acceptance and completion

Difficulty
The recipient may have accepted while the venue has not yet confirmed the transfer. The role and release of the previous reserve cannot yet be treated as complete.
What I changed
I showed the invitation separately from the confirmed result. An unconfirmed result lets the recipient check the same request rather than accept or pay again.

08

Results

I designed an organiser handover within an existing shared booking. The recipient sees the responsibilities and money before accepting, and both people receive a clear confirmed outcome. The group keeps its places and existing payments.

In design review, I showed what changes for each person before and after acceptance. We focused on the maximum future cost, the unchanged personal share and the point of completion. These distinctions shaped the invitation review and the confirmed outcome.

I then compared the early and revised prototypes. Over six working days, 12 participants completed tasks in both versions. Half started with each version, using different bookings of the same difficulty.

Understand the handover terms
Early version2:30
Revised prototype2:06
min:sec 16% less time
From opening the invitation to correctly explaining the maximum, available balance, timing and next action. Time spent receiving hints was included.
Understood the reserve terms
Early version6 of 12
Revised prototype10 of 12
4 more people
Named the maximum, balance and timing without a hint, explaining that money set aside had not yet been paid to the venue.
Understood the transfer result
Early version7 of 12
Revised prototype11 of 12
4 more people
Identified the confirmed outcome and next step without assuming funds were available while the result was still being checked.

Each median uses 12 measurements per version. The time reduction is the difference between medians divided by the original 2:30. All tasks were eventually completed correctly with help included; independence counts only answers without hints. The comparison concerns prototype tasks, not the venue’s or bank’s processing speed.

Risk detail and register with connected context

Next case study

Assessing and reviewing company risks / Easycompliance

Continue

Let’s Connect

Download CV