Conversational onboarding: preview the work before asking for trust

Start with a task, not a personality

A first turn is a routing decision, not an audition for a character. Name two or three things the system can actually help with today, using verbs and recognizable outcomes. Pair each with the minimum information it needs. “Compare plan options,” “prepare a support handoff,” and “find a documented policy” are more useful than “Ask me anything.” Do not describe a capability merely because a model might generate words about it; describe the service boundary that is currently available.

A capability preview differs from a scope or refusal contract. A scope contract says what the system must not do. A preview helps someone choose a useful first action before they have learned the product vocabulary. Keep the preview short enough to scan and give the user a neutral path to type a different question. The system can then say whether that question fits the available route.

Reveal requirements progressively

Each sample task should lead to a small explanation of inputs, expected result, and any human or tool boundary. Do not place every permission, exception, and data policy in the greeting. Instead, expose the next relevant detail at the moment a person selects a task. A booking preview can say it will ask for location and preferred time; it should not suggest an appointment is held before a live availability check.

Worked example, hypothetical: a public-service guide begins with “Find eligibility information,” “Prepare questions for an adviser,” and “Understand a letter.” Selecting the first option asks for the programme, not a name or account number. Selecting the second offers a blank checklist. A user who selects neither can choose “I have a different question” or “Exit.” This sequence demonstrates the interaction without inventing a completed service.

Make exits visible and equivalent

An exit is not a tiny close icon after a persuasive sequence. Provide choices such as start over, change task, continue without saving, and use another support route where one exists. Preserve harmless draft text when a person changes their mind, but do not retain it as session memory merely to make return feel smooth. If a task requires authentication or a document, state that before the user has invested several turns.

The counterexample is a wizard that treats “not now” as failure and repeatedly returns to the same promotional prompt. That can be especially confusing in voice, kiosk, and embedded contexts where the user did not deliberately open a full application. A neutral exit also reduces the chance that a user answers an unnecessary question simply to escape the flow.

Test discovery rather than completion alone

Review first-run sessions with people who do not know internal feature names. Give each a goal and observe whether they can identify an appropriate sample task, state what will happen next, switch tasks, and leave. Include an unsupported request and a request that becomes consequential after one step. The desired result is an honest redirect, not a forced conversion into the nearest available feature.

Acceptance checks are concrete: every displayed task has a real route; no preview claims an outcome before its required checks; keyboard and touch users can reach every option and exit; and returning to the opener does not preserve an implied commitment. Track confusion notes separately from completion counts. A high click-through rate cannot show that users understood the boundary.

Exit audit. Check that escape is equally available before and after a sample is selected, including when a dependency fails. A return to the start must not convert a draft into a commitment or a profile.

Keep the promise small enough to maintain

Revise previews when tools, policies, or supported languages change. A stale example is worse than no example because it teaches a false mental model. Give content owners a simple inventory: displayed task, prerequisite, live dependency, safe alternative, and review owner. Treat it as product copy with operational consequences rather than decoration added at launch.

The limitation is that an onboarding preview cannot establish informed consent for every future action or explain an entire service. It can only make the next choice inspectable. W3C guidance on accessible names and focus supports operable choices, but it does not prescribe a conversational menu. The task framing and wording here are original design guidance.

Maintain the route map

Review the opening against new-account, failed-service, keyboard-only, small-screen, and reduced-motion states. A capability that changed or disappeared must be removed from its sample before users encounter a dead route. Use abandonment signals only to find where to look; they cannot explain why a person could not choose.

Include a concrete edge case: a returning visitor reaches the first-run screen after a previously available tool is temporarily unavailable. The preview should name the outage or hide that route, retain a neutral question path, and avoid suggesting the visitor failed to complete a task they never started.