Friction patterns

I redesigned and built a demo to showcase some better friction patterns that I think would really improve the aava experience (I also did some visual redesigning for fun!). I will discuss the changes below.

I agree with the broad position that DeFi interfaces should remain open.

If someone really wants to perform an extreme action, the UI should not become paternalistic to the point that it blocks legitimate agency. Crypto is valuable precisely because protocols are permissionless and users can act without asking for approval.

But that does not mean every confirmation pattern is equally responsible.

There is a huge difference between:

• allowing a dangerous action after the user clearly demonstrates understanding
• allowing a dangerous action because they tapped through a familiar warning ritual

Those are not the same thing.

A checkbox is often treated as proof of informed consent. In reality it is usually proof that a user wanted to continue.

That distinction is everything.

Designers often add friction as if the goal is simply to slow a user down.

That is not enough.

Useful friction does one of three things:

1. It interrupts autopilot
2. It translates risk into human terms
3. It verifies intent before irreversible execution

A checkbox mainly does the first, and even that weakly.

People have been trained by the modern internet to blast through consent modals, cookie banners, app permissions, warnings, and legal notices. They do not read them with fresh eyes. They pattern-match them. They assume they are another small speed bump between themselves and their goal.

So when someone is about to move $50 million through a route that will clearly produce an absurdly bad outcome, a lightweight pattern like a single checkbox is not really a safeguard. It is ceremony.

And ceremony is not protection.

One of the biggest design mistakes in finance is presenting an abnormal action inside a normal-looking flow.

If the screen still feels like a standard “review and confirm” experience, the user’s brain keeps running the same mental model: I am doing a trade.

But in this case, the reality is closer to: I am about to donate an enormous amount of money to the market by accepting extreme price impact.

Those are wildly different things.

The interface needs to reflect that difference visually, verbally, and structurally.

If I were redesigning this kind of flow, I would not just add another warning line. I would switch the entire UI into a critical-risk confirmation state.

That means:

• stronger visual contrast and a clear break from the default trading UI
• a short, explicit summary of what will happen in dollar terms
• removal of ambiguous or euphemistic language
• a requirement for the user to actively demonstrate that they understand what they are about to do

Not because the protocol should forbid it.

Because the interface should be able to say: if you continue, it is now beyond doubt that you understood the likely outcome.

That protects the user, and it also protects the product.

This incident is a reminder that design patterns are not decorative.

They govern real outcomes.

In crypto especially, where transactions are final and there is often no central party to reverse mistakes, UX decisions are part of the safety model. Confirmation flows, language choices, hierarchy, delay, contrast, and interaction structure all shape whether a user truly understands what they are doing.

That means friction is not the enemy.

Bad friction is the enemy.
Performative friction is the enemy.
Friction that looks compliant but fails to create understanding is the enemy.

The right friction is what stands between intention and disaster.

And sometimes, that difference is worth millions.