Prompting with User Stories¶
The quality of what you get back from AI depends on the quality of what you put in.
This is not unique to AI. Ask a colleague "tell me about the project" and you get a rambling answer. Ask "what outcomes are you targeting for Q3, and how will you measure success?" and you get something useful. Specificity works the same way with AI.
User Stories: Connecting Output to Outcomes¶
A user story is a practice for thinking about work from the user's perspective: who is this for, what do they need, and how will building this change their behavior? That connection between what you build and the behavior change it creates is what ties your work to outcomes.
The practice has a well-known template that also works exceptionally well as an AI prompt, because it gives AI specific, outcome-oriented direction with clear expectations for behavior and completion.
The template has two parts:
As a [who needs this],
I want [what they need]
so that [why it matters]
Given [a starting situation],
When [something happens],
Then [what should be true]
Part 1: The Story¶
The first three lines define the direction:
- "As a" defines the user. Who are you building for?
- "I want" defines the feature. What specific capability will be delivered?
- "So that" defines the outcome. What behavior change do you expect this feature to create?
The "so that" clause is the most commonly skipped part, and the most important one. Without it, you have a feature request. With it, you have a testable hypothesis about how this feature should connect to driving real impact.
Examples: The Story
These are just illustrations. Do not send them to your AI assistant.
As a weather operations officer,
I want to see where lightning has struck in the last hour on an interactive map
So that I can issue timely warnings to maintenance crews and reschedule outdoor work around dangerous weather to protect their safety.
As a contracting officer evaluating a potential vendor,
I want a profile card showing their total federal award history and top awarding agencies
So that I can quickly assess their federal contracting footprint during due diligence.
As a squadron readiness officer,
I want a dashboard that shows planned aircraft maintenance windows by tail number
So that I can identify scheduling conflicts before they delay the next mission.
Part 2: The Acceptance Criteria¶
Each Given/When/Then block describes a specific scenario:
- "Given" sets up the starting state. What data is loaded, what page the user is on, what conditions are true.
- "When" is the action. Clicking a button, filling in a form, loading a page.
- "Then" is the expected response. What should the user see, and what should be true afterward?
Together, these scenarios form a contract: if every scenario passes, the work is done. If any fails, the work is not done. Edge cases count. If an edge case does not have its own scenario, you have not defined how it should be handled, and you cannot hold anyone (or any AI) accountable for getting it right.
This is where acceptance criteria become guardrails. You are telling AI exactly what "right" looks like, and creating the checklist to verify. Step through each scenario yourself: set up the condition, take the action, check the result. Pass or fail.
Examples: Acceptance Criteria
These match the stories above. Click the same tab to see the criteria for each story.
Given the lightning strike map is loaded with data from the last hour,
when I click on a strike marker,
then I see the strike time, coordinates, and a list of any maintenance crews working within two miles of that location.
Given I am viewing a vendor profile for Lockheed Martin,
when the profile card loads,
then I see the total federal award amount formatted as currency, the top three awarding agencies by dollar volume, and a business size indicator.
Given I am a squadron readiness officer viewing planned maintenance windows on the dashboard,
when a tail number has no scheduling conflicts,
then its maintenance window is colored green.
When a tail number has a scheduling conflict,
then its maintenance window is colored red and a conflict icon is visible next to the overlapping window.
Notice the format is flexible. A single Given can set up multiple When/Then pairs from the same starting point.
How It All Fits Together¶
| Part | What It Does |
|---|---|
| As a [who] | Builds empathy; defines who you are building for |
| I want [what] | Defines the feature or deliverable |
| So that [why] | States the hypothesis: how this feature changes user behavior |
| Given/When/Then | Defines what done means; the pass/fail verification checklist |
Think of it like...
Every user story is a small hypothesis: "We believe that if we build [feature] for [user], they will [change behavior], and that will [create this outcome]." The acceptance criteria define the contract. Together, they turn feature delivery into an experiment your team can learn from.
Reverse Engineer a User Story
Partners | ~5 minutes total | Split into partners. Open a notes app: Notes on Mac, Notepad on Windows (not your AI assistant).
Imagine your team is building a ride-hailing app. A Product Manager walks over and says: "We need a feature where someone can request a ride and see the estimated arrival time and price before they commit."
Write a user story for this feature:
As a [who needs this],
I want [what they need]
so that [why it matters]
Given [a starting situation],
When [something happens],
Then [what should be true]
Given [a starting situation],
When [something happens],
Then [what should be true]
The Story. Who is this for, what do they need, and why does it matter?
The Acceptance Criteria. Write 2-3 Given/When/Then scenarios:
- What happens on the happy path when everything works as expected?
- What happens when no drivers are available in your area?
- What if your preferred ride type is unavailable, but a different class is available sooner at a higher price?
Compare your story with another pair at your table. Where they differ are the places where ambiguity would have let AI guess.
Key Insight
A user story is a structured way to tell AI exactly what to build, for whom, and how the software should behave. "As a / I want / so that" defines the direction. Given/When/Then criteria define the contract: if every scenario passes, the work is done. The more specific the story, the less room AI has to guess.