Design process · Documentation

A user story
that designers
can actually use

A structured way to describe what a user needs — so that designers, developers, and testers all work from the same understanding.

Download full guide + template (.docx)

What is a user story

A user story is a single sentence describing one thing a specific person needs to do — and why it matters to them. It is not a feature request, not a technical brief, and not a design specification. It is the starting point for all three.

The format is simple: "As a [type of user], I want to [do something], so that [I get this value]."

Everything else in this template — context, rules, edge cases — exists to give that one sentence enough background that the team receiving it can act on it without guessing.

A user story is written by
BA Business Analyst
And used by
Design UI/UX Designer
Dev Developer
QA QA Engineer

Three principles

01
One user. One action. One outcome.
A story describes a single thing a specific person needs to do. If you find yourself writing "and also..." — that is a new story.
02
Discovery before concept.
A story is written after you understand the need — not before. Writing a concept and then asking what the user needs is like designing a door before knowing which wall it goes in. If you cannot describe the current state and the trigger, discovery is not done.
03
Done means done for everyone.
BA, designer, and developer share one definition of done. There is no "done from my side." There is only done. This template includes that shared definition — it is not optional.

What goes into a story

Each field exists for a reason. Here is what is expected — and why it matters to the people receiving it.

Business trigger
What happened that led to this task? A client complaint, a regulatory change, a metric drop? Without context, designers solve the wrong problem beautifully.
Current state
How does it work today? If nothing exists yet, say so. Designers need to know what they are replacing or extending — not just what to build.
The story
"As a [user], I want to [action], so that [outcome]." One sentence. If it does not fit in one sentence, it is not one story.
Acceptance criteria
Testable conditions — not wishes. "The user can..." not "The system should feel..." Each criterion must be verifiable by QA without interpretation.
Business rules
Validation logic, limits, regulatory constraints. This is what prevents a designer from drawing a flow that is technically or legally impossible.
Edge cases
Optional but powerful. What happens when the data is missing? When the session times out? When the user is not eligible? Empty states are UX too.
Open questions
If something is unresolved, name it here — with an owner and a deadline. Do not let open questions hide inside a document nobody reads.

Common mistakes

What a bad story looks like

These are the four mistakes that come up every time. Knowing them before you write saves everyone a round of revisions.

Instead of this
"Add a currency exchange feature to the app."
Write this
"As a private banking client, I want to exchange currency at a confirmed rate, so that I know exactly what I will receive before committing."
A feature request is not a user story. The user, their action, and the value they get must all be present.
Instead of this
"As a client, I want to exchange currency and view my transaction history and set rate alerts."
Write this
Three separate stories — one per action.
One story = one action. "And" is a signal to split.
Instead of this
Acceptance criteria: "The flow should feel intuitive and fast."
Write this
"The client sees the locked rate and a countdown timer within 2 seconds of entering an amount."
Acceptance criteria must be testable. "Feel intuitive" cannot be verified by QA.
Instead of this
Handing over the story with "business rules: TBD" or leaving the field blank.
Write this
Every required field filled. Open questions named, with an owner and a due date.
An incomplete story is returned. It is not a starting point for design — it is a blocker.

What happens next

Where this document lives in the process

The story is not a final deliverable. It is a handoff document that moves through the team in order.

BA
Write & review
BA writes the story. PM reviews and signs off. All required fields must be complete before it moves forward.
→
Design
Receive & design
Designer receives the story, asks clarifying questions if needed, then designs all states — including errors, empty states, and edge cases.
→
Dev
Implement
Developer implements against the Figma mockup. The story and its acceptance criteria stay the source of truth — not verbal instructions.
→
QA
Verify
QA checks each acceptance criterion from the story. If a criterion cannot be verified, it was not written correctly.

Sample story

A filled example from a currency exchange flow in a banking product. Use this as a reference when writing your own.

User Story · Currency Exchange Flow

BANK-1042 · 12.03.2025 · v1  ·  Author: Anna K.  ·  Reviewed: Dmytro P.

Sample
01 · Context — why are we doing this
Business trigger Client support reported a 34% increase in calls related to confusion around exchange rate confirmation. Clients are unsure whether the rate shown is final or an estimate.
Current state The current flow shows a rate at the start of the exchange and again at confirmation — but does not indicate whether the rate is locked or may change. No timer is shown. Clients frequently cancel when the rate changes unexpectedly.
Desired outcome Reduce exchange cancellation rate by 20%. The client clearly understands at every step whether the rate is locked, for how long, and what happens if it expires.
02 · The story
Core story As a private banking client, I want to exchange currency with a confirmed rate, so that I know exactly what I will receive before committing to the transaction.
User / persona Private banking client — medium-frequency. Not a professional dealer. Comfortable with online banking but not with financial jargon.
Entry point Dashboard → "Exchange currency" button. Also reachable via the account page for a specific currency wallet.
03 · Requirements
Acceptance criteria 1. Client sees the exchange rate before entering an amount.
2. A timer shows how long the rate is valid (e.g. 30 seconds).
3. If the rate expires during input, client is notified and rate refreshes — no silent changes.
4. Confirmation screen shows: from amount, to amount, rate used, timestamp of rate lock.
5. Client can cancel at any point before final confirmation.
Business rules Rate locked for 30 seconds after display. Minimum transaction: 100 USD equivalent. Maximum single transaction: 50 000 USD without additional approval. Rate deviation >0.5% from Bloomberg mid triggers a soft warning.
Edge cases
Rate expires during input Amount below minimum Amount above limit Session timeout mid-flow Currency pair unavailable
Out of scope Batch / scheduled exchanges. Crypto pairs. Corporate accounts.
04 · Definition of done — shared across all roles
BA
  • Story reviewed and signed off by PM
  • All required fields filled
  • Open questions resolved or assigned
Design
  • All states covered: default, loading, error, empty, expired
  • Flow approved by PM before handoff
  • Figma file ready with annotations
Dev
  • Implemented per Figma mockup
  • All acceptance criteria pass QA
  • Tested at all target resolutions
05 · References & open questions
Related tickets BANK-998 (rate display component) · BANK-1039 (timer component) · BANK-1041 (Bloomberg integration)
Open questions ❓ Should rate expiry trigger automatic refresh or require manual action by client? — Owner: Anna K. — Due: 14.03.2025

Write your story

Fill in the fields below and download when ready. Hover the i icon on any label for guidance. Fields marked · are required.

⚠ Some required fields are empty. Please fill them in before downloading.
1
Story info
Keep this at the top — it's how people find the story later.
2
Context
Why are we doing this? This is what designers read first.
3
The story
One user. One action. One outcome. If it needs "and also" — split it.
As a I want to so that
4
Requirements
This is what QA will test. Be specific — no "should feel" language here.
5
Definition of done
A shared agreement — the same in every story, not filled in per task.

"Definition of done" describes the conditions each role must meet before their part of the work is considered complete. This is a standing team agreement — it does not change per story. If any role cannot meet their conditions, the story is not done — regardless of what anyone says on a call.

BA
Design
Dev
6
References & open questions
Don't let open questions hide. Name them, assign them, set a deadline.
Fields marked with · are required before passing to the design team.