The phrase “user story” has become so routine it’s lost most of its meaning. It was never supposed to be a requirement. Ron Jeffries described it with three Cs: the Card, the Conversation, and the Confirmation. Together they package shared understanding, not specs. I add a fourth, and I put it first, because it’s the one teams skip most:
- Context: who the user is and the situation they’re in
- Card: the “As a… I want… so that…” sentence
- Conversation: the discussion with the user, or someone who truly understands them, where the team clarifies what’s actually going on
- Confirmation: the criteria that tell you the story is done, without dictating the solution
A ticket that holds only the card was never the point. The card was meant to be a reminder of a conversation. But it’s the only part that fits in Jira, so it’s the part that survived.
And now the card has a new job. If nobody’s paying attention, it quickly becomes the prompt.
“As an operator, I want to see active alarms so that I can respond to them.”
Hand that to an agent and you’ll get a clean, sortable alarm list by lunch. Fine. And somewhere in it, the operator will hesitate.
Before AI, a thin user story cost a sprint of wrong work. The team found the mismatch in standup, in review, in the hallway. The conversation happened late, but it happened. An agent doesn’t have hallways. It builds exactly what the issue in Linear says, completely, without asking whether it reflects anything real. You find out it was wrong when users tell you. Sometimes they tell you by disappearing.
So the other three Cs have to travel with the issue now, and that takes real effort when you write it. Here’s the same story with all four:
- Context: Night shift. An alarm fires. The operator has thirty seconds to decide whether it’s real and what to do first.
- Conversation: Today they cross-check two screens and often call someone before acting. They don’t distrust the alarm system. They distrust this alarm, because it’s been wrong before and nothing tells them why it fired.
- Card: As a night-shift operator, I need to know within thirty seconds whether an alarm is real and what to do first, so I can act without calling someone to confirm.
- Confirmation: The operator acts on the view without a second screen or a phone call. When the system isn’t confident, it says so in plain language.
Look at where taste, thought, and trust ended up. Context and Conversation carry the judgment. Confirmation carries the trust condition, written down as a requirement instead of hoped for as a side effect.
None of it comes from a desk. On the alert redesign I wrote about in What Linear Did with Taste, we didn’t have that conversation until after we’d built the first version. It cost us two months of polished execution in the wrong direction. An agent would have built the wrong version faster. It wouldn’t have built the right one.
Do that part first
AI gives you extraordinary leverage once you know what to build. It gives you nothing on the question of what’s worth building, or on what would make a stranger feel safe enough to stop hesitating and act.
Those answers come from the same place they always have: proximity to real people with real problems, the discipline of having the conversation instead of writing the card and forgetting the other three Cs, and the judgment to decide and the responsibility to stand behind it.
Before you open plan mode. Before you write the context file. Before you hand the agent its first card. Go talk to the person who has the problem.
Do that part first.
Where have you seen a product that worked fine and still made you hesitate?
Sources
- Anton Sten, Designing for Trust (July 2026), the source of the taste-versus-trust distinction, the hesitation line, and the lock icon
- Taste Cannot Be Delegated, UX Collective, on preference versus judgment and design by committee
- Ron Jeffries, Essential XP: Card, Conversation, Confirmation, the original three Cs of user stories
Also in September: Taste, Thought, and Trust Don’t Come From the Model · Taste Is Judgment, Not Preference · Trust Is the One Nobody Names
Continues in October with Research Changes Shape. It Doesn’t Go Away.
Daniel Arevalo is a Product Architect and strategic product design leader. He helps product teams turn AI capability into trusted, adoptable workflows, with a background in industrial AI, IT/OT cybersecurity, and high-stakes enterprise software for critical infrastructure.