There Is Nothing Wrong With "As a user" Approach

As a customer, I want to access the application to make an order.

How does that sound? Is it too dry? Do you need to know more about the person trying to make an order? Is it fun enough to get cracking at the code?

Recently, I came across a great articlethat says that the “as a user approach” is not the best way to go about stories and instead, recommends a more empathetic approach. The author argues that we’ve become detached from the real people who will be using the product or software.

I couldn’t disagree more. The article makes a few valid points but misinterprets them. I see where the author is coming from: it might be the right way to think about interfaces from the standpoint of the concrete middle-age single Joe, who is aiming to buy his two cute daughters a pizza. But this approach has no real applicability, when it comes to development. Few stories such as that could be used early in the project to draw a big picture of the product, but I don’t see them being of any use even after a few weeks down the line the project.

Story is not a novel

Here is an example presented by the author: As a user, I want to log in, so I can access the application. Indeed, this story does not say much about the user. Bang on the money! However, adding details such as age or hair color won’t help either. This is not to say that the story should not list the devices that the user is trying to log in with. Forgot password, single sign-on - all these should be separate stories. The story above is terrible, but not because it is boring or doesn’t look like an essay. There are few things in particular that I don’t like about it, namely:

• a user is not definitive. The actor must be referenced explicitly as a user type. For example: a customer, an anonymous user, an admin and so on. It is a good idea to outline all user types and reference them. But I will come back to this later.

• I want to log in. It isn’t that bad actually. This particular example, however, is too vague, indeed. If there is only one way of signing up, this should be alright. However, if more options are considered, then having something like login via Facebook will be way better. As an alternative, an epic Authorization mechanisms could be created. Nevertheless, you may choose to go into any level of detail with the user story depending on your circumstances.

• I can access the application. Janet Taylor makes a perfect point that the story doesn’t answer the question why the user wants to access an application. It is obvious enough that people log in to access something. On the other hand, accessing the app is an important step. You should either tell the whole purpose of the app in few words or just leave it as it is. People will understand what it means and why that user needs to get in.

There is an article I wrote recently, concerning creation of a meaningful user story

Make hypothesis, not assumptions

People are bad at assuming things. Developers are even worse! What happens when people assume different things? they fail expectations, they misunderstand each other and tend to work in different directions. What goes through your head when you say “customer”? You immediately know that all the most important fact about the person is that he/she is looking to make a purchase. Can you distinguish the 32 year old man from a 46 year old lady on your website? So, why encourage your engineers or designers to assume that? They will, most likely, each assume something different. On the other hand, if you are targeting a particular demographic or know your customers through google analytics, it makes sense to announce that. It is so much clearer to tell your team that our customers women from western Europe, age from 25 to 36. Then, just reference this audience as a customer. Validate the information about your audience, not assume.

Nobody wants to submit forms

Indeed, this small section is probably one that I find myself in total agreement with.The article cites many reasons why submitting the form might make for a terrible experience . However, it is completely irrelevant to the call for building empathy.

The purpose of the user story is to facilitate a conversation

Yes, that’s right. The goal of the story is to initiate a discussion between the team and the product owner. It is a way of switching from writing requirements to talking about them. As the author suggests, implementation details aren’t supposed to be there, which is actually right. The team will figure them out, as they go along.

Asking questions about the user performing the task doesn’t deserve that much focus as is described in the article. Imagine how long it would take to discuss every possible way that Joe can live his life and interact with the login form.

Although, writing requirements is still quite important when you try to communicate with them!

You never know what actual people think about

Staying away from technical details in the user story is good advice. However, the call to focus on actual people instead is a little bit tricky though. I think these are two entirely unrelated concepts. You actually don’t have to do anything “instead”. Just do the first part - remove implementation details. That’s it. Don’t try to play the guessing game. Guesses are bad for you. There are many more questions that could be asked about the story, and the effective manager will shrewdly deem unimportant ones as such and redirect focus on the most vital ones. This is what the Scrum approach is all about.