With the experience I’ve accumulated in the financial sector, I’ve had the opportunity to take on several independent consulting projects on the side. One of those projects left me with a lesson I won’t forget:

Sometimes, the smallest design decisions can have consequences many times larger than they appear.

It was about a monthly automatic payment feature in a financial app. The feature helped customers with installment loans avoid having to remember their payment dates. They only needed to link their e-wallet once—the money would then be automatically deducted each month.

In practice, this was a “win-win” feature. The company reduced bad debt, while customers reduced the risk of forgetting their payment dates. I was genuinely happy to see the feature added to the app.

Until one meeting, when the PO made a very small request:

“Remove the Cancel button. Don’t let customers cancel automatic payments themselves in the app. If they want to cancel, they can go to MoMo and figure out how to do it there.”

Can a small request hide a much bigger trade-off?

“This will put users at a disadvantage.” That was the first thought that came to my mind.

THE PO’S PERSPECTIVE: WHEN KPIs CLASH WITH EXPERIENCE

I put myself in the PO’s position and could partly understand the reason behind the request. The automatic-payment cancellation rate was a number being tracked every week. It was tied to debt collection KPIs and pressure from management. Hide the Cancel button, the cancellation rate goes down, and the report looks better. So that number was directly tied to job security—it wasn’t simply a matter of being unreasonable.

If we kept the Cancel button, users could cancel automatic payments. The company would also lose some of the advantage of automatically collecting repayments. That was true too. But before deciding whether to keep or remove the Cancel button, I thought there was a question we needed to answer first.

Why would a customer want to cancel this feature after signing up for it?

The answer would help us determine whether the Cancel button was actually necessary—not make a right-or-wrong judgment based on instinct.

THE FEAR OF THE FINAL PAYMENT

Customers may worry that they will still be charged after fully repaying their loan if they cannot manually stop the automatic payment process themselves.

That was the first reason that came to mind—but after thinking it through, I knew it wasn’t strong enough. Technically, the development team could program the system to stop deducting money immediately after the final payment. At the same time, it could send a confirmation that the loan had been fully repaid and automatic payments had been canceled. So the scenario of “I’ve already paid off my debt but the system still charged me” would not actually happen. It was a real concern only during the period before the final payment was due—when customers did not yet know for certain whether the system would stop at the right time.

BREAKING DOWN THE PROBLEM

More fundamentally, customers may want to take control of automatic payments for very practical reasons:

• Temporary financial difficulties: A customer loses their source of income and wants to choose their own payment date within the allowed window rather than having the system automatically deduct money on a fixed date, potentially causing a failed payment and resulting fees.
• Uncertainty about the amount being charged: Even when the system deducts the correct amount, customers may not feel comfortable when they cannot personally check the amount due before the money is taken.
• Changing or closing an e-wallet: A customer stops using that e-wallet, switches to another one, or closes the account. They need to disconnect the old wallet before a transaction failure occurs.
• Control over personal cash flow: The automatic deduction date does not coincide with payday, causing the account to go into overdraft or incur bank fees. The customer wants to choose a different payment time or method.

THE TRUE NATURE OF THE CANCEL BUTTON

These reasons have one thing in common: they are not rare edge cases. In many situations, customers need to stop the process immediately, through the same channel where they originally signed up—not search through another channel where they never enrolled just to find a way to cancel.

That is when the true nature of the Cancel button becomes clear. It is not a secondary feature. It is a safety valve for users when their circumstances change faster than the process can respond.

I presented these reasons to the PO so we could determine together: If these cancellation needs are legitimate and could happen to any customer, hiding the Cancel button does not eliminate the need. It simply pushes customers to find another way—slower, harder, and more frustrating.

Let the data answer for itself

But if I wanted to convince the PO, asking “Why do customers cancel?” was not enough. That was still an assumption, not evidence. So I suggested measuring actual user behavior after hiding the button: the number of support tickets related to “I can’t find a way to cancel,” negative app-store reviews, and how often customers called the hotline to complain. If my assumption was wrong—if almost no one actually needed to cancel—then my concerns would also turn out to be assumptions, and I would have learned a different lesson.

And the final card I used to persuade the PO was not about ethics, but operational risk:

“If customers cannot cancel where they originally signed up, could this violate any regulations? If so, who would be responsible when a complaint is filed?”

I also needed time to investigate that risk myself.

It was not a random question. It was a way of framing the discussion. Instead of arguing about right or wrong, I asked a question that they would have to answer themselves. If a real issue existed, they would discover the contradiction in their own decision. There was no need to turn it into a competition in the meeting—just ask the right question.

The PO wasn’t sure of the answer either. And an unanswered question involving the word “violation” is something anyone in that position would need to stop and verify before moving forward—not because they had been persuaded, but because product people have a responsibility to be careful.

Numbers don’t lie, but they don’t tell the whole story either

A few weeks after the feature launched, the data began to reveal part of the story that the cancellation-rate report could not show.

Support tickets asking “How do I cancel automatic payments?” started increasing. Some customers, unable to find a Cancel button in the app, left negative public reviews—something that had not happened before.

The call center began receiving complaints. Most reflected the same sentiment:

“Why can’t I stop the automatic deduction in the app, right where I manage automatic payments?”

The cancellation rate in the report remained low—exactly as originally intended. But it wasn’t really a good number. It was a silent number. It did not reflect satisfaction; it was simply hiding dissatisfaction somewhere else—where customers had to struggle to find their way out instead of being given a straightforward way to do so.

Combined with the legal question the PO was still trying to answer, the picture became clearer.

The Cancel button was added back to the app.

Why “Hide the Cancel Button” is more dangerous than an ordinary UX decision

FROM A LEGAL PERSPECTIVE

Intentionally designing a product so that customers cannot proactively stop a service where they signed up for it is no longer merely a debate about user experience (UX).

After looking into it, I found that Vietnam’s 2023 Law on Protection of Consumer Rights contains provisions related to consumers’ right to unilaterally terminate continuous service contracts, while also tightening requirements around continuing transactions without providing a clear mechanism for consumers to choose whether to continue or stop.

So the question for the PO was no longer simply “Should we keep or remove a Cancel button?” It had become a matter that needed serious legal review.

FROM A PSYCHOLOGICAL PERSPECTIVE

The implicit assumption behind hiding the Cancel button—that taking away customers’ ability to cancel would pressure them into repaying their debt more reliably—was no longer convincing. Customers might indeed feel powerless, but that could trigger other negative consequences.

People who borrow money are already under pressure to manage their finances. Hiding the Cancel button may make it easier for the company to collect repayments, but it creates another kind of anxiety for users: the loss of financial control.

In psychology, the concept of financial locus of control suggests that financial pressure itself does not necessarily break people down; the feeling that they cannot make decisions for themselves about their own money can be more damaging. When people lose their sense of agency, they do not necessarily become better at repaying debt. They may simply become exhausted and look for any way out of the system—even ways that ultimately hurt the business.

FROM A USER-CENTRIC PERSPECTIVE

The need does not disappear. It moves to support, the call center, reviews, and complaints. Removing the Cancel button only creates more friction, and that friction becomes where complaint risk emerges.

Every time friction is deliberately introduced, users may still pay—but they stop trusting the product. That is a silent trust debt accumulating in the background, one that does not appear on any financial report.

More importantly, the feeling of being “unable to get out” does not disappear even after customers eventually manage to cancel through another app. They carry that feeling with them, and it can influence whether they choose to use any other product from the company in the future.

Let users remain in control

The cancellation rate is real pressure, driven by a legitimate goal: helping customers repay their debts on time. But in product design, every idea needs to be evaluated from multiple perspectives. And there is never only one idea for solving a problem.

Keeping someone by blocking the exit is not retention—it is captivity. It just goes by a different name in the report.Trading a short-term good-looking number for a trust debt that must be paid later, in a form no report can measure—is that really worth it?