Paul McAleer

A Couple of Thoughts on UX + UI Stories in Agile

Paul McAleer

My opinion is that UI and UX stories are the wrong vehicles for conveying the activities of user experience folks. Here’s why.

My interpretation of stories is that they should demonstrate value to end users or, as I like to call them, people. They might get divided into segments and different customers but, whatever. UX and UI stories I’ve encountered look something like this:

“Make the wireframe for the pages in the ‘add a new post’ workflow.”

Or, in more strict story fashion,

“As a UX designer, I will create pages for adding a post in the application in order to document the workflow.”

That’s a kind of harsh way of putting it, I’ll admit, and a BA more in tune with story writing could improve this. But that is essentially what a UX story says and, for the end user, it is totally without value nor meaning. Wireframes and sketches and the like are implementation details. They may be important to the team making the software, yes, but the end user does not and should not directly care about wireframes.

There are at least a couple of ways of rethinking this story. One way is to make it a slice of the broader story which actually is valuable.

With the above example, your epic speaks about adding content via the web interface and your stories are where the real deal is shown.

“As a content editor, I’d like to add a new post in order to get it reviewed by a peer or supervisor.”

“As a reviewer, I’d like to add a new post in order to publish it to the public website.”

Stuff like that. Then if sketches or wireframes need to be made, use tasks within the story itself - just like you would with (surprise?) development.

You probably wouldn’t have a story about a database. Stories I’ve seen tend to transcend the technology, so why do we make UX + UI ones at all?