Web usability is that corner of the web that says that people use web pages and that perhaps web pages should therefore be written and structured for people.
You can bring just about anything under the umbrella of usability. One of the mantras is that it should be part of the planning and design process, and that the more work you put into planning your usability the fewer problems you’ll have to fix when it’s all in production.
Which is all well and good.
There are several usability planning tools. One of them is variously called user stories, user scenarios, user narratives … you get the idea. (18F: User Scenarios) As a usability specialist (so to speak), I am more or less contractually obligated to have endless enthusiasm for user stories and to advocate for them in all projects.
And as you can tell – I am telegraphing this so well – my enthusiasm is more measured.
There are some particular folks at my work place (at national and local levels) who do have this user-stories-are-mandatory attitude, and I’m not sure how much of my lukewarmness stems from limitations of user stories themselves, or from these specific particular people. I do wonder about this.
But assuming it’s all legitimate, here are my thoughts:
Pro: You get a group of well meaning people together who all know the users, and tell everyone to design for the user, and everyone will come up with the same thing, right? Of course right. When you go through the exercise of writing down these things that everyone knows, it’s inevitable that everyone knows something different. So done right, user stories get everyone talking, get everyone coordinated, and give everyone a common structure for framing all their future discussions. Even if you’re just a single person team, the exercise of taking what you know and writing it down focuses your thoughts.
I mean, what’s not to like?
Con: In order to break through that wall of ‘what do I do with a blank page??’, there are all kinds of templates for how to write a good user story. Think mad libs: “As a [type of user], I need a [feature] so I can [task].” This kind of suggested format is great. It’s also horrible. For one, it’s terribly stilted. But worse, it gives everyone this formula. Just fill this out – or better yet, make your team lead fill this out – and voila, you’ve done usability. And then you have these 10 sentences, you do those 10 things, and anything wrong with the design is the fault of the person who came up with the user stories.
In other words, this tool is being used as a cudgel and a crutch. The developer doesn’t have to understand the user at all, they just have to require someone else to write user stories before they’ll undertake the task. And I think that’s horrible, because user stories are a summary; they are lecture notes; not the book. They work beautifully when you do know the full story and just need to focus on the salient points. But if all you know are the salient points … well, fill in your own example.
***
It is odd, being the usability expert in the room, and trying to throw cold water on the user stories the other person is insisting on.
I am confused, but do not need you to clarify. I think I would be confused even if i really understood what user stories are.
You sound tired.
It’s funny – I’ve gotten some feedback at work that I need more “confidence”. Which has sent me into utter paroxysms of self-doubt, as you can well imagine.
But one of the confidence killers is the concept that I’m a generalist in a world of specialists, and that therefore everything that I know is more or less given knowledge to everyone I talk with.
Like user stories. It seems to me that this is a fairly self-evident concept, and that I can therefore get straight to the point of complaining about things. The idea that I’m being at all technical or jargon-y here is somewhat amusing. In a contemplative way.
Or perhaps it’s just that I ~am~ tired, and can’t communicate clearly, even when discussing a relatively simple concept.
Next time I feel like complaining, I should complain about SQL. 🙂