Why I Love User Stories

Usability CountsUsability Counts

I love user stories.

Why?

They’re a great way to communicate requirements. Combined with epics, user stories tell a product narrative so everyone understand the essence of what they are building, yet don’t restrict creativity.

User stories are an outgrowth of agile methodologies, and are used to state requirements without writing endless pages of documentation. Groups of user stories are called “epics”, and if a user story is too big, it can be broken up into smaller stories for the developers to work with.

While they may not replace high-level product requirement documents in all organizations, they can be used to break those requirements into bite-sized pieces that are easier to digest, understand, and build against.

This is an example of a user story format developed by Mike Cohn:

• As an actor, role, or persona, I want to complete a goal so that I achieve this value.

Example of user stories for a system would be:

• As a common user, I want to be able to sign in so I can use the system.
• As a shopper, I want to be able to checkout so I can purchase the items in my shopping cart.

I’ve been writing user stories for years and have worked with product managers to write them. They are part of just about every single project I work on, big or small. The stories have been instrumental for getting to core user needs; I’ve used them as a checklist for software development and not depended on the whims of a stakeholder.

All user experience and product design professionals should become experts in writing user stories. Here’s why.

Establish requirements in plain English

Sometimes when product management writes use cases or other product requirement documents, the content is in the language of the domain they are working in. An accounting system might talk about requirements in terms that are familiar to the product owners, which is accounting terminology. However, most engineers aren’t accountants. Unfamiliar jargon and technical terms create confusion, and confusion leads to features that don’t meet the initial requirements.

That’s where user stories come in.

User stories are written in plain English so both the product owners and engineers understand what is being achieved. They are the glue that binds high-level product requirements to wireframes. Every member of the three legged stool — Product Management, Design, and Engineering — can relate to the user story and agree about what it means. The stories can also be used to write test cases, because they contain an achievable goal.

Drive user research

During the requirements process, personas and user research are sometimes forgotten while writing the use cases. Or the personas are so buried in the requirements they are hard to find.

As documentation grows, we lose the users in the forest as we document the trees.

User stories do the opposite: users are incorporated right into the requirements so all parties know exactly who they are designing for. It’s usually within the first three words of a user story: As an actor, role, or persona. It might be all users in the system — for example, sign-in is used by every user that interacts with the system. Or it might a single role: a database administrator might be the only role that users a feature.

The user story is tied to a persona, actor or role using the system, which should force upfront research. That means more work at the beginning (that you should be doing anyway), but results in less work overall.

Freedom to create within constraints

There’s nothing more demoralizing than a use case document that spells out exactly what a designer or developer should build. While it establishes guardrails, it also limits creativity.

The best thing about user stories is that they are precise enough show value, but allow room to improve and iterate. Good user stories generate discussion, collaboration, and rework of the stories to make sure the value is communicated. This discussion encourages conversations about what the designers and developers should build, and allows freedom to be imaginative and innovative.

All user stories are a starting point. If you have a good team they will lead to other stories that are more expansive and provide more value to the user.

Clear demonstration of value

The worst thing about long requirements documents is that the value to users gets lost in those requirements. Pages and pages of documentation are written, and it’s not obvious why the developers are building the features specified.

User stories are the exact opposite of that — within every story is the value the user is getting out of the feature, plus that value can be illustrated in how it relates to the system. This allows user stories to be ranked based on their value. Sign In, for example, is required for most applications. However, that feature is needed even before favoriting an item, so the sign-in user story would be ranked first.

Less to maintain

The biggest waste of time I’ve ever gone through? Writing 1,200 pages of documentation for a software development project. Every time a feature changed, multiple pages had to be rewritten. Sometimes, I would be rewriting 500 words a day just in change requests.

User stories are easy to maintain, and direct the effort to where it should go: on building the final product. Most of the time I’ve written user stories in Excel, and they’ve also made it to tools like Trello, Asana and Basecamp.

Where to start

Talking about user stories is great, but here’s how to get moving on them:

• Nearly every application has a base set of stories that are needed to launch. If you start there, you’ll get practice on writing them and understand the format. Collabnet offers a good primer on different user story formats.
• Write them with your team members. If you work closely with product managers or developers, pair up to write the stories so all team members understand the effort that goes into them. Ironically, writing less is often harder than writing more, so you may spend over an hour writing a single user story.
• Test different formats. Figuring out the right communication style for your team is key. There are several different formats for user stories that are worthwhile, and which one ends up being used can be based on team preference.

Remember user stories cut through reams of over-specified documentation to get the heart of what your user’s need, and make your life as a designer easier.
Use them.

The post Why I Love User Stories appeared first on Usability Counts.