Evil User Stories for Modeling Evil Users

If you're like most Product Owners, you probably have a backlog full of user stories modeling just what you'd like to see your best users do with your product.

You have stories modeling how they get the most out of every feature, how they find every benefit laid out for them, and how they squeeze your best intent out of every corner of your product.  Everything you've done has likely been with an eye towards taking care of your best users.

But what about your "not so great" users.  Not just those who are casual users of your product, or approach it with the lackluster enthusiasm.  No, I'm talking about those malevolent users who have set out to do you harm.  You have those users, too...you just may not be thinking about them.

These are the users who have only dubious intent towards your company, your product, or even your other users.  We call these users our "Evil Users", and whether you want to think of them or not...they're your users, too.  And they deserve their own user stories.

A Story of Evil

Evil user stories are just like normal user stories, except they model what a malevolent user wants to do in your product rather than what a benign user would do.  In every case, this is exactly what you want a user not to do inside of your product.

Why would you write stories that model exactly what you want a user not to do?  Because by understanding what an Evil User wants to do in your product, and more important why they want to do it, you can better understand how to defend against them.

Let's look at an example.

Imagine your product is an ecommerce platform that allows your users to buy and sell rare video game cartridges.  Buyers on your marketplace can pay with either their PayPal account or a credit card.

Now imagine that your community of rare video game aficionados has been discovered by a hacker.  This hacker intends to steal the credit card numbers of your users so he may sell those numbers on the black market.

You might write an Evil User Story to model this that looks something like this...As a hacker, I want to steal the credit card numbers of my fellow users, so I can sell those numbers on black market.

This story is our starting point.  It helps us understand what a hacker wants to do and why they would want to do it.  But it doesn't help us understand how they may accomplish it.

With a bit of "evil brainstorming" we can probably think of a few ways to accomplish this.  One way would be to gain direct access to the database that backs our website.  This would give our hacker unfettered access to all credit card numbers in the site.  However, this would be difficult our hacker to do, and since we're most likely encrypting our credit card numbers, the hacker would not be able to easily use his bounty, anyway.

Another option would be to break into another user's account where the hacker could pull that user's credit card number right from their billing information page.  This would be much easier than gaining direct access to our backend database and it would also give the hacker access to more of our user's profile information, such as the corresponding name and address associated with the credit card.

This seems like the most likely path our user would take, so let's refine our Evil User Story to reflect this...As a hacker, I want to break into another user's account, so I can steal their credit card number.

Now that we have a better understanding of why a hacker would want to break into a user's account we can consider how to better defend against it.  For example, we could strengthen the authentication requirements for a user to log into their account...perhaps by requiring an alphanumeric password with at least 8 digits and special symbols or require two-factor authentication.  Alternatively, instead of complicating the authentication process we could decide to just never display the full credit card number to a user and instead display only the last four digits.  That way, if a hacker does compromise a user's account, then they'll never be able to access the full credit card number in order to steal it.

The important takeaway here is that, much like a normal user story, the most powerful part of an Evil User Story is the "so that" clause.  Once we understand the intentions behind a user's actions we can start to work backwards to understand the steps they may take to accomplish them.  It's these steps that we'll want to mitigate against.

Evil Personified

We now have our first evil user story focusing on hackers.  But "hacker" is a relatively generic term.  There are plenty of disgruntled people in the world who may wish to do harm to both our product and our benevolent users.  For example, imagine that early in the history of our company we hired an IT Admin named Victor.  Although Victor was a talented admin he just never seemed to fit with the rest of the team and eventually things turned sour and he had to be let go.  Victor's departure was nasty and although we may have forgotten about him, he's now back for revenge.

How will Victor take his revenge?  Well, he knows that what sets our ecommerce platform across is the depth of our inventory.  We're "the place" that people come to for hard to find classic console video games.  If our inventory were to suddenly disappear from our website then we would be sunk.  Unfortunately, Victor also knows exactly how our ecommerce administration portal works...and that we rarely disable admin accounts after employees leave.  To help us imagine exactly what Victor may try to do, we can model his intent with another Evil User Story.

As a disgruntled employee, I want to delete all of the store's inventory, so the store will appear to be out of stock on all items and will be unable to generate revenue.

Now that we understand exactly what Victor is trying to do we can explore ways to prevent him from accomplishing his task, just as we did with our hacker.

However, the key takeaway here is the addition of the Disgruntled Employee persona.  Just as with normal users, considering all Evil User Stories from the perspective of the generic "hacker" persona would limit our vision of how the product could be compromised and bias our perception to only a single use case.  Instead, just as we should create personas to represent all of the major types of users of our product, we should also create Evil Personas to help us explore all of the potential groups of users who may wish to do us harm.  Only by creating actual personas for each of these groups can be better understand their motivations and, ultimately, their methods.

Where Do These Stories Fit?

Unlike normal stories, Evil User Stories are unlikely to ever end up on our product backlog in their original form.  After all, we wouldn't want to invest time in adding the ability for Victor to delete our entire inventory in a single click.

Instead, we use these stories as the first part of the process towards modeling the potential threats that could apply to our app and brainstorming how to mitigate them.  It is the output of this brainstorming that ultimately makes its way onto our product backlog as stories.  For example, as a result of our previous two discussions we may add a story to obscure all of the last 4 digits of all credit cards to a user who is viewing their billing information.  Or, we may decide to add an automated alert to review all active admin user accounts in the system every 30 days to ensure that no former employees retain their access after leaving our company.

Putting on Your Black Hat

As Product Owners, we're often quite adept at considering all of the possible use cases where our product could bring benefit to our users.  We also tend to be quite good at considering our different types of users and what their different motivations may be.  However, how some of our users may actually intend to take advantage of our product is often a blind spot.  By considering their different motivations, and ultimately their means, we can better protect both our users and ourselves and from those less scrupulous users who may wish to do us harm.