Onboarding that respects a busy user's time

User onboarding UX should start with the person's job, and spend the first screen proving the product can help with it. A tour of the interface, a required account form, and a video are lessons. Lessons can wait until the person has seen a result they care about. Busy people give you a short opening. Use it on the job.

Nielsen Norman Group's writing on how long people stay is direct: to earn several minutes of attention, the value has to be clear within about 10 seconds. An onboarding carousel that introduces "your workspace" spends that window on the product's structure. The person still does not know whether this tool can do the thing they came to do.

Start from the job they already have

Name the job in their words, then let them do a piece of it. "Add the person you need to call today" beats "Welcome to the platform." The first field should be the one that creates a real object in their account. A sample object they did not ask for is a toy. Their own object is a reason to return.

You can teach with that object. Once it exists, point at the one control that does the next part of the job. "Set a time for Alex Kim." That is onboarding. It is also the product. The lesson and the work are the same gesture, so nothing has to be remembered for later.

If the product needs a piece of setup before any job is possible, make the setup the smallest input that unblocks the job. A scheduling tool may need a timezone. Ask for the timezone and then go to the first appointment. Ask for the company logo, the brand color, and the team invites after the person has felt the product work. Those items matter. They do not matter first.

Defer the account wall as far as it can honestly go. If you can let someone draft the first object before they verify an email, do that, and save the draft through the verification. If the product truly cannot exist without an account, ask only for what the account needs, and say why. "Email, so we can return this lead to you." A form of eight fields is a bouncer. Bouncers belong at clubs, not in front of an empty product.

This applies to tools for work and to quieter products alike. A founder building a focused app often copies an enterprise setup wizard because it looks thorough. Thorough, here, means the person waits. Show the job. Collect the rest when a real record needs it.

What to postpone

Make a later list and keep it out of the first session.

• Profile details that do not change the first job.
• Inviting teammates, until there is something worth showing them.
• Integrations, until the record inside your product is the source they would want to sync.
• Feature tours of areas they have not touched.
• Permission matrices and billing plan comparisons, unless the product is the plan.
• Notifications opt-ins, until there is an event worth hearing about.

Each of these can be a small prompt at the moment it becomes relevant. Invite a teammate when a second person is mentioned. Connect a calendar when they set a second meeting. Ask for a card when they hit a limit you explained at the start. Relevance is the permission to interrupt. A checklist of six setup tasks on day one is an interruption with a progress bar.

Progress bars feel motivating in a pitch and costly in use. They tell the person they are incomplete. If the first job is already done, they are not incomplete. Let the checklist go, or shrink it to a single optional improvement that is visibly optional.

Also postpone conceptual education. "Here is how we think about pipelines" is a blog post. If the model is so novel that the first screen is impossible without it, the model may be the problem. Try a plainer object. A lead with a next step is easier to enter than a "journey stage" that requires a glossary. You can introduce your vocabulary after their word is safely stored.

Teach in the moment, then get out of the way

When a control is genuinely obscure, a single sentence beside it is enough. "This status is visible to the client." Dismissing it should be permanent for that person. If they see the same coach mark on every visit, they will stop reading all of them, including the one you add later that they needed.

Do not chain tips. One tip that ends by highlighting the next tip is a tour with smaller boxes. Let the person act. If they succeed, stay quiet. If they fail, the error should teach, because you already have their attention on the problem. An error that says what to fix is better onboarding than a slideshow they clicked through an hour ago.

Empty states carry a share of this teaching. The first time a list is blank, the sentence can name the first action. That was covered as a design problem of its own. Use the empty state as the lesson, and resist adding a modal in front of it. Two teachers at once produce a person who closes both.

Videos belong in a help link, not in the doorway. A two-minute video is a large request dressed up as friendliness. Offer it when someone opens help, or when the same person fails the same step twice. The people who want a video can have one. Everyone else can do the job.

Copy in these moments follows the same rule as the rest of the product. Name the action. Say what happens next. Leave the slogan on the marketing page. The person inside the tool is already convinced enough to try. They need the next verb.

If you measure anything in the first session, measure whether the first object was created, and how long that took. A completed tour is a weak sign. A real record is a strong one. You do not need a large analytics project to see this. Watch five new people, or read the support notes from the first week. The step where they stall is the step your onboarding failed to make obvious.

A first session you can draw on one page

Sketch the opening as a single path. You should be able to tell it in four beats.

1. The person sees the job, stated in one sentence, and one field or one action.
2. They create their own object. You show it back to them with their words in it.
3. You offer the single next action that belongs to that object, and you allow them to stop.
4. Anything else waits on a list the product can ask for later, in context.

Read the sketch to someone who has the job and has not seen the product. If they ask "when do I actually start," the opening is still a foyer. Delete a beat. Foundations are allowed to be thin. A thin opening that reaches the job is stronger than a complete curriculum.

Check the return visit as part of the same sketch. Onboarding that only works once, and then dumps the person into a different home full of modules, wastes the lesson. The second visit should open on their object, with the same words. "Welcome back, let's take a tour" resets the relationship for no reason.

Hanabi designs and builds the interface and the site around it, so the promise on the homepage and the first action in the product can use the same sentence. When those two sentences drift, onboarding becomes a repair job. Write them together.

If the first session is something you want designed rather than inherited from a template, see Hanabi's services. Bring the job the user came to do, and the fields you are tempted to ask for first. The cut is the design.

The screens that teach best are often the ones teams forget to specify. Empty states, errors, and the first success goes further on the blank screen and the failure, which do more teaching than a tour if you let them.