What is a User Story?

TL;DR

• A user story describes a need from the user’s perspective.
• It should communicate the outcome, not prescribe every UI detail.
• A story is usually paired with acceptance criteria.
• User stories and user flows are not the same thing.
• A story should create conversation, not replace it.

What does a user story look like?

A common format is:

As a [type of user], I want [goal], so that [reason or value].

Suppose a user loses their debit card.

A story could be:

As a cardholder, I want to freeze my card so that I can prevent new transactions while I look for it.

Notice what it does not say: “Add a red toggle under Settings with a confirmation modal.” That would already prescribe a solution.

The story keeps the team focused on the user’s goal.

What makes a useful user story?

Who?

Whose need is this? “User” is often too generic when admins, account owners, guests, buyers, and viewers have different permissions and goals.

What?

What are they trying to accomplish?

Why?

What value does that create?

Compare these two stories:

Weak: As a user, I want notifications.

Stronger: As an account owner, I want to know when a large payment fails so I can recover it before service is interrupted.

The second gives the team enough context to reason about urgency, content, delivery, and recovery.

User story vs. user flow

A user story captures intent. A user flow captures sequence.

For the card-freeze example:

User story: I want to freeze my card so I can prevent unauthorized use.

User flow: Card → Card settings → Freeze card → Confirm → Frozen state.

The flow can then expand into alternate paths, errors, and recovery states.

User story vs. requirement

The story is usually intentionally high-level. Requirements describe the product behavior in greater detail.

Story: As an admin, I want to invite a teammate so we can collaborate.

Requirement: The admin must be able to invite a teammate by email.

Acceptance criterion: If the email already belongs to a workspace member, the system should not send another invitation.

Each layer adds precision without forcing all detail into one sentence.

How do you write a useful user story?

1. Identify the specific user or role.
2. Describe the job they are trying to complete.
3. State why that outcome matters.
4. Avoid prescribing UI unless the interface itself is a genuine constraint.
5. Add acceptance criteria for important behavior.
6. Map the flow if the story spans multiple screens, states, or decisions.
7. Review whether the story is small enough to discuss and test clearly.

Common user-story mistakes

Removing the value

“As a user, I want a button” tells the team almost nothing about the job.

Using “user” for everyone

Account owner, viewer, administrator, buyer, host, and guest may have very different needs.

Stuffing the entire specification into the story

The story should stay easy to understand. Put deeper behavior in requirements and acceptance criteria.

Treating the template as magic

Bad thinking does not become user-centered because the sentence begins with “As a user.”

Frequently asked questions

Do user stories need acceptance criteria?

Usually, yes. Acceptance criteria make expected behavior specific and testable.

Can one feature have multiple user stories?

Yes. Different users, permissions, goals, or stages of a flow can create separate stories.

Are user stories only for Agile teams?

No. The format is common in Agile practice, but describing a need from the user’s perspective is useful more broadly.

The bottom line

A user story should make one thing painfully clear: Who needs what, and why?

Everything else can build from there.

Related terms

Acceptance criteria · PRD · MVP · Product discovery · Product management

Relevant Figr resource

See how user stories fit into requirements and product workflows in Figr’s PRD guide.