Imagine you work in customer service for a large camper rental company. You need to tell a customer that she has to be rebooked to a different model because her preferred camper is unavailable. She decides to cancel the entire booking because she is not satisfied with the new model. When you try to process this request in the internal software and cancel the booking free of charge, you are shown the following modal:
Would you intuitively know what would happen when confirming this modal? If your answer is no, then your experience is similar to the users of the software where this modal was used. The team trained each other internally and created extensive documentation with screenshots explaining which button to click in which situation to keep this step somewhat manageable.
Besides the modal’s pure complexity, at a certain point there was also an irregular but fatal software bug that caused incorrectly sent emails and hard-to-fix errors in the database. All of this eventually led to major uncertainty and real stress whenever users interacted with this screen, which made a redesign of the process urgently necessary.
No time to keep reading? Here is the final redesign result:
I’ll walk you through each redesign step and its impact in the deep dive below. 🤿
The Difference Section - too much information overwhelms users
This section breaks down all amounts related to the booking adjustment in an extremely detailed and technical way. On the left, you see the pure before-and-after change list, and on the right, additional relevant sums such as already paid or already invoiced amounts are listed - very overwhelming, and in most cases not really relevant. Ultimately, the only thing that really matters is the total difference of the change, because that is the basis for further processing.
For this reason, I redesigned this section into a classic collapsible area. All detailed information is still available in case it is needed for traceability, just hidden by default.
The Action Section - cryptic button labels and unclear outcomes
You’ve probably already wondered what the cryptic number-letter combinations in the middle of the modal mean. A reduction in booking value can be handled in three different ways:
- Refund
- Coupon
- Fee
Depending on selected cancellation policies and the timing of the booking adjustment, it can also be a combination of multiple types, for example 50% of the booking value as a refund and 50% as a coupon. So these labels represent the resolution type of the difference:
- 100R means 100% refund
- 50R/50C means 50% refund and 50% coupon
- 100C means 100% coupon
- … and so on
Clicking one of these “codes” changes the absolute values in the grayed-out input fields below, and that ultimately determines how the booking value is settled. Yes, you read that right, the most important piece of information in the entire modal, namely what happens after confirmation, is hidden in these extremely hard-to-read input fields. By default, they are not editable, only “Manual override” allows entering custom values.
I replaced this admittedly “quirky” UI with a clear question and a tab switcher.
To prevent mistakes, no option is preselected by default. The user must deliberately choose a handling method before the action can be completed.
The first option, “As booked” processes the difference amount automatically based on the booked cancellation policy. If customer service wants to deviate from this policy as a goodwill gesture, the most common alternatives are either a full refund or issuing a coupon. For all other special cases, there is the “Custom” tab, which contains the known input fields.
The Finalization Section - “Cancelling the Cancel”
There was one last UX issue to solve. Normally, the application uses the word “Cancel” to abort an action. In the case of a cancellation, however, “Cancel” is actually the right word to confirm the operation. The solution here was to use the alternative word “Abort” in this specific case to minimize confusion.
Here is the complete redesigned modal once more:
After I implemented the redesign and it went live in production, usage errors in booking adjustments/cancellations dropped drastically, which significantly reduced the service team’s workload and restored their trust in the software.
The engineering team responsible for manual database error corrections also benefited from the lower error rate. Instead of fixing around three to five errors per month during peak season as before, after the redesign it was only two to three per year, and even those only in extreme edge cases.