How to Create User Stories for Onboarding - 5 steps

Most user story guides teach the format; few show an onboarding story with its acceptance criteria attached, and almost none split stories by the kind of new user. That split matters. The person who creates an account lands in an empty product, while a teammate they invite lands in one full of someone else's work, and the two need different first sessions.

This post keeps the five steps from its original version and adds what onboarding needs on top: worked stories you can adapt, the criteria that make them testable, and a quick check before they go into a sprint.

What is a user story?

A user story is a short description of a feature from the end user's side: who they are, what they want and why. It follows the format "As a [role], I want [goal] so that [reason]". User stories came out of agile software development and are now common in product management and UX design too.

The role is the persona who'll use the feature. The goal is the specific action they want to take or the problem they want solved. The reason is the motivation behind it, whether that's convenience, speed or peace of mind. For a ride-hailing app:

"As a frequent traveller, I want to schedule a ride in advance so that I can avoid the stress of last-minute bookings."

Framed this way, the team knows who the feature is for and what success looks like for them. A backlog of user stories, ranked by how much each matters to users, keeps the work focused on their needs rather than on a feature list. Designers use the same stories to map the user journey and spot pain points.

How do user stories help user onboarding?

User stories help user onboarding in three ways. They show what a new user wants to accomplish and why, so the team designs for that outcome. They help rank onboarding work, so the steps that matter most get built first. And they keep the team on the user's goals through a process that crosses design, engineering and marketing.

Onboarding also has more than one kind of new user, and each needs its own stories:

How do you create user stories for onboarding? 5 steps

1. Identify user personas

Start by identifying your user personas: fictional characters that represent your target audience, based on real data from surveys, interviews and user testing. Each persona should include:

• Demographic information (age, location and so on)
• Job title and responsibilities
• Goals and objectives
• Pain points and challenges
• Behaviours and preferences

For onboarding, add one more field: how this persona arrives. Someone who signed up after a demo, someone invited by a colleague and someone who found you through search start with very different knowledge.

2. Understand user goals

User goals are what people want to achieve with your product, from logging in to finishing a project. Find them through user interviews, surveys or user testing: ask users what they want to get done and which tasks or features are essential to it.

Onboarding user stories built on real goals focus on the features that matter most, and they let you tailor onboarding by goal: a user who wants to "track my team's deadlines" needs a different first project from one who wants to "plan a product launch".

3. Follow the user story format and add acceptance criteria

Write each story in the standard format:

• User role: the persona performing the action.
• Goal: what the user wants to achieve.
• Reason: why they want to achieve it.

For a project management tool: "As a project manager, I want to create a new project so that I can organise and track my team's progress."

Acceptance criteria are the conditions a story must meet to count as done, often written as Given/When/Then. They turn a story into something your team can test. Before a story goes into a sprint, check it against INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable. Onboarding stories most often fail on Small ("As a new user, I want a great onboarding") and Testable ("so that I feel welcome").

4. Incorporate realistic scenarios

Realistic scenarios make sure your onboarding user stories cover situations users actually meet, and they expose pain points before users do. Walk through each stage of onboarding and list the moments a new user will hit, for example:

• A user's first login to your product
• Creating a first project or task
• Collaborating with team members on a project
• Deciding whether the product is right for them, where social proof in customer onboarding helps

When the situation matters more than the role, a job story can fit better: "When [situation], I want to [motivation], so I can [outcome]." For example: "When I open the product for the first time after my company bought it, I want to see what my manager has already set up, so I can start on my own tasks."

5. Test and iterate

The last step is to test and iterate. Build a prototype of the onboarding flow, ask a group of users to try it, and change the stories based on what you see. Our guide to user testing with onboarding in mind covers how to run those sessions. Keep testing until users reach their first result without help.

What do onboarding user stories look like with acceptance criteria?

Here are five onboarding user stories for a project management tool, one or more per kind of new user, each with acceptance criteria you could hand to a developer:

1. Account creator, first session. "As a team lead starting a trial, I want to begin from a template that matches my team's work so that I see the product working in my first session." Given a new account, when the user picks their team type, then the matching template opens with sample tasks, and the sample data can be deleted in one action.
2. Account creator, first project. "As a project manager, I want to create a project with just a name so that I can start before deciding every setting." Given an empty workspace, when the user clicks Create project and enters a name, then the project is created with all other fields optional, and the checklist task "Create your first project" is marked complete.
3. Account creator, inviting. "As a team lead, I want to invite teammates from inside my first project so that they see the work in context." Given a project exists, when the user enters email addresses, then invitations are sent and each link opens that project, not an empty dashboard.
4. Invited teammate. "As a teammate invited to a project, I want to land on the tasks assigned to me so that I don't have to search a workspace someone else built." Given an invitation link, when the teammate signs up, then workspace setup questions are skipped and they see the project filtered to their tasks.
5. Returning user. "As a user coming back after a month away, I want to see what changed so that I don't have to relearn the product." Given the last session was more than 30 days ago, when the user logs in, then a single dismissable summary of changes appears once.

Each story names a kind of new user, one goal and a test. Once they're built, the words on each screen matter as much as the flow; see our onboarding UX writing examples for microcopy that does that job.