← Volver al blog

Onboarding: small wins before you ask for everything

Long mandatory tutorials tank retention. Show value in the first minute, defer account creation until needed, and measure where people quit. Every extra screen needs a justification stronger than “marketing wanted it.” Good onboarding feels like help, not a sales wall.

Time-to-value

Let users poke a sandbox or sample content before sign-up if business rules allow. Ask permissions after context.

Skip buttons should be real, not fake dark patterns.

Instrumentation

Funnel events per onboarding step. Watch platform differences—Android back behavior can skip flows unexpectedly.

Session replay cautiously; privacy policies matter.

Iterate

A/B copy and step order more often than fancy animations. Localization lengthens text; test German and French layouts early.

Empty states after onboarding should teach the next action.

Questions to ask about each onboarding screen

If we removed this step, would conversion drop—or would users reach value faster? Does this screen teach something the UI cannot explain inline? Can we show this content later, after the user has a reason to care?

Ship smaller experiments: copy changes beat full redesigns for learning why people bounce.

Designing the first session around outcomes, not screens

The first session is a contract between your product and the user: you promise a payoff, they promise attention. Screens are just scaffolding. Start from the job-to-be-done: what should be true when the user closes the app sixty seconds from now? If the answer is ‘they created something,’ orient onboarding around creation, not account walls. If the answer is ‘they understood the value,’ use guided content with real data instead of empty states. Every screen before that outcome needs a ruthless justification—if removing it does not change completion of the outcome, remove it. Product and growth teams often ask for extra steps to collect demographics or push permissions early; push back with funnel data. A shorter path with higher completion beats a longer path with more data points nobody queries. Instrument each step with time-on-screen and drop-off, not only completion. Long dwell times on a step often mean confusion, not engagement—pair metrics with qualitative sessions when you can. For regulated industries, collect the minimum viable legal consent without bundling marketing consents into the same screen unless required—users parse intent quickly and resent mixed motives. When you cannot skip account creation, explain why in one sentence tied to user benefit: sync, backup, compliance—not ‘we need your email for updates’ unless updates are genuinely the hook.

Progressive disclosure without hiding essentials

Progressive disclosure is not the same as hiding settings. Teach advanced features after users grasp basics, but never hide safety, privacy, or billing realities. A common pattern: start with a minimal dashboard, reveal toolbars after the first successful action, and surface power features contextually—when the user attempts something that needs them. Avoid ‘mystery meat’ navigation where icons lack labels until tapped; first-time users need text. For multi-role products, ask role early only if experience diverges immediately; otherwise default to the most common path and allow switching later. Localization changes copy length—test German and Spanish on small devices to ensure CTAs remain visible. If onboarding includes video, provide captions and a skip—autoplay video with sound is a conversion killer on public transport. Offline-first apps should degrade gracefully: cache onboarding content locally so flaky networks do not strand users on spinner screens. And remember Android back behavior: users may leave onboarding unexpectedly—persist progress and offer resume on next launch.

Measurement that changes decisions, not just dashboards

Funnel charts are vanity if nobody acts on them. Tie each onboarding step to an owner and a decision rule: if drop-off exceeds X%, run a research sprint. Segment by acquisition channel—users from ads may need different priming than organic. Compare iOS and Android; platform differences in keyboards, permissions, and back stacks skew completion. Watch cohorts over weeks, not only day-zero—some products show delayed activation. Avoid optimizing only for account creation if your north star is weekly active usage; add events for first core action completed within seven days. Session replay helps, but sample and anonymize—never replay password fields. Pair quant with qual: five user tests often explain the ‘why’ behind a cliff in the funnel. When experiments ship, document hypotheses and outcomes so future teams do not rerun the same losing ideas. Finally, align analytics schema with data warehouse naming—onboarding event names should match between mobile and web if journeys cross surfaces.

Permissions, trust, and the pace of asks

Each permission is a withdrawal from a trust account you have not fully funded yet. Notifications, tracking, Bluetooth, health data—each needs a contextual pre-screen explaining user-visible benefit. If denial is likely, design a graceful path: limited mode, reminders later, or deep links to Settings with neutral copy. Never loop users through dead-end states if they deny—offer manual workflows where feasible. For email and phone collection, separate verification steps from exploration steps so users perceive momentum. Fraud-sensitive apps may need stricter gating—communicate why delays exist to reduce abandonment attributed to ‘slowness’ rather than policy. Enterprise SSO flows add hops; show progress indicators and explicit error messages when IdPs fail. Throughout, keep support macros updated so agents explain onboarding quirks consistently—nothing erodes trust like contradictory answers.

Iteration mechanics that teams actually follow

Ship onboarding improvements in small vertical slices: copy test, ordering test, new illustration—one variable at a time when possible. Feature-flag risky experiments and be ready to revert quickly. Keep a changelog of onboarding versions referenced in analytics so analysts can filter cohorts accurately. Review onboarding quarterly even if metrics look fine—product positioning drifts, and screenshots age. Involve customer support in reviews—they hear verbatim confusion. When redesigning, maintain parallel funnels briefly to compare old versus new rather than cold-turkey swaps on all users. Document known issues (‘we cannot skip step 3 on Android because…’) so new PMs do not reopen settled debates. Celebrate wins with the team—onboarding improvements often lift revenue more than shiny new features users never reach because they bounced early.

Shipping and reliability habits (1)

Environment variables should be classified: public-by-design, sensitive-with-mitigations, or never-on-device. `EXPO_PUBLIC_` values are extractable—treat them that way. Align env handling across EAS profiles and local dev; fail fast when keys are missing instead of shipping undefined behavior.

Project structure should make ownership obvious: routes as backbone, feature folders for product areas, thin screens, and shared infrastructure that is deliberately named. Refactor in vertical slices with device-tested releases—big-bang rewrites without tests are how teams lose weeks.

Platform differences worth rehearsing (2)

Accessibility is compatibility. Labels, focus order, and dynamic type are not polish—they determine whether users can complete tasks at all. Test with VoiceOver and TalkBack on hardware; simulators miss focus bugs. When designs prioritize minimalism, negotiate text alternatives for icon-only controls. Accessibility regressions often follow navigation redesigns—add checklist items to those PRs specifically.

Internationalization is a product feature, not a string swap. Plural rules, RTL layout, and locale-aware formatting change behavior—not just copy length. Pseudolocale helps find clipping early, but real Arabic and German QA catches nuance. Avoid concatenating translated fragments; context matters. Document glossary terms so translators do not invent inconsistent product names.

Security, privacy, and data handling (3)

Images and maps look simple in mocks and expensive in production. Decode sizes should match display sizes; static map thumbnails are not interchangeable with interactive MapView gestures. Quotas, API keys, and offline behavior need explicit fallbacks—addresses as text, retry buttons, and calm error copy. Monitor vendor dashboards for spikes that indicate bugs or abuse.

Error boundaries catch render failures, not native crashes or async mistakes. Pair them with platform crash reporting and structured client logs. Fallback UI should include build identifiers and humane copy—never raw stack traces for end users. Test fallbacks with screen readers; a broken error screen is still broken UX.

Performance and measurement discipline (4)

Keyboard and form UX separate polished apps from ‘works on desktop simulators.’ Platform differences in soft input modes matter; test smallest phones and Android gesture navigation. Primary actions must remain reachable when the keyboard is visible—scroll containers and keyboard controllers exist because this problem is universal.

Type-safe navigation pays off when routes multiply. Keep param lists near navigators, validate external URLs, and avoid serializing non-JSON-safe values through params. Renaming routes is a cross-cutting change—update analytics, push payloads, and E2E selectors in the same release train.

Team process and long-term maintenance (5)

Privacy nutrition labels and Play Data Safety forms should reflect actual SDK behavior—inventory dependencies each release and remove dead code. Drift between claims and telemetry is legal and store risk, not just embarrassment. Involve legal early when adding analytics or ads.

Expo SDK upgrades are integration projects: `expo doctor`, aligned community packages, regenerated native projects, and device smoke tests for camera, push, and IAP. Freeze unrelated native refactors during the upgrade window and keep rollback paths hot. Document surprises for the next upgrade while memory is fresh.

Shipping and reliability habits (6)

Background execution policies change with OS updates—revalidate after major iOS and Android releases. Misused background modes invite rejection. Persist user work frequently; the OS can kill you anytime after backgrounding. Uploads and timers should tolerate pause and resume without corrupting state.

Design tokens and semantic colors make dark mode and rebrands feasible. Mixing three styling systems doubles migration cost—pick a primary approach and draw boundaries. Runtime CSS-in-JS can cost frame time on hot screens—profile before adopting wholesale.

Platform differences worth rehearsing (7)

Helper modules concentrate glue code—storage, navigation, permissions—so screens stay readable. Split helpers by topic before files become merge-conflict magnets, and document each module’s contract. Good helpers answer ‘where do we save tokens?’ in one glance—not ‘ask Sarah.’

Shipping React Native features is less about any single API and more about the system around it: typed boundaries, predictable navigation, and telemetry that tells you what broke in production. Prefer boring, explicit modules over clever metaprogramming that the next hire cannot grep. When platform vendors change behavior in point releases, your defense is automated smoke tests on real devices and a short internal changelog of native assumptions you rely on.

Security, privacy, and data handling (8)

Monorepos amplify both leverage and failure modes: duplicate React versions cause mysterious hook errors, and Metro misconfiguration blocks local packages from resolving. Invest in workspace discipline—single React version, documented `watchFolders`, and lint rules preventing packages from importing app navigators accidentally. CI must mirror local installs; ‘works on my laptop’ with different package managers is a time bomb.

Native modules are product decisions disguised as engineering tasks. You inherit Xcode and Gradle upgrades, store review scrutiny, and security obligations. Prefer maintained Expo modules and config plugins before writing JNI or Swift glue from scratch. When you must go native, budget pairing time with platform specialists and write runbooks for on-call—crashes in native code bypass many JS safeguards.

Performance and measurement discipline (9)

Storage is not a database. AsyncStorage and MMKV excel at key-value preferences; SQLite or remote APIs belong elsewhere for relational data. Migrations should be incremental, logged, and non-blocking for UI. Secure tokens need secure storage when your model demands it—speed is not a substitute for correctness on auth material.

WebViews are untrusted browsers inside your app. Validate `postMessage` payloads, lock navigation to expected hosts, and prefer system-browser auth flows when OAuth security demands it. Third-party JavaScript can change without your deploy—treat XSS in web as bridge compromise risk. Clear storage on logout and rate-limit message handlers.

Team process and long-term maintenance (10)

FlatList performance is configuration as much as code. Stable keys, reasonable `windowSize`, and memoized rows beat switching to a different list primitive blindly. Nested virtualized lists are a last resort—redesign first. Profile with production-like data volumes; dev placeholders lie.

Splash screens and launch gates should reflect honest readiness: fonts, theme, session, critical remote config—not every SDK under the sun. Infinite splash is worse than a slightly longer branded hold. Match native and JS background colors to avoid flashes; respect reduced motion for animations.

Shipping and reliability habits (11)

WebViews are untrusted browsers inside your app. Validate `postMessage` payloads, lock navigation to expected hosts, and prefer system-browser auth flows when OAuth security demands it. Third-party JavaScript can change without your deploy—treat XSS in web as bridge compromise risk. Clear storage on logout and rate-limit message handlers.

E2E tests should protect revenue paths, not every permutation. Stable selectors (`testID`) beat text that marketing rewrites weekly. Flake management is a feature: quarantine, fix root causes, and keep smoke suites green on CI devices. Five reliable tests beat fifty flaky ones that everyone ignores.

Estructura del proyecto → · Utilidades de app →