The Hidden Friction in a “Change Plan” Journey
“Sometimes the biggest UX problems aren’t in the main flow. They’re in what happens when users change their minds.”
When designing a Change Plan feature for a sports management platform, the primary user journey seemed straightforward.
A student could:
- Navigate to My Plan.
- Tap Change Plan.
- Browse available plans.
- Select an effective date.
- Submit the request.
The request would then appear in the admin portal, where an administrator could review it, update the student’s package, and even change their assigned batch if necessary.
Everything worked.
Or so I thought.
The Edge Case That Changed Everything
While reviewing the complete journey, I noticed an important business rule:
A student can submit only one plan change request per month.
That meant if a student accidentally chose the wrong package or changed their mind before the request was approved, they couldn’t simply submit another request.
Their only option was to withdraw the existing request.
On paper, this solved the problem.
But from the user’s perspective, it introduced a new one.
The Missing Piece
Imagine this scenario.
You request to upgrade from a one-month package to a three-month package. A few minutes later, you realize you selected the wrong plan. You withdraw the request.
And then…It disappears. There is no confirmation.
No history. No indication that a request was ever made.
The screen simply returns to its original state.
Get Bindu Dayanand’s stories in your inbox
Join Medium for free to get updates from this writer.
As a user, questions immediately arise:
- Was my withdrawal successful?
- Did my request actually get cancelled?
- Can I submit another request now?
The system knew the answer.
The user didn’t.
The Solution
Instead of treating withdrawn requests as deleted, I introduced a lightweight Request History page.
From the Change Plan screen, users can now access their previous requests through a simple text button.
Each request displays its current status, such as:
- Pending
- Approved
- Rejected
- Withdrawn
Now, withdrawing a request no longer feels like deleting it.
It becomes another state in the request lifecycle.
Users gain visibility into what happened and confidence that the system has recorded their action.
Why a Separate Page?
One option was to show previous requests directly on the Change Plan screen.
I decided against it.
The primary goal of that screen is to help users submit a new request.
Adding historical information would compete for attention and increase visual complexity.
Instead, a secondary text action keeps the main flow focused while making request history available whenever users need it.
What I Learned
This project reminded me that successful UX isn’t only about helping users to complete tasks.
It’s also about helping them understand what happened after they completed them.
Sometimes, the most valuable design decisions come from asking one simple question:
“What happens after this?”
In this case, answering that question transformed a disappearing action into a transparent, trustworthy experience.
