Sing it with me: As a _user_ I want to _perform an action_ so I can _achieve an end result_.

This is great in theory, but writing good user stories is harder than it sounds. I’ve seen well-meaning product, design, and engineering folks take this approach to user stories and interpret them as magic words. Somehow, as long as we begin our task statement by uttering the “as a user” mantra, we’re magically taking a user-centered approach.

No. Because here’s what happens when this approach is used badly:

“As a user, I want to click the button, so I can submit the form.”

This type of thinking is what leads to buttons labeled things like “submit.” Please, please don’t do this.

“As a user, I want to log in, so I can access the application.”

This doesn’t tell me anything about how the person intends to log in, what device they’re on, whether they need single-sign on, what happens if they forget their password, if they should even need a password, and so on. And the “so what?” is missing — why do they need to access the application? Are there elements they should be able to access without logging in? Does it matter what access level they have? Is the login process different for different user types?

Besides, it’s a little boring.

Let’s break down why creating generic, technically-oriented user stories like this is a very, very bad idea.

As a user…

I can almost guarantee you that your person doesn’t self-identify as a “user.” “User” is a technical word that abstracts away the person’s humanity. If you have personas, use them. If not, you can at least be more descriptive. Here are some ideas:

As Maude the entry-level marketing manager…

As a single parent of a teenager…

As a first-time homebuyer in a big city…

Pay attention to what’s happening in your brain as you read that. See what happens? All of a sudden we’re getting a clearer picture of the real person we’re building this stuff for. We might already be getting some ideas about their challenges and goals. We also might be making some assumptions about their age, education level, and other demographics.

In other words, they’re becoming human. And we’re already taking steps to empathize with them.

I want to click the button…

No one ever wants to click a button.

… so I can submit the form.

No. Maude does not care about submitting the form. She might, however, care about the thing the form will get her.

… so I can order my book.

… so I can transfer money to my bank account.

… so I can connect with the support team.

What to do instead

The purpose of user stories is to create empathy. As a result, tiny implementation details do not need to be written in the form of user stories. The design and engineering teams can figure that out; that’s their job.

When user stories really shine, they tell a story about the person using your product. The person becomes the hero. You’re just there to create the conditions for her to achieve her real-life goals.

When you’re writing user stories, think about:

• Who will this workflow serve?
• What are the real-world implications of that person performing tasks in this app? (Remember, the physical world exists too.)
• How will their life change when that thing happens?

This isn’t hard. It just requires that we step away from the computers for a minute, remove ourselves from the implementation details and instead think critically about the actual people using the things we make.