“Maybe Later” Is UX’s Nicest Lie

I was watching a user session recording last Tuesday when it hit me.

The user had just signed up for this productivity app I was helping optimize. They landed on the dashboard, and immediately a modal popped up: "Welcome! Let us show you around." Big blue button saying "Get Started," smaller gray one saying "Maybe Later."

They clicked "Maybe Later" without even reading the headline.

Three minutes later, they were clicking randomly around the interface, clearly lost. Five minutes after that, they closed the tab and never came back.

This person wanted to succeed. They'd just paid for a subscription. They'd taken time out of their day to try something new. But we'd trained them, in that first moment, to choose ignorance over guidance.

And the worst part? We thought we were being polite.

The Lie We Tell Ourselves About Choice

"Maybe Later" feels like good UX, doesn't it? We're giving users control. We're not being pushy. We're respecting their autonomy.

I used to think this too. I'd design these elegant modals with careful copy and thoughtful interactions, then slap a "Maybe Later" button in the corner because, well, what if someone doesn't want to see this right now?

But here's what I've learned from watching hundreds of user sessions: "Maybe Later" almost never means "later." It means "never," with extra steps.

I started tracking this obsessively across different products. Users who clicked "Maybe Later" on onboarding flows had much more higher churn rate than those who completed the guidance. Not because they were less engaged, they'd literally signed up minutes earlier, but because we'd given them permission to stay confused.

What That Button Actually Does to People

When you put a "Maybe Later" button on something important, you're not just offering an escape route. You're sending three devastating messages:

You're telling them this isn't urgent.
If it really mattered, you wouldn't make it skippable. That's the subtext users absorb, even if they don't consciously think it.

You're making them choose before they understand.
It's like pausing someone mid-recipe and asking if they want to skip the part about preheating the oven. They say yes because they're overwhelmed, not because they don't need the information.

You're deferring their success, not the friction.
Every piece of guidance they skip now becomes a problem they'll hit later - except now they'll be alone when they hit it.

I learned this the hard way working with a team whose users kept churning after the trial period. We couldn't figure out why until we started mapping the user journey from signup to cancellation. The pattern was heartbreaking: users would skip onboarding, struggle with basic tasks, submit support tickets for things we'd tried to teach them on day one, then leave before support could help.

We weren't respecting their choice. We were abandoning them to failure.

The Moment I Changed My Mind

A few months ago, I was user-testing a new feature for a design tool. This woman (let's call her Sarah) had just discovered our collaboration features for the first time. A tooltip appeared explaining how shared cursors worked, with a "Got it" button and a "Maybe Later" option.

She clicked "Maybe Later" immediately. Not because she wasn't interested, but because she was in the middle of something else and the interruption felt jarring.

Ten minutes later, she tried to collaborate with her teammate. She couldn't figure out why she couldn't see his cursor. She spent five minutes looking for settings, getting increasingly frustrated. Finally, she messaged him: "Is this thing broken?"

She wanted to learn. She needed to learn. But we'd taught her to defer learning until she was already failing.

That's when I realized: the problem isn't that we're giving users choices. The problem is that we're giving them the wrong choices at the wrong times.

What Users Actually Need

I started paying attention to apps that felt effortless to learn. The pattern was clear: they didn't ask users to choose between learning and doing. They wove learning into doing.

Figma doesn't interrupt you with feature tours. But when you first try to create a component, gentle guidance appears contextually, right when you need it. Linear doesn't force you through setup flows, but their interface is so clear that you naturally discover features as you need them.

The best onboarding doesn't feel like onboarding at all. It feels like the product being helpful at exactly the right moment.

How to Design for Real Human Behavior

Here's what I do now instead of "Maybe Later" buttons:

I design guidance that feels native, not interruptive.
Instead of modal overlays, I use contextual hints that appear when users actually attempt something. Instead of front-loading everything, I surface help when it's relevant.

I anchor learning to outcomes, not features.
Don't teach "how to use tags." Teach "how to find this project again next week." When guidance is about achieving goals, people engage with it.

I make skipping possible but not frictionless.
If someone really wants to skip something important, they can - but they have to work slightly harder for it. A small confirmation that says "This will help you avoid common mistakes - sure you want to skip?" isn't dark patterns. It's context.

I create visible paths back to guidance.
If users aren't ready now, they need to know where to find help later. I make sure there's always a clear "Show me how this works" option that doesn't require digging through help docs.

The Products That Get This Right

I've been studying apps that have low support volume and high activation rates. None of them use "Maybe Later" buttons for important flows.

Notion drops you into a sample workspace that demonstrates capabilities through example, not explanation. You learn by exploring, not by watching.

Stripe's documentation is embedded right in their interface. When you're setting up payments, the guidance is right there, contextual and unobtrusive.

What I Learned About Respect

The biggest mindset shift for me was realizing that letting users skip important guidance isn't respectful - it's neglectful.

Real respect means designing experiences that help people succeed, even when they don't know what they need yet. It means being confident enough in your product's value to guide people toward it, not hoping they'll stumble into it eventually.

I think about Sarah a lot. She didn't want to defer learning; she wanted to learn at the right time, in the right way. We failed her not by being too pushy, but by being too passive.

The Hard Truth

"Maybe Later" buttons feel safe to ship. They give us plausible deniability: "We offered guidance. They chose not to take it."

But that's not product thinking. That's just shifting responsibility to users for our design failures.

If something is important enough to interrupt users for, it's important enough to design properly. If it's not important enough to design well, it's not important enough to interrupt users for.

The middle ground - interrupting people with poorly-timed, easily-dismissed guidance - is the worst of both worlds. It's intrusive and ineffective.

What Changes When You Stop Deferring

I've worked with teams that eliminated "Maybe Later" buttons from critical flows. The results are always the same: initial completion rates go up, support tickets go down, and activation improves.

But the most interesting change is cultural. Teams start taking onboarding seriously when they can't fall back on "users can skip it if they want." They start asking better questions: Is this the right time to show this? Is this information actually helpful? Can we make this feel less like interruption and more like assistance?

Removing the escape hatch forces you to design experiences that users actually want to engage with. And when you do that, you don't need escape hatches.

The Real Choice

Here's the choice I think about now when designing guidance: Do I want users to succeed immediately, or do I want them to feel like they had control over their confusion?

Those aren't the same thing. And optimizing for the feeling of control at the expense of actual success is a trade-off that hurts everyone.

Users don't want more choices. They want better outcomes. They want to feel capable and confident using your product. They want to achieve their goals without friction or frustration.

"Maybe Later" buttons optimize for the wrong thing. They optimize for politeness over effectiveness, for comfort over success.

And in the end, there's nothing polite about letting people fail when you could have helped them succeed.

This is the kind of thing we obsess over at DNSK WORK. Because the difference between good products and great ones is usually hiding in the small decisions that shape how people learn to use them.