Trap #2: Bogus user stories

When we first swallowed the manual on user-centred design, we used to get quite excited over our personas.

Here’s one, Henry he has a whole side plot about his divorce, and how it’s impacted on his relationship with his grand-kids. Very relatable. I think we were working through our purple patch here. We started out with much thinner, paperback characters, they had star-signs, but you couldn’t really figure out their motivation in hitting the checkout button.

Anyway - we’ve got a lot more functional recently. Character names are much more likely to be along the lines of ‘Single Ticket Buyer’’. Whatever, they’re called, they are not likely to feature in user stories like this:

[story] “As a Patron I want to Engage with rich content about education projects so I can feel more involved.”

That - I am afraid - is a Bogus User Story. These are the stories we end up writing when we are trying to make the users fit into the motivations of our organisation. You’re basically starting with those departmental round-robin requirements, and trying to put them into user story format. You see that bit at the end of the user story. The ’So I can’ bit? That bit is the most important piece of a User Story because it’s supposed to establish the benefit to the user, and hence the reason they would want this feature. When you have a long-list of internally generated requirements this gets annoying pretty fast. Who are these people? What do they want? It just gets in the way…

So you end up with Bogus User Stories, and because of that the people at the coal face delivering the features:

1. Don’t know how to build the feature (because User Stories don’t really tell you)
2. Don’t know what the feature is for (because the story is bogus)

Congratulations you played yourself.

What do do:

• You could Keep it Real, by asking actual users for things they want to use your website to do. If you actually ask real people, they might start telling you about things they think they might want, rather than things they need, so even better, you could observe real users using a tool like HotJar or Full Story, or run an actual task-focused user test.
  
  
• I recommend taking a look at the Jobs To Be Done framework. Jobs To be Done is quite interesting. It’s not designed as an out and out replacement for User Stories, but it does have some things to say about Personas. It presumes a user has a job to do, and considers how your product will facilitate that job. If we think about the job of attending a show, and then consider all of the things that out user needs to do in order to get that job done, it will give us clues as to the main tasks our website should facilitate, from researching the shows and times, to entering their credit card details, to getting directions to the venue. The why is embedded in the job to be done, the how is your job to figure out. You might find it helpful to view your product from that perspective as a parallel to your user stories. At the end of the day, when you think about the jobs you have to do, it doesn’t make that much difference if you’re a divorced Libra or not.

Trap #10 Building a Monument
Trap #9 100% Digital Coverage
Trap #8 Divide & Conquer
Trap #7 Designing for your CEO’s smartphone
Trap #6 False Prophets
Trap #5 Post-it Fetishism
Trap #4 Building not Buying
Trap #3 Buying not Bodging
Trap #2 Bogus User Stories
Trap #1 Cutting Against the Grain