Picture someone who installs your app after tapping an Instagram ad. They open it on a mid-range Android phone, swipe through four welcome slides, meet a registration form with eight fields, wait for an OTP that arrives two minutes late, and then get asked for location, camera and notification access in a row. By then, the reason they installed the app is long forgotten.
Good app onboarding does the opposite. It gets new users to their first useful moment quickly, asks for information and permissions only when they are needed, and explains each request in plain language. Everything else, from profile details to tutorials, can wait until the user has a reason to care.
This guide covers the patterns that work, the details that matter for Indonesian users, and how to measure onboarding so you can fix the exact step where people leave.
Define the first moment of value
Onboarding needs a destination. Every app has an action that shows users why it is worth keeping: the first completed order, the first points earned, the first report submitted. Product teams often call this the "aha moment". Design every onboarding screen around reaching it sooner.
| App type | First moment of value | What onboarding must cover | What can wait |
|---|---|---|---|
| Food or retail ordering | First order placed and paid | Delivery address, payment at checkout | Profile photo, birthday, preferences |
| Loyalty or membership | First points or voucher in the wallet | Phone number, member QR code | Full profile, marketing preferences |
| Fintech or payments | First top-up or payment | Identity verification, PIN | Investment preferences, referrals |
| Field team app (B2B) | First visit or report submitted | Login, assigned tasks, offline sync | Settings, extra modules |
| Booking or services | First appointment confirmed | Service, time slot, contact number | Password, reviews |
The "what can wait" column is where most friction hides. If a field is not needed for the first moment of value, ask for it later, in context, or not at all.
Seven onboarding patterns and when to use them
1. Let people look before they sign up
Guest mode lets users browse your catalog, menu or schedule before creating an account. It suits retail, F&B and booking apps, where people want to check prices or availability first. Ask for an account at the moment it helps the user, such as checkout or saving a favorite.
2. Progressive profiling
Collect information in small steps across several sessions: a phone number at checkout, an address with the first delivery, a birthday when you offer a birthday voucher. Each question arrives with an obvious reason.
3. Phone number and OTP, done properly
Phone-number sign-in is familiar to Indonesian users, and many apps now send one-time passwords over WhatsApp as well as SMS. Small details decide whether this step works:
- Accept both 08xx and +62 8xx formats and normalize them in the background
- Show a resend timer, and offer a second channel if the first OTP does not arrive
- Use OTP autofill: the SMS Retriever API on Android and one-time code autofill on iOS save users from switching apps
- Rate-limit OTP requests and budget for message costs, which grow with every resend
4. Social and email sign-in
Google sign-in removes typing for many Android users. If your iOS app offers third-party or social login, Apple's App Review Guidelines generally require an equivalent privacy-focused login option as well, and Sign in with Apple is the usual way to meet that. Design the account model so one person can link several sign-in methods.
5. Ask for permissions in context
Request location when the user taps "find the nearest outlet", the camera when they scan a QR code, and notifications after the first order, when order updates matter. Since Android 13, apps need the user's permission to send notifications, as on iOS, so a declined prompt costs you a channel. A short screen explaining the benefit before the system prompt helps users decide. If they decline, keep the app working and offer the option again later in settings.
6. Personalize only when it changes the experience
A question like "What are you shopping for?" earns its place only if the answer changes what the user sees next. Limit personalization to one to three questions, and always allow skipping.
7. Teach at the point of use, not in a carousel
Welcome carousels are easy to build and easy to skip. Contextual hints, helpful empty states ("No orders yet. Browse today's menu") and a short setup checklist for B2B apps teach users at the moment they need the information. Our guide to UI/UX design principles that increase conversions covers the broader interface rules behind these patterns.
Details that matter for Indonesian users
- Device and network limits. Many users run entry-level Android phones with limited storage and prepaid data. Keep the app size and first-launch downloads small, cache content, and let every onboarding step retry gracefully on a weak connection
- Language and tone. Choose between formal "Anda" and casual "kamu" early and use it consistently in screens, notifications and customer service replies. Write the Bahasa Indonesia copy natively rather than translating it from English
- Identity verification. Regulated financial apps must verify identity, usually with an e-KTP photo and a selfie. Treat KYC as its own resumable flow, explain why each item is needed and show progress, so a user interrupted by a phone call can continue later
- Consent. Indonesia's Personal Data Protection Law (Law No. 27 of 2022, or UU PDP) expects consent to be clear and tied to specific purposes. Separate required consent from optional marketing consent, and never pre-tick the optional box. Our guide to UU PDP compliance for apps explains the wider obligations
- Account deletion. Both Apple and Google require apps that let users create an account to also offer a way to delete it. Build this into the account model from the start
- Returning users. People change phones and reinstall apps. Make it easy to log in on a new device and restore points, vouchers and order history
Measure onboarding as a funnel
Onboarding improves only when you can see where people leave. Track each step as an event with consistent names, for example:
first_opensignup_startedotp_sentandotp_verifiedpermission_prompt_shownandpermission_grantedfirst_value_action, such as the first order or first submitted report
Firebase Analytics or another product analytics tool can show the drop-off between each pair of steps. Break the numbers down by operating system version, device model, acquisition channel and app version. A sudden drop at otp_verified right after a release, for example, points to a delivery or autofill problem rather than a design problem.
When traffic is too low for reliable A/B tests, watch five to eight target users try the app in person or over a video call, and ask them to think aloud. Sessions like these reveal friction that analytics can only hint at, such as a button label people misread or a form field they do not understand.
Analytics events fall under your privacy obligations too. Collect what you need for product decisions, and respect the consent choices users made during onboarding.
Common onboarding mistakes to avoid
- Forcing account creation before users see any value
- Long welcome carousels that cannot be skipped
- Asking for every permission at first launch
- OTP screens without a resend timer or a fallback channel
- KYC flows that lose progress when the app is closed
- Tutorials that break or mislead after the interface changes
- Treating onboarding as finished at launch. It is a funnel to keep improving, a point we expand on in our guide to mobile app maintenance after launch.
How Weaveward can build this for you
We would start by defining the first moment of value for your app and mapping the current onboarding flow step by step, including OTP delivery, permission prompts and consent screens. The first deliverable is a clickable prototype of the revised flow, tested with a handful of target users, followed by the production build with funnel events in place so every step is measurable from the first release. After launch, we compare the funnel against the baseline and adjust the weakest step.
Learn more about our mobile app design and development, or talk to our team about improving your app's first-run experience.