Don't Let Users Quit at Step Three: Multi-Step Wizards for Vibe Projects

This guide is not just about "splitting a long form across several pages." The real test of a multi-step wizard is what happens when a user gets stuck on step three, closes the page, and comes back the next day: can your product pick them up where they left off? Many vibe projects' wizards die in the same place: steps sliced by database table, a progress bar computed by page count, data lost on going back, and drafts held together only by browser cache. Users are not dealing with your data model. They are trying to get something done.

All examples in this article are fictional, including product names such as the "Qinghe Shop" onboarding wizard and "Yunfan Travel" driver onboarding, as well as people and numbers. They were invented to explain the method and should not be cited as real product cases.

First, decide: should this flow be split at all?

Not every long flow deserves splitting. Count three numbers first: total fields, required fields, and how many "decisions" the user has to make. If there are fewer than ten fields, no branches, and a user can finish in one sitting, do not split: splitting only adds clicks and waiting. Consider splitting seriously when any of these apply: more than twenty fields; a step that involves waiting, such as uploading an ID, waiting for a verification code, or waiting for manual review; different users taking completely different branches, such as individuals versus businesses supplying entirely different documents; or users who will likely need to go find another document halfway through.

There is a more direct test: ask someone who has never seen the product to say out loud what they are doing. If they say "first sign up, then upload documents, then set up payment, then list products," those are natural step boundaries. If they say "just fill in a form," do not force a split. Step boundaries should match the words in the user's mouth, not your backend table names. Having a users table, a shops table, and a payments table does not mean the user has three tables in their head.

Fictional example: the Qinghe Shop onboarding flow was originally sliced by backend tables into "Account info, Shop info, Qualification info, Settlement info," and step two had the highest drop-off. Interviews revealed users had no concept of "qualification info" at all; what they said was "I have to prove this shop is mine." Renaming step two to "Prove this shop is yours" and putting the business licence, storefront photo, and ID in the same step brought drop-off down. Not one field changed. The step name finally described the user's task instead of your table name, and that made the difference.

How to slice steps: by the user's mind, not by database tables

Three rules work for slicing. First, one step does one thing, and that thing can be stated in one sentence, such as "Tell us who you are," "Pick a payment method," or "Check everything before submitting." If a step title needs commas to explain itself, the step is too big. Second, separate "decisions that require thinking" from "information that is just copied." Choosing a plan, setting a price, and writing an introduction are decisions; typing a phone number and attaching an ID are copying. Mixing the two forces users to make decisions while copying, which doubles fatigue. Third, give anything that involves waiting its own step, or at least warn about it in advance. Taking a photo of an ID and waiting for recognition should not be buried among five other fields in a long page while the user waits.

Step count matters too. Three to five steps is the most common range; beyond seven, be suspicious: either the flow itself is too long and fields need cutting, or you sliced too finely and every "Next" click makes the user wonder how many steps remain. If you genuinely need more than seven, consider folding later steps into "optional" or "fill in later" so users can complete the main flow first. The main flow is simple to define: without it, the user gets nothing; optional steps are the ones users can skip and still start using the product.

Branching decides whether a wizard feels human. Do not ask users to pick from categories they do not understand and then branch on that choice. Instead, ask one question the user can definitely answer, then branch on the answer. For shop onboarding, ask "Are you opening as an individual or a business?" rather than "Please select entity type: sole proprietorship / limited company / partnership." The former is the user's own identity; the latter is business-registration jargon. Ask at most two branching questions, and immediately show the effect: the next step's title, fields, and hints should all change, so the user trusts that their choice mattered.

Step titles and subtitles must be written in plain language. The title states the task; the subtitle states how long it takes and what to prepare. For example, title "Set up payment," subtitle "About one minute; you will need a bank card in your own name." Do not write "Complete settlement information," which only a developer understands. The time in the subtitle must be honest: promise one minute and take five, and the user will stop trusting every step that follows.

Progress indicators that do not lie

Progress bars lie easily, and users notice. Computing progress by page count is the most common lie: in a five-step wizard, a user on step three sees 60%, but step three includes ID upload and review waiting, so the actual work done may be only a third. When the bar barely moves on step four, the user feels tricked.

There are three honest approaches; pick one and stick to it. The first is step-based: show only "Step X of Y," no percentage, no promise about workload. The second is weighted: estimate weights by field count and difficulty per step, so hard steps count for more progress, but say in the copy that this is an estimate. The third is milestone-based: skip the continuous bar and mark only key nodes, such as "Documents submitted," "Under review," and "Activated," which suits flows with manual review. The first is the least likely to go wrong, especially for a vibe project shipping its first wizard.

Several details decide whether a progress indicator is trustworthy. Completed steps must be clickable to review, not locked. The current step must be marked clearly, not by colour alone, because colour-blind users may not distinguish it. If branching changes the total step count, update the total the moment the branch happens; do not let a user discover halfway that "5 steps" has become "7 steps." A sentence in advance beats an explanation afterwards: "Business onboarding adds one qualification review step."

Do not play tricks with the progress bar: do not use "just one more step" to lure users into optional fields they never wanted to fill; do not count the "submission succeeded" screen as a step and make users think there is more to do. Submission success is the finish line, and the finish page should say what happens next, when to expect feedback, and what the user can do now, not just display a giant tick.

Going back must not lose data

This is the basic decency of a wizard: when the user clicks "Back," everything they entered must still be there when they return. Implementation has one hard rule: step data lives in the wizard's own state, not inside a step's page component. When the page changes, the component is destroyed, and the data must not be destroyed with it. Use one draft object carrying all steps' data; each step reads and writes only its own fields, and switching steps only changes the view, never the data.

Test three back-navigation scenarios separately. First, clicking the "Back" button: the most common case, and it must lose zero data. Second, clicking the top step bar to jump directly to an earlier step, then jumping forward again: data must survive both jumps. Third, the browser back button: this is where most single-page apps fail, because they never handle browser history and pressing back exits the wizard entirely. The fix is to give each step a history entry that supports forward and back, or intercept back navigation and map it to "previous step," while still giving the user a clear way out so they do not feel trapped.

Two subtler points on going back. First, when users change an earlier step, fields in later steps that depend on it must be handled: if the user changes "individual or business" in step one, step two's field list changes, and leftover business fields become dirty data. The rule is: when an upstream key field changes, clear downstream dependent fields and prompt the user to re-confirm; never silently keep them. Second, do not just dump the user at the top of the page on return: if they were filling in a form lower down, return them to roughly where they left off, or at least do not make them hunt for where they were.

Draft saving and resume: the user closed the page and can still come back

Draft saving is not a nice-to-have for a long wizard; it is standard equipment. Users get interrupted by phone calls, dead batteries, and lost connections. Those are normal, not exceptions. Drafts must do three things: save automatically, be resumable any time, and be visible to the user.

Get the auto-save timing right: save when a field loses focus, save on every step change, and save on a timer as well. Do not wait for the user to click "Save draft": many users never will, because they assume you are already saving for them. When saving fails, say so: a quiet banner saying "Draft failed to save, please check your connection" beats silent data loss. When saving succeeds, there is no need for a popup every time; a subtle "Auto-saved at HH:MM" is enough.

Where drafts live decides how long they survive. Local browser storage alone means switching devices loses everything; server-only storage means logged-out users cannot save at all. The pragmatic split is: logged-out users save locally first and sync to the server immediately after login, merging the two; logged-in users save directly to the server with a local copy as a fallback. Define a conflict rule for merging: the more recently updated copy wins, and list any locally unsynced fields for the user to confirm rather than silently overwriting them.

The resume entry point must be obvious. When the user returns the next day, the home page or list should show at a glance "You have an unfinished shop application — continue," taking them straight to the step they left, not back to step one. On resume, also flag expired information item by item: verification codes that expired, uploaded ID images that are no longer valid, plans that were taken down. Surface these for re-confirmation one by one instead of dumping all errors at final submission.

Drafts also need a retention period and a cleanup rule. State how long drafts are kept, for example thirty days, remind the user once before expiry, and tell them after cleanup. Drafts with no expiry pile up into dirty data nobody dares delete. When cleaning up, do not delete silently: give the user one "still want to continue?" chance.

Dividing validation between per-step checks and final submission checks

When the division is unclear, a wizard becomes "every step blocks you, and the last step blocks you once more." The sensible split is: each step validates only things in that step that the user can fix right now; final submission handles cross-step checks that need global information. For example, a wrongly formatted phone number should be caught in the phone-number step; but a rule like "the payee is not the same person as the shop owner" needs cross-step comparison and belongs at the end, because the user cannot see later information while on an earlier step, so blocking them early is pointless.

Per-step timing matters too. Do not flag errors character by character while the user is still typing; validate when they finish a field and move focus away. When they click "Next," list all errors in that step at once and move focus to the first error field, instead of only showing "Please check your input" at the top. Error copy should say how to fix it, not just "Invalid format": "Phone numbers should be 11 digits; you entered 10" is far more useful than "Phone number format error." How validation rules are written and how error copy is worded is the subject of the form-validation guide; this article only sets the division of labour and does not repeat that content.

Final submission validation must do two things. First, re-run full validation over all steps, because the user may have changed an upstream field on the way back and invalidated downstream data. Second, show a review page before submission, summarising key information by step so users can check it themselves before clicking submit. Every item on the review page must be clickable back to edit, returning straight to the review page afterwards, not to the start of the flow. While submitting, disable the button and show "Submitting" to prevent double-clicks creating duplicate records; on failure, keep all data and explain the reason and the next step instead of making the user start over.

Long wizards on mobile: collapsing, paging, and thumb-zone trade-offs

On mobile, the worst mistake is shrinking the desktop step bar into the phone screen. Five dots and connecting lines squeezed together are impossible to tap accurately. On mobile, the top should show one line of text: "Step 3 of 5: Set up payment," with the full step list expanding only when the user taps it. Text progress is more reliable than graphic progress on small screens, and it costs less space.

Long steps on mobile should use in-screen collapsing. If a step runs beyond one screen, fold secondary fields into expandable sections, expanding only required fields by default, with expand buttons that say what is inside, such as "Expand to fill invoice information (optional)." Do not use a bare "More" that says nothing. When a section expands, scroll the page to the top of that section automatically; do not make the user find it themselves.

Button placement is the most overlooked mobile pitfall. Next and Back belong in a fixed bottom bar within thumb reach, not only at the very bottom of a long page, or users must scroll to the bottom after every screen just to continue. The fixed bottom bar must respect the safe area and avoid the phone's gesture bar; the content area needs enough bottom padding so the last field is not covered by the bar. When the keyboard opens, the fixed bar must move out of the way or collapse, not cover the field being typed. This is the single highest-failure detail in mobile wizards; walk the whole flow on a real phone before signing off.

Mobile also means interruptions happen more often: calls, app switches, and screen locks can all cause the page to be reclaimed by the system. So mobile auto-save intervals should be shorter than desktop, and on recovery the user should return to the step and field they left, not merely to the start of the step.

Finding and trimming the step with the highest drop-off

Instrument first, then change things. For each step, record at least four numbers: entries, completions, next-click rate, and back-to-previous-step rate. The step with the highest drop-off is usually not the one with the most fields; it is the one where users unexpectedly need to prepare something: suddenly uploading an ID, suddenly entering a number they do not know, suddenly making a decision. When diagnosing, separate "people who exited from this step" from "people who went back from this step": exits mean the step itself is the problem; going back means an earlier step set the wrong expectation and the user returned to fix something.

Once you find the problem step, do four things in order. First, cut fields: move "nice to have" fields to optional or later, keeping as required only what genuinely blocks the flow. Second, warn in advance: in the previous step's subtitle or at the start of this step, tell users what materials this step needs so they arrive prepared instead of discovering mid-step that they must go find a document. Third, split decisions: break a hard decision into two steps, easy first, hard second; or provide defaults so users edit rather than choose from scratch. Fourth, lower the barrier: let users skip the step and move on, with the system remembering what they owe and reminding them prominently later, instead of trapping them in place.

Fictional example: in the Yunfan Travel driver onboarding flow, step three "Vehicle information" had the highest drop-off, and analytics showed many users spending over ten minutes there before leaving. Interviews found most did not know where to find the vehicle identification number. The fix changed no fields; it just added a diagram showing where the number appears on the door frame and the registration document, plus a tappable "don't know where it is" hint. Drop-off fell, not because the flow got shorter, but because users were no longer stuck on "I don't know." Trimming does not always mean cutting fields; sometimes one explanation beats cutting three fields.

After a round of changes, watch another week of data before declaring victory. Change only one variable at a time for comparison: if you cut fields, rewrote copy, and reordered steps in the same week, you will never know which change helped. One change, then data, then the next change.

A step-design checklist you can copy directly

Go through this before building. Flow: total fields, required fields, and branch count counted; every step statable in one sentence; step names in the user's task language, not table names; optional steps removed from the main flow. Progress: the progress algorithm chosen among step-based, weighted, or milestone; advance warning for branch-driven total changes; completed steps clickable back; success page stating next steps and feedback timing.

Data: step data held in one draft object so switching steps loses nothing; browser back mapped to previous step; rules for clearing and re-confirming downstream fields when upstream key fields change; auto-save timing, failure notice, and saved-time display defined; resume entry prominent, with item-by-item flags for expired information; draft retention and cleanup rules written into product copy.

Validation and submission: each step validates only its own fixable items, final submission handles cross-step checks and a full re-run; review page items clickable back to edit; submit button disabled while submitting to prevent duplicates; submission failure preserves data and explains the reason. Mobile: text progress at the top instead of a squeezed step bar; long steps' secondary fields collapsed with buttons that say what is inside; bottom buttons fixed in the thumb zone clear of the gesture bar; fixed bar not covering the input when the keyboard opens; full flow walked on a real phone.

State machine essentials: draw the wizard as a diagram before writing code

Wizards break when state is scattered as booleans across pages: one page has a "filled" flag, another has an "uploaded" flag, and nobody can say what state the wizard is actually in. Before writing code, draw the wizard as a state machine with no more than seven states. The usual set is: not started, in progress, awaiting completion, under review, completed, abandoned, expired. For each state, write where it can go, what triggers the move, and what the user sees in that state.

Three state-machine rules are worth pinning to the wall. First, no save action on any step may push the state directly to "completed"; only a successful final submission can. Second, "awaiting completion" is a formal state, not a fudge inside "in progress": when users skip optional steps, the system must record what they owe and where to complete it, not pretend the flow is finished. Third, keep a log of state changes: when a user entered review, when they were sent back for more information, and why. That log is both the basis for customer support and the raw data for locating drop-off. Once the diagram is drawn, have someone who did not build it walk the flow against it; wherever they cannot walk, the diagram is not yet right.

One honest closing note: users will not praise a good wizard; they will just quietly finish it. But they will vote with their feet against a bad one. Slice steps the way users think, report progress honestly, keep data safe, and catch users at breakpoints, and the wizard will already be better than most vibe projects manage.