User Story Examples: 10 Stories With Acceptance Criteria
By SayCraft Team · 2026-08-23 · 11 min read
A user story is a short conversation starter about user value, not a complete specification. A useful copyable pattern is “As a [role], I want [outcome], so that [reason].” The format does not guarantee a useful story: the role must be real, the outcome must be bounded, and the reason must explain a decision or benefit. Add acceptance criteria, constraints, failure behavior, and evidence separately so a polished sentence does not hide ambiguity. The ten connected examples below use one client-approval product to show onboarding, permissions, search, editing, recovery, notifications, export, accessibility, and account recovery.
10 connected user story examples
| User story | Key acceptance criteria |
|---|---|
| As a new client, I want to accept an invitation and set a password so that I can review my project. | A valid, unused invitation enters its one project; expired or used links offer a safe replacement path. |
| As an account owner, I want to invite a client to one project so that access does not expose unrelated work. | The invitation grants only the selected project and an unrelated account cannot read its draft. |
| As a client, I want to search drafts by project name so that I can return to an older review. | A matching project is returned; no-match and search-failure states explain the next action. |
| As a designer, I want an upload to show progress and failure so that I know whether a draft is safe to share. | Uploading, Ready, and Failed are distinguishable; only Ready can be shared. |
| As a client, I want to request changes with a comment so that the designer understands the decision. | A non-empty comment is saved against the current draft version and can be retrieved after reload. |
| As a designer, I want to recover an interrupted upload so that I do not repeat completed work. | Retry leaves Failed state and produces one draft rather than a duplicate. |
| As an account owner, I want notification preferences per project so that urgent approvals are visible without excess email. | The owner can choose the supported project-level preference and later see which choice is active. |
| As a client, I want to export the final approval record so that I can attach it to procurement notes. | The export names the project, draft version, decision, actor, and recorded time. |
| As a keyboard user, I want every review action to be reachable with visible focus so that I can complete the workflow. | Tab order reaches every action, focus remains visible, and validation returns focus to its correction. |
| As a user who forgot a password, I want a time-limited reset path so that I can regain access without support. | Known and unknown identifiers receive the same visible response; link expiry follows the approved identity policy. |
Acceptance criteria for the invitation story
Given an active invitation for one project When the invited client opens the link before expiry Then they can create credentials and enter that project And they cannot see any other project Given an expired or already-used invitation When someone opens the link Then the system explains that access cannot continue And offers a safe way to request a new invitation
Weak versus useful stories
| Weak | Improved | Why |
|---|---|---|
| As a user, I want a dashboard. | As a designer, I want to see drafts waiting for client review so that I can follow up on blocked projects. | The role, decision, and outcome are visible. |
| As an admin, I want notifications. | As an account owner, I want one digest for approvals due today so that I can act without receiving an email for every event. | The frequency and purpose can now be discussed. |
Split a story when it contains multiple independently valuable workflows, roles, or failure policies. Keep steps together when dividing them would leave no usable outcome. Map the resulting stories back to the SRS, use the login acceptance criteria for the recovery story, then turn risky criteria into a test case.
When an idea arrives as a proposed feature, use the feature request template to capture the underlying problem first. Put accepted stories into a prioritized product backlog; if you are writing the checks without an engineering background, follow the nontechnical founder’s acceptance criteria guide.
Sources used for this guide
Turn the document into something testable
Choose one story with its acceptance criteria, not the whole backlog. A focused story gives the live build a clear outcome and review boundary.
Frequently asked questions
What is a good user story example?
A good user story identifies a real user, the outcome they need, and why it matters, then pairs that statement with acceptance criteria that make the behavior reviewable.
Does every requirement need a user story?
No. Policies, constraints, defects, research tasks, and quality requirements may be clearer in other forms. Use a user story when it helps the team discuss a slice of user value.