in Agile, UX Practice

The UX of User Stories, Part 2

In the first part of this two-part series, we talked about what Stories are, their relationship to Personas and Story Maps, and factors to consider when writing stories.  Let’s continue by looking at the relationship between stories and UI exploration.

6. Iterate Story Development with UI Exploration

Within the everyday chaos of an average design project, part of what makes stories so valuable is their nimbleness and flexibility.  They can easily be ordered, re-ordered, and grouped in any number of ways depending on your current need, such as by category, priority, complexity, sprint, or whatever, and you can do this in a highly ad-hoc manner.  Team members can use the same card for everything from affinity diagrams to product road maps to scrum boards and on and on. But this level of flexibility also has drawbacks.

The node-like nature of Stories also means they often lack context.  In other words, while you can easily group a set of cards and say that they belong together, it is very difficult to see how they will fit together simply by looking at the cards alone. This is where UI exploration comes in.

Users participating in a design studio session

Users participating in a design studio session

While Agile offers strong conversation-centered methods for capturing stories, UX adds to that by offering visually centered methods for contextualizing those stories, i.e. helping us uncover the order in which features should be completed, which feature should be accessible in association with other features, and more.

Here’s a quick example. Jim, the auto mechanic we talked about in part 1, has described each of the following features as being important to him:

Find part by part number
Find part based on location in vehicle
View part specs
Show me if aftermarket parts are available
Keep a running tally of parts I plan to order

(Note that we are not using the long format described earlier. Especially during early exploration, just have users jot down short phrases they can speak to in more detail later.)

Discussing these features with Jim, he explains that

Sometimes I want to search by part number, but sometimes its easier to just find it based on where in the engine the part is, especially for new models, though sometimes I might need to find the part based some other spec info, or all I have is an aftermarket part number.

Based on this conversation with Jim, while it is clear we have a good starting point, it is also clear that we have no idea if this list of features is the right list or a complete list until Jim is able to see them in context, i.e. in some rendering of an actual user experience.

For example, maybe we create a part number search feature with a smart auto-complete, which when Jim sees it, he realizes that a visual search is not as critical as he thought.  Or, conversely, maybe we make the visual search so easy that searching by part number falls to the wayside.

The bottom line is this: make sure UI exploration is part of story development.  For example, do some initial cardstorming with your users, but then quickly transition to a visual exploration, such as a design studio. (Will Evans recently did a great write-up on on that.) The visual exploration will also help you improve your story coverage.

Story coverage is the degree to which you in fact have all the stories that will be needed to deliver a complete product experience.  This can be very hard to see from just looking at a list of cards, but is much more likely to jump out at you when looking at or interacting with a user interface.

7. Make sure UI infrastructure stories get into the backlog

If you are using a story-based model for software development, that means that only features for which there are stories, and which have been added to a sprint backlog, will in fact get implemented.  Ok, that’s all good and well, but what does that have to do with UX?  Well, it means that simply having a feature appear in a wireframe or prototype, even if the team agrees that the feature is important and should be part of the product, does not mean that feature will get built.  There must be a story for the feature, and the feature must be added to the backlog. If not, you’ll be negating much of what makes a story-based model effective.

Now, in most cases, this is not a problem.  The force driving the creation of a set of wireframes is usually a set of stories.  Or, in other situations, you might start visually, and then generate story cards from those artifacts.

But in the midst of this, there are certain features which can easily slip through the cracks, which I like to think of as UI infrastructure stories.

Like signage in a building, some UI features are just seen as part of the infrastructure, and something customers will just expect to be there and not think to ask for.

Like signage in a building, some UI features are just seen as part of the infrastructure, and something customers will just expect to be there and not think to ask for.

These are your water-sewer-electricity-type features, like pagination for tables or navigation bread-crumbs. A product owner isn’t going to think to ask for this stuff, but will simply expect to see it in the product, like I am not going to ask for electrical outlets in my hotel room, but will just expect it.

The problem here is that, in a story-based model (and in some ways in the Agile model in general), if you don’t ask for it, you won’t get it. But UX design, in contrast, is very much about giving the customer what they did not think to ask for.  Therefore, as part of UI exploration, it is essential to look at the UI and compare it to the backlog and make sure that there are cards for these types of features.

Find these features in your design artifact, write a story for each of them and work with your team to get them estimated and added to the backlog.  If not, you are going to have some unpleasant surprises at the end of your sprint, and be carrying UX debt, i.e. half-baked experiences that, like credit card debt, get costlier and costlier to fix with time.

8. Be present during story estimation

A key function of user stories are to serve as an estimating and planning tool.  After stories are written, hopefully by customer and users, developers use a variety of methods (such as planning poker) to assign a cost to a story, such as in the form of story points, such that the Product Owner can decide if they want to “buy” it and place it into the backlog.

Conventionally, only developers, or those who will be doing the actual software construction, participate in estimating.  That is all good and well. (After all, something that may seem as simple as justs adding a button to the screen from a UI perspective could equal a world of work that we are not aware of under the hood.)  At the same time, it is critically important that you are present during estimation.

And I don’t just mean physically sitting there watching developers estimate (though that can be an experience in itself, if you’ve never seen an Agile estimation workshop), I mean really being present.  In other words, come prepared to an estimation session with an idea of which cards you think might involve some complex UI, and watch out for a low-ball estimation.  Make sure you educate yourself on how Agile estimation works, so that you can raise a concern if you think developers are under-estimating a feature.

A common pattern, particularly on a pragmatic Agile team, is that the estimation will be based on the simplest possible way to implement the feature.  For example, if you are implementing a form, that may mean just putting all the fields on one page as one long form.  However, that may not be the best solution from a UX perspective.  You should be present to lobby for a more costly but also more user-friendly UI, in cases where it makes sense, such as to make the product competitive. This is also why its so important to have done some UI exploration before you estimate, to have a concrete basis for your discussion. Too often I see it happen afterwards, which makes for all kinds of churn and other problems.

9. Make sure testers are testing for usability

From a tester’s vantage point, a story is something for which you create a test.  If the test passes, the story is done.  Ok, I’m oversimplifying things quite a bit here, but one thing to be aware of is that testers in many cases are not looking at or primarily focused on the user interface. Instead, they are writing code-based tests that check to see if the code written to execute the given feature passes the test or not.

A snippet from a code-based unit test, which would run as part of automated testing.

If your head is spinning from reading that, then you would be well advised to educate yourself on test-driven development.  It turns traditional QA on its head and is a powerful manifestation of Agile thinking.

Perhaps more importantly from a UX perspective, because it allows for a large percentage of testing to be automated, it can free up testers to spend time reviewing the user interface and the quality of the user experience.  This can, to a large degree, be a question of working with them to point out examples of the types of issues they should be looking for in the UI, things that might jump out at you, but may not jump out at them, such as pagination links being super-tiny or in a color that is hard to see or whatever, but also to make sure that they are looking at and comparing UI screen mockups with the real thing.

It also means looking carefully at any acceptance criteria that have been created going into the sprint, because testers will use those as a basis for determining done-ness. Another very powerful tool here is a UI style guide.  This is where you can include general display rules for the user interface, so that you don’t have to keep repeating the same issue over and over.

This will allow you to spend more time working on the design for an upcoming sprint and spend less time having to check every screen of the app at the end of every sprint and nag deveplopers (or fill out time-consuming bug reports) about a slew of small tweaks that need to be made.

10. Read Mike Cohn’s book

User Stories are a huge topic and I’ve only looked at them here from the relatively thin perspective of UX.  If you haven’t done so already, you should pick up a copy of Mike Cohn’s book, User Stories Applied.  Even though it’s been out for quite a few years now, it remains as relevant as ever.

Any tips and tricks for integrating UX and User Stories you’d like to add? Please share them in the comments! 


  1. Hi, this is not a comments, is actually a question: we’ve started working with scrum in December 2011 and it’s not clear to me how the UI guys write their own stories. I mean: we know that we want user stories to be written in a customer-need format, avoiding writing too technical stories with poor value for customers. We also know (and it’s quiet normal) that UI guys use to work 1-sprint in advance, thinking on next-sprint’s interfaces, but also integrating features we’re releasing in the current sprint.

    The question is: how do we track the work the UI guys do for the next sprint? it’s not part of the current stories, so, where do I put those tasks?

    I hope I’ve been enogh clear :)

    Ciao, Massimo.

Comments are closed.


  • User Story Acceptance « Tales from a Trading Desk July 24, 2011

    […] tests.  Exploring UX Techniques and Practices (Agile 2012) offers a view, which is probably worth reading in conjunction with Gokjo’s posting – How to implement UI testing without shooting […]

  • Yuri Winds July 24, 2011

    […]Anders Ramsay talks about using the method of user stories in designing interfaces. The article deals with both the format of these requirements and the process of data collection. The second part- […] (Original in Russian)

  • The UX of User Stories, Part 1 - Anders July 24, 2011

    […] post got to be pretty long, so I decided to break it up into two parts. Read part 2, in which I talk about other key factors UX designers should consider when working with Stories, […]