A user story is a one-sentence description of something a user needs, written from their point of view. The standard format is: "As a [type of user], I want [to do something], so that [I can achieve a goal]."
So instead of "Build export to CSV," you write: "As a team admin, I want to export feedback to CSV, so that I can share it with stakeholders who don't have product access." Same feature, but now the whole team knows who it's for and why it matters.
Why the format holds up
User stories force you to think about the person using a feature before thinking about the implementation. The "so that" clause is especially important. It tells engineers what problem they're actually solving, which gives them room to find a better solution than the one you described.
Common mistakes
Making stories too big is the most common one. "As a user, I want to manage my account" is an epic, not a story. Break it down until each story can ship in a sprint.
Forgetting the "so that" is the second. Without it, engineers are guessing at intent. Writing stories for the business instead of the user is the third: "As an admin, I want to see revenue metrics" is usually a business need wearing a user story costume.
User stories work best when they're backed by real customer feedback. If you can link a story to a specific request or quote, every item on your product roadmap becomes easier to defend.