Onboarding — Our approach

The first screen sets the question. We want the question to be “what matters most to me?” — not “what should I do with this app?”

The problem

Most onboarding flows fail in one of two opposite ways: they ask too much (a 12-step tour, a personality quiz, a goal-setting wizard before you can do anything) or they ask nothing (a blank screen with no idea where to start). The first kind drops people in the funnel. The second drops them after install.

The harder design problem is in the middle: enough setup that the first session has signal, little enough that the app gets out of the way. OterApp’s onboarding is short on purpose, and the dashboard you land on is deliberately empty. That’s not laziness; it’s a position.

What the science says

The fresh-start effect

Dai, Milkman & Riis (2014) showed that people are more likely to begin goal-directed behavior at temporal landmarks — the start of a week, a month, a year, or a “new chapter” (a new job, a new home, a new app). Installing a life-management app is itself a landmark. The act of signing up signals to the user and to their own psychology that something new is starting.

This is a precious window. The research consistently shows that intentions formed at a fresh-start point are followed through more often than intentions formed at random points. Onboarding should harness that window, not waste it.

Minimal-friction first sessions

A long line of conversion research — summarised in Hoehle & Venkatesh (2015) for mobile apps specifically — finds that each additional onboarding step lowers completion rate. The drop isn’t linear: it’s compounding. A 3-step flow with 90% per-step completion lands at 73%; a 7-step flow lands at 48%. For a life app, where the value is “use this every day for years,” losing half your users in the first five minutes is catastrophic.

The implication isn’t “no onboarding.” It’s that every step has to earn its keep.

Choice overload

Iyengar & Lepper (2000) — the famous jam-jar study — showed that more choices reduce both decision quality and decision satisfaction. Schwartz (2004) extended this: too many options at a decision point lead to decision avoidance — the person doesn’t pick anything.

A new user landing on a dashboard with 12 features lit up, all asking for attention, is staring at a jam-jar display. The path of least resistance is to close the app and try later. Instead, the dashboard starts empty and fills up as you use what matters to you — the “jars” appear only when you’ve decided you want them.

Mandatory email verification

The security-research consensus (see Florencio & Herley, 2007; OWASP guidance) is that unverified email accounts are a magnet for abuse: throwaway signups, account-takeover attempts, password-reset funneling. The cost of mandating verification is one extra step at signup; the benefit is that every downstream interaction (password reset, FCM device registration, account recovery) has a trusted destination.

This is one of the few places where OterApp deliberately adds friction.

How Oter applies it

Email, password, and a verification code. That’s it. There is no personality quiz, no goal questionnaire, no “tell us about your life” wizard. Those things sound friendly but they’re often the first source of decision fatigue — and the user hasn’t even tried the app yet.

The dashboard starts empty

When you land on the home screen for the first time, it shows the structure (your domains) without forcing content. You can start anywhere: a task, a habit, a budget. Each first-action choice is yours, and the dashboard fills up around you. You’re never “behind” because there’s nothing to be behind on.

This is the choice-overload mitigation. The dashboard isn’t a menu; it’s a mirror.

Email verification is enforced, with a clear recovery path

You can’t log in until you verify. If your code didn’t arrive, the resend endpoint is one tap away, and the error states are explicit (“the code expired,” “the code is wrong”) instead of generic. The friction is real but it’s a one-time cost.

Password reset uses a 6-digit PIN, not a magic link

PINs work in environments where magic-link emails don’t reliably land (corporate spam filters, shared inboxes, mobile mail apps that strip the link). It’s a small choice with a large practical impact on users in less-than-ideal email environments.

The login flow always tries to fetch a Firebase push token before posting the request — so your device is registered for push notifications from the first session, with no later “please enable notifications” prompt. If Firebase is unavailable, login still succeeds; push just won’t work until the next session. This is the defer-the-permission pattern: ask only when you’re sure you can deliver the value.

Practical tips

Start with one feature. Pick the one that hurts most right now (overdue bills, missed habits, lost reading time). The dashboard will fill in around that anchor.
If you don’t see the verification email, check spam — then use Resend. The endpoint generates a new code, and old codes are invalidated. There’s no waiting.
Take the empty dashboard as a feature, not a bug. It’s an invitation to decide what matters, not a checklist of what you should do.

References

Dai, H., Milkman, K. L., & Riis, J. (2014). The fresh start effect: Temporal landmarks motivate aspirational behavior. Management Science, 60(10), 2563–2582.

Florencio, D., & Herley, C. (2007). A large-scale study of web password habits. WWW ‘07 Proceedings, 657–666.

Hoehle, H., & Venkatesh, V. (2015). Mobile application usability: Conceptualization and instrument development. MIS Quarterly, 39(2), 435–472.

Iyengar, S. S., & Lepper, M. R. (2000). When choice is demotivating: Can one desire too much of a good thing? Journal of Personality and Social Psychology, 79(6), 995–1006.

Schwartz, B. (2004). The Paradox of Choice: Why More Is Less. Ecco.