Remember These 5 Quick Wins for Writing User Stories

Whether you’ve been writing user stories for years or are brand new to the game, these five tips will help your team work smarter and build better.

As a product manager, your job is to make sure the final product meets the needs of your customers. You can only do that if you’re capturing customer needs and communicating them as best you can!

What is a user story?

Put simply, a user story captures what the user needs your product to do and why.

The “story” part is quite short. In fact, the typical story only includes the three elements I just mentioned: the user (or customer persona), their need, and a purpose. The end!

It’s a way of writing product specs that explains the reason for a request, rather than describing a solution to that request.

For example, “As a customer service agent, I need to record notes after a call, so that my other teammates have full context about a complaint and we can keep the customer happy.” 

This user story doesn’t suggest a text box in a CRM or any other UI solution around recording notes. Instead, the story communicates the need for sharing inter-team knowledge in order to boost customer success and reduce churn. 

If you need, take a moment to learn more about user stories in general. When it comes to writing great ones, of course it’s important to make sure you’re wording everything in a way the developers can understand.

But more than that, writing great user stories is about the research, thought process, and structure you apply into them.

5 tips for writing user stories

1. Use one specific story format.

Pick a fill-in-the-blank format for your user stories. (That’s “Mad Libs” style for anyone who gets the reference!)

Something simple and easy is usually all you need. Here’s an example that works for most products:

Using a format is helpful for a couple reasons.

The first is collaboration. The whole team should be able to contribute. The simple fill-in-the-blank design ensures user stories can be written by anyone on the team.

The second is comprehension. Formats help ensure that all user stories can be read and understood by anyone on the team. The key points are captured and structured in a way that makes sense.

If the product manager or developer needs more context, they can directly follow up with whoever discovered or wrote the user story.

Of course, such formats only work if everyone is filling them out in a smart, effective way! Our next tip helps with that.

2. Focus on the goal, rather than the need or want

Whatever comes after “so that” or “in order to” is the more important part of a user story. 

I can’t stress enough how important it is to define the goal. This is the ultimate desired outcome. Focusing on the goal, rather than the need or want, has a two-fold benefit.

In the writing process, it forces the person who’s writing the spec to actually articulate what they’re trying to achieve. If they can’t pin it down themselves, how is anyone down the line going to understand?

Perhaps most importantly, focusing on the outcome creates a space for developers to think creatively about how to reach that goal. With full knowledge of the product’s technology and its purpose, dev teams can devise cool solutions that satisfy wants and needs in ways that customers and other team members (including you!) won’t think of.

On that note, you don’t want to send user stories that are prescriptive, e.g. “I want this button.”

Allowing for interpretation and creativity is key. It’s far better to pull in the expertise of other people on the team than to narrowly specify something and hope it’s the right solution.

3. Spend some time with Jobs-to-be-Done

If you’re having trouble defining the goal, try looking at your user story through the lens of another common framework: Jobs-to-be-Done.

Identify the jobs that someone hires your tool to do. What is it that they want your tool to do for them?

This approach helps you think wider about how your tool is used and what might be your user’s goal — or maybe there are multiple goals! 

It also illuminates what your competitive space actually is, both on and off the market. For example, if yours is a tool for task organization, maybe you think your “competitor” is a spreadsheet but it’s actually a post-it note. That’s a totally different way of getting the job done! So, this can transform how you conceptualize your tool and inform how you create new competitive solutions.

4. Make sure your personas are based on behavior, not demographics

Behaviors should inform the needs, wants, and goals that you’re writing about in user stories. That’s why the very first element in the story — the persona — is fundamental to a successful spec!

It’s important to create personas based on user behavior, not customer demographics. Stick to details about how this person uses your tool and interacts with your UI. This ensures that the personas’ needs are relevant to your product.

And don’t forget to update these personas from time to time! As your product evolves, so does user behavior.

5. Go back to the source

Good user stories begin with good research and discovery. That means talking to actual users, as well as collecting feedback from the rest of the company.

Make sure you’re uncovering real problems and real needs, and make sure you’re understanding and representing them correctly. The risks are that you either legitimize and prioritize needs that aren’t actually important, or you overlook spots where new solutions could have a valuable impact on your product and company objectives.

Close listening to customers also helps you develop acceptance criteria, an important part of any user story. The team uses acceptance criteria to recognize when the job is actually done and fulfilling the customer’s needs.