How to prototype an onboarding flow with an AI agent

To prototype an onboarding flow with an AI agent, start from the moment a new user first gets value, list the fewest steps that lead there, and ask the agent to draw each step and each of its states as a separate screen, linked by the actions between them. Review the whole path before you change any code, then iterate on single screens. The sections below give the steps, a prompt you can reuse and a review checklist.

Start from activation, not from the welcome screen

Most onboarding flows are designed from the first screen forward: welcome, sign up, profile, preferences, tour. Each step seems reasonable, and together they put five screens between the user and the product.

Design from the other end. Name the activation moment: the first action after which a user understands why the product exists. For a project tool it might be “created a project and invited one person”; for a note app, “wrote a note and found it again”. Then ask of every step: is this required before that moment? If not, move it later, make it optional, or drop it.

Write the result down as one sentence you will give the agent:

A new user signs up, names their first project, and lands on the project page with one sample task, in three screens or fewer after sign-up.

Map the steps and their states

Each step is a screen, and each screen has several states. Onboarding is where empty, error and waiting states matter most, because the user has no habits yet and little patience.

Step	Purpose	States to draw
Sign up	Create the account	empty, validation error, email already used, submitting
Verify email	Confirm the address	waiting for code, wrong code, code expired, code resent
Name the project	First real input	empty, filled, name too long
Invite (optional)	Bring a teammate	empty, invalid email, skipped
Project page	First value	with the sample task, empty if the sample was declined

Add the paths people forget: a user who closes the app during verification and comes back tomorrow, a user who signs in instead of signing up, a user who taps Back on every step. The user flow diagram guide shows how to write these as a table of from, trigger and to.

Write the prompt

A good prompt gives the agent the goal, the audience, the steps, the states and the constraints. It also says clearly that this is a prototype, so the agent does not start editing your app.

Prototype the onboarding flow for new users. Do not change the app code.

Goal: a new user signs up, names their first project and lands on the
project page with one sample task, in three screens or fewer after sign-up.
Audience: small team leads, on a phone (390 x 844).

Steps and states:
1. Sign up: empty, validation error, email already used.
2. Verify email: waiting for code, wrong code, code expired.
3. Name your project: empty, filled.
4. Invite a teammate (optional, with Skip): empty, invalid email.
5. Project page: with the sample task.

Use our real components, colors and fonts, and write real copy, no lorem
ipsum. One screen state per file. For each state, list the actions that
lead to other states (for example "Tap Continue", "Submit wrong code").

The phrase “one screen state per file” matters: it gives you something to review state by state, and it keeps the error states from being folded into a single “form” screen.

Review the whole flow, then each screen

Look at the path first, in order, without reading the details. Then go screen by screen. A checklist:

• Count: how many screens and how many fields stand before the activation moment?
• Skip and back: can the user skip what is optional, and go back without losing input?
• Errors: does each error say what to do, and keep what was typed?
• Waiting: what does the user see while the code is on its way, and how do they resend it?
• Leaving and returning: where does a user land if they quit halfway?
• Permissions: is any system permission requested before the user reaches the feature that needs it?
• Copy: does each screen say what happens next, in words the user would use?
• The end: is the first screen after onboarding useful, or an empty page?

Feedback works best when it points at one screen and one change: “On Verify email, waiting for code: add a Resend code link, disabled for 30 seconds, and show the address the code was sent to.”

Walk one person through it

Before you polish anything, show the screens in order to one person who has never used the product, on the device size you designed for. Ask them to say out loud what they think each screen asks of them and what they expect after tapping the main button. Do not explain. Every time you feel the urge to explain, write down the screen: that is where the copy or the order needs work. Ten minutes with one person usually finds the step that confuses everyone.

Use variants where the direction is unclear

Some onboarding questions have no obvious answer until you see them: one long form or three short steps, a sample project or an empty one, a progress bar or none. Ask for two or three variants of the step in question and compare them side by side, against one criterion decided in advance, such as the number of taps to the activation moment. Then choose one; do not ask the agent to merge them. Comparing design variants before writing code goes deeper into running that comparison.

Common mistakes a prototype catches

• A tour of feature screenshots before the user has done anything.
• Permission requests on the first screen.
• Profile questions that nothing in the product uses yet.
• No Skip on optional steps.
• An empty home screen at the end, with no hint of what to do next.
• Only the sign-up path drawn, not sign-in or password reset.
• On phones, the primary button hidden behind the keyboard.

All of these are visible in a set of static screens. None of them needs code to find.

Doing it with agentappbuilder

In agentappbuilder, a prompt like the one above becomes a set of linked frames on a canvas: your agent creates each step as a screen and each state as a frame, and links the frames with the actions between them, without touching your code. The documentation uses this very case as its example of a new flow:

Prototype an onboarding tutorial with agentappbuilder: three steps that
explain the main screen, a Skip button on each step, and the empty home
screen at the end.

You then paste the URL of any frame into your chat with what to change, and your agent adds a new version, while the older versions stay listed for comparison. When you ask for variants, they show side by side until you choose one. When the flow is right, “Apply the prototypes” asks your agent to code the chosen versions into your app and report what it implemented. Working with your agent lists the prompts for each moment, and Concepts explains versions and variants. For the guided tour that often follows sign-up, see designing an in-app tutorial, screen by screen.