All posts

March 17, 2026

Designing Complete Onboarding Flows with AI

Onboarding is the most critical sequence in any product — and the one most AI design tools get wrong. Here's how to generate a complete onboarding flow, for every user type, in one pass.

Most AI design tools, when asked to generate an app, produce something like: a homepage, a few core feature screens, and maybe a settings page. Ask them to show you the onboarding flow and they'll generate a welcome screen — one screen, the one before the real product begins. What they won't show you is what happens next: the account setup, the first-use guidance, the moment the product delivers its first value, the confirmation that something meaningful was done.

Onboarding is not one screen. It's a sequence, and the quality of that sequence determines whether users activate. Research consistently shows that users who complete onboarding are dramatically more likely to reach the aha moment — the point where they understand what the product does for them and become engaged. Missing or incomplete onboarding doesn't get noticed in a demo. It gets noticed in your week-one retention numbers.

What a complete onboarding sequence actually contains

A well-designed onboarding flow has a structure that mirrors the cognitive journey of a new user. Most products need some version of these steps:

Welcome and orientation. The user has just signed up. They need immediate confirmation that they're in the right place — a screen that tells them what this product does for them specifically, not for everyone.

Account or context setup. Many products can't deliver value until they know something about the user: what role they're in, what they're trying to accomplish, the specifics of their situation. This is where the product collects that information — not to fill a database field, but because the product needs it to personalise what comes next.

First action guidance. The onboarding shouldn't just show the user around. It should get them to do something real: create their first item, connect an account, invite a teammate, run a report. The specific action depends on the product, but the principle is universal: guided first action drives activation better than a tour of what everything does.

First value delivery. The moment the product shows the user something specific to their situation — their data in the interface, a result from their first action — is the moment they become users rather than visitors. This screen exists to make that moment visible and legible.

Completion and next step. Onboarding should have a defined end. A completion state that acknowledges what was done and points clearly to what comes next avoids the most common activation failure mode: users who complete setup but don't know what to do when they arrive at the main product.

A five-screen onboarding flow needs all five screens designed and specified. If any are missing, engineers make them up during implementation — usually as afterthoughts.

The user type problem

Most products have more than one user type. And different user types need different onboarding paths.

An analytics platform might onboard an analyst differently from an executive. A project management tool might take a project manager through a different setup than a developer. A B2B SaaS product where the buyer is also a user needs onboarding that accounts for whether the person signing up is the admin who purchased or a team member they invited.

Generic AI design tools — those that generate from a prompt rather than from a product model — produce a single onboarding path. They don't know your user types exist because you never told them. You described a screen and got a screen.

The problem compounds when you realise the user types affect more than just the onboarding. The welcome message, the setup steps, the first guided action, the empty state after completion — all of these should reflect who the user is. A designer manually building this out can hold the user types in their head. An AI generating from a single prompt has no model of the product to reason from.

How the questionnaire handles onboarding

Mowgli's questionnaire asks explicitly about user types — not as a demographic exercise but as a structural one. It asks who uses the product, what they're trying to accomplish, and what their first experience with the product needs to do. These answers aren't just metadata. They're the inputs to the spec, and the spec is what drives the generation.

When the spec defines two user types with different onboarding paths, the output contains two onboarding paths — all the way through, including the branching points, the type-specific setup steps, the role-appropriate first actions, and the distinct completion states.

The questionnaire also asks about edge states: what happens when the user arrives before any data exists, when a required integration isn't connected yet, when they reach a step that requires something they haven't set up. These are the moments that feel polished or rough in a real product, and they're the moments that generic generation routinely omits.

A complete onboarding flow — branched for two user types, with empty states and error handling — might be 10 to 15 distinct screens. Those screens can be generated in one pass from a spec that defined them upfront, rather than prompted individually or assembled inconsistently after the fact.

What this looks like in practice

A typical mobile consumer app might need:

  • Welcome screen (with value proposition matched to how the user acquired)
  • Permissions request (with context about why each permission matters)
  • Account personalisation (name, preferences, goals)
  • First guided action (create first item, run first scan, invite first person)
  • Success state and next step

A B2B SaaS product with two user types — admins and members — might need:

  • Admin: welcome → organisation setup → first team member invite → first project created → completion
  • Member: welcome (invited context) → accept invite → profile setup → first task assigned → completion

All of these screens, for all of these paths, can be in the generated output from the start. Not because they were individually described, but because the product model knew about the user types and the flows that serve them.

Sources