Ironically, one of the most fundamental tools that Product Managers use every day to communicate requirements, expectations, and user goals to their development teams also sometimes seems to be one of the most difficult things to get right.  Maybe it’s because many of us are used to the bad, old days of waterfall requirements, maybe it’s because our developers aren’t used to solving problems, or maybe it’s because our stakeholders and upper management expect certainty in what we’re going to do and how we’re going to do it.  Regardless of the reasons, it’s absolutely essential that we master this tool and push for its proper use whenever we can.  Properly-formatted, well-written user stories are the cornerstone of a user-centered design pattern — and stating a problem that needs to be solved in a way that allows developers the freedom to solve it in the way they deem most appropriate is a talent that all Product Managers can benefit from.

Everyone should be very familiar with the common structure of a user story:

As [user] I want to [task] so that I can [goal].

And, while that seems very simple from a high level view, the actual implementation of this model can be challenging to get just right.

As a [user]…

First, we have to define who the user is, which sets the overall context for the story itself.  There are a variety of approaches that one can take with this part of the story, everything from a highly-detailed, thoroughly-researched user persona that tells you what the person eats for breakfast to a very broad, generic classification of what “type” of user you’re dealing with, such as an end user, admin, or other large class.  Personally, I prefer to take a middle ground and focus on defining light personae that provide insight into the most important traits of the user for the particular product that you’re working on.  For example, I find the following to be generally applicable no matter what the product or users may be, usually plotted on a five-point scale:

• Technical Knowledge/Expertise:
  1 = Very little technical knowledge, 5 = Technology expert
• Ability/Willingness to Learn:
  1 = Resistant to Self-Learning, 5 = Natural product explorer
• Group/Individual Orientation:
  1 = Solitary, 5 = Always works in groups
• Educational Background:
  1 = High school or less, 5 = post-graduate degree
• Career Stage:
  1 = Early stage / college grad, 5 = Late stage, executive

These five attributes tend to point you in the right direction for most technical questions that may come up, but you’ll want to add some specific criteria to them that directly relates to your particular product.  For example, if designing a product for the legal market, you’ll want to add whether or not they’re licensed (ethical concerns), the size of the firm that they practice in, whether or not they do the work themselves or delegate it to others, and similar appropriate traits.

It’s really important to get the user specific enough that the developers know who they’re designing and building the solution for, but not so specific that they become caricatures that become running jokes in practice.  Balancing out the specificity with what will actually work for the development team can be a challenge — but that’s why we work with our teams to establish a set of personas that will work for your goals.

And personally, I never assign personas a specific name, like “Bob” or “Mary” — in my experience such a level of detail nearly always makes the personas actually harder to use, as people have to constantly remind themselves “who” Mary or Bob or Sam actually is.  Rather (and I’m aware that this is sacrilege to many people in the industry), I simply prefer to refer to them by their role — the “Research Librarian” or the “Workflow Designer” or the “Accounting Administrator”.

…I want to [task]…

After you’ve specified the user, the next part of the story that we focus on is the task that the user needs to do.  This task should be placed in the context of the system or product that we’re writing the user story within, and should directly relate to the goal.  Ideally, we’re trying to capture a single task with every user story, though multiple tasks may be destined to fulfill the same end goal.

A good task description for WordPress’ “distraction free” writing mode (which I happen to be using right now) might be “…I want to remove all extraneous content and widgets from the screen…”  Another good example might be something like “…I want to compare multiple versions of a single document…”

I’ve found it’s pretty rare that people don’t get the “task” part of a user story pretty solid, unless they’re trying to work stories into non-traditional processes, such as part of a design organization’s work.  In those cases, the task is going to be entirely dependent upon who you have identified as the “user” of the story — if it’s the customer, it might be something like “…I want to position my product as the perfect solution for stay-at-home moms who want their laundry to be its whitest…” if, for example, you were creating an ad campaign for a home products company.

…so I can [goal].

Ah, goals.  The Holy Grail of user stories.  Goals are the part of the user story that separates them from “requirements.”  A poorly-structured user story can still be built without goals, and it can still be built with overly-specific task descriptions — in fact, this is often the case with companies transitioning into a more formal Scrum practice or from a traditional Waterfall mentality.  But the pure and ecstatic beauty of user stories will never be realized until you get great at writing goal statements.

Goal statements are at the heart of the user story — they’re the key component that enables your development teams to actually solve problems and not just check a bunch of boxes off of a list.  Goal statements are where the agility actually happens in Scrum teams — because they enable the developers to envision a better solution than what you’ve described in the task, or even to question whether the user that you’ve identified is the “right” user for the story.

Without well-structured goal statements, you can’t have those conversations, because all you’ve got is a user and a task, both of which are directive and not collaborative.  “This user wants to do that,” is not how you start a conversation.  It’s within the “so I can achieve some end goal” where the magic happens.

For example, you might write a story that looks something like this:

“As a word processing transcriber, I want to be able to save my work regularly so that I can be reassured that if something unexpected happens I won’t have lost everything.’

Not bad — names the user type, describes a task that they want to do, and specifies the goal.

But…the task is wrong.  A good development team will look at that goal and ask, “Why does the user need to save their work proactively?  Why can’t we just save it in the background without their interaction, then if something happens, prompt them to restore it?”

And they’d rewrite the story as:

“As a word processing transcriber, I want to have my work saved for me without my interaction, so that I can restore from a prior version if something unexpected happens and ensure I haven’t lost too much work.”

And thus (perhaps), auto-save is born.

Please, make auto-save.  Don’t make another save button.  Focus on the goals.