Last Tuesday I watched a new user bounce around a freshly minted dashboard. Up pops the friendly onboarding modal: "Welcome! Let us show you around." Two buttons: "Get started" and "Maybe later".
They hit "Maybe later" without reading the headline. Three minutes of guesswork. Five minutes later, the tab is closed.
This person wanted to succeed - they had just paid. But our first decision taught them to choose ignorance over guidance.
Designers, this one is on us.
Politeness theatre vs product outcomes
"Maybe later" looks considerate. We tell ourselves we are giving control and avoiding coercion.
I have shipped that modal too. It feels humane in a Figma frame. In the wild, it mostly operates as an opt-out from learning.
On one product we tracked, users who tapped "Maybe later" during onboarding had 73% higher churn. Not because they were less motivated - they had literally just signed up - but because we gave them permission to remain confused at the exact moment confusion is most expensive.
What reads as politeness in UI often converts into avoidable support tickets, abandoned features and lower LTV.
What the button communicates (whether you intend it or not)
When you place "Maybe later" next to essential guidance, you encode three messages into the interface:
- This isn't urgent. If it really mattered, it would not be so easy to skip. Priority is telegraphed by friction.
- Decide before you understand. You are asking users to make a meta-decision while they are cognitively cold. Faced with uncertainty, people default to the lowest-effort option: dismiss.
- Success can wait. Every skipped explainer becomes a trap they will fall into later, when there is no supportive context on screen.
That is decision architecture, not just microcopy.
The moment the penny dropped
During a collaboration test, a tooltip explained shared cursors with "Got it" and "Maybe later". The participant dismissed instantly - not from disinterest, but because she was mid-task.
Ten minutes on, she tried to collaborate, could not see her teammate's cursor, and concluded the feature was broken. We had taught her to defer learning until failure, then left her to carry the cost.
We did not need more tutorial content. We needed a different delivery mechanism.
Design for learning-in-flow
The best products do not force a choice between learning and doing. They entwine them. Patterns that consistently outperform the modal-plus-skip pattern:
1) Contextual, just-in-time cues
Trigger lightweight guidance at the moment of intent, not on page load. A micro-hint that appears when a user opens the sharing panel lands better than a blanket tour on first visit. Keep copy atomic - one job per hint.
Design notes
- Anchor hints to the control or surface being explained.
- Prefer inline affordances and empty-state helpers over centre-screen overlays.
- Set decay rules so hints do not reappear once demonstrated success is observed.
2) Outcome-framed microcopy
Users do not care about features - they care about not being stuck next week.
Instead of: "Use tags to organise tasks."
Try: "Tag now to find this in seconds next week."
Swap nouns for verbs, and verbs for outcomes. If the user cannot answer "what do I get for doing this now?", your copy is probably UI-centric rather than user-centric.
3) Progressive disclosure by default
Expose the minimum surface to get started, then reveal depth on demand. Allow users to master a narrow path, then progressively layer in capability. Progressive disclosure is not dumbing down - it is sequencing complexity in a way brains can absorb.
4) Guardrails over gates
If skipping truly risks error, add a light guardrail rather than a hard block.
Pattern: soft confirmation
"This step prevents common mistakes with invoices. Skip anyway?"
You are not coercing - you are calibrating the cost of the decision.
5) Durable return paths
If users are not ready now, they must know where help lives later. Bake a visible Learn surface into the product chrome: a help icon with contextual articles, a searchable command palette that surfaces how-to actions, or a checklist that sits in the sidebar rather than in a modal.
6) Demonstrations beat descriptions
When possible, show the behaviour. Micro-animations, ghost states and interactive "try it" sandboxes often out-teach paragraphs. If a control supports drag, hint with a tiny nudge. If collaboration has presence, pulse the avatar once.
Patterns and when to use them
First-run checklists
Replace the tour with a 3–5 item checklist aligned to activation moments. Each item deep-links to the task and auto-ticks on success. The list lives in the UI until completion, then retires quietly to Help.Inline empty states
When a surface is empty, the most valuable content is an action that fills it. "Create your first rule" with a one-line benefit and a primary button beats a paragraph about rules.Embedded coach marks
Small, anchored notes that appear after an intentional hover or focus, not on page load. Always provide an obvious way to bring them back.Command palette education
Treat the palette as a learning surface. Surface verbs like "invite teammate" or "set up billing" with one-line benefits and result previews.Checklists with consequences
If a skipped step will degrade the experience, reflect that status in-line: "Billing not set - usage capped at 5 exports" with a direct fix action.
What to instrument
If you are removing "Maybe later", measure the right things so design debates move from taste to telemetry:
- Activation events: proportion of new users who reach the first meaningful outcome.
- Time-to-value: median time to complete the core task once.
- Guided action completion rate: how often a just-in-time hint leads to a successful action within the same session.
- Help return paths: % of users who reopen guidance from the chrome and succeed on the next attempt.
- Feature false-negative rate: sessions where users try a capability, fail, and do not return within 7 days.
- Rage-click or backtrack signals: reductions here indicate guidance is doing real work.
A simple decision rubric for designers
Keep a skip only if all three are true:
- The step is genuinely optional for immediate success.
- The cost of skipping is legible to the user at the moment of choice.
- There is a durable, obvious path to return later that does not require hunting through docs.
If any of these fail, do not offer a "Maybe later". Use contextual guidance, a checklist or a soft confirmation instead.
The real choice
Do you want users to succeed now, or do you want them to feel they controlled their confusion? Those are not the same. Optimising for the feeling of control at the expense of actual success hurts everyone.
Users do not want more choices. They want better outcomes. They want to feel capable using your product without friction.
"Maybe later" optimises for politeness over effectiveness. There is nothing polite about letting people fail when you could have helped them succeed.
The products that feel effortless do not offer escape hatches from learning. They make learning feel effortless too.
This is the kind of problem we obsess over at DNSK WORK. Small interface decisions shape how people learn your product, and the difference between good and great often hides in those seams.
Top comments (0)