Monthly Archives: July 2011

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! 

The UX of User Stories, Part 1

If you are a UX designer who wants to quickly get up to speed with integrating Agile and UX, there are few better places to start than with User Stories.  They are both a quintessential embodiment of Agile thinking (i.e. if you understand User Stories, you understand Agile thinking) and a potential power tool for a UX designer on an Agile team.  But like any tool, they can be highly effective, or, if you have no idea how stories work, cause some serious damage, especially to the UX dimension of your product.  So, if you’re using User Stories or thinking about adopting them as a tool, here are ten tips to help UX designers understand User Stories (we’ll just call them Stories from hereon) and wield them to both yours and the team’s benefit.

1. Know What the Story Is

Ok, first things first.  Before we can offer any advice about stories we need to understand what we’re talking about. Take a look at this and tell me what it is:

As a substitute teacher, I want to view a list of all students in my course, so that I can call on them by name.

If your practice has been raised on a steady diet of document-centered design processes, i.e. work that revolves around and culminates in the creation of documents, like specifications or use cases or whatever, you can be forgiven for looking at the above card and thinking that you are looking at a story.

The card is not the (whole) story
Yes, the above definitely is a story card, but the actual story is not on the card.  This might be confusing, but bear with me here.  The statement on the card is only what one can think of as the title portion of the story. The full story is the conversation triggered by the statement on the card.  In other words, the complete story, i.e. all the excruciating details about the given feature, live in a self-maintaining, self-updating data store, namely the team’s collective memory.  Therefore, in whatever moment when someone picks up a card and has a conversation with other team members, the statement on the card triggers the most current knowledge about the feature by those team members.

The idea of storing project information in collective team memory might sound funky, but not only does it make a lot of sense—information in a modern software project is too fast-moving and volatile for document storage to be able to keep up—but collective team memory is, by its nature, always up-to-date.  All that is needed are the correct words that will trigger the appropriate memory, and resulting conversation.  And that is what goes on a story card.

If you’re still skeptical about this concept, you should know that you probably use this technique yourself on a regular basis, such as when writing a todo list. When writing a todo list you don’t write down every last detail about the thing you need to do, but only just enough so that you won’t forget to do it and, when the times comes to complete the todo item, you’ll remember all the details about what needed to be done.  Stories work the same way, except that in this case its a team-wide todo item, as well as a team-wide communication device.

Stories are a whole-team communication interface

Stories are a communication interface between team members

Each team members looks upon and uses the same story from the vantage point of their particular work

When you hand the same card to a different team member, each team member will look at it from a different perspective, and use it in a different way.  In more pontificating terms, this is what is known as a boundary object.  For a user, it describes a needed or desired feature.  For a developer, it describes a feature that needs to be estimated and/or work that will need to be completed. For a UX designer, it describes a puzzle piece to be fit into a product offering (or not) to create a coherent and valuable experience.  For a tester, it describes something for which a test likely needs to be written.  And so on, for each team member.  One story; multiple perspectives.

If you understand these various perspectives and the way in which a story gets kicked around between team members, then you’ll have a good mental model of how the Agile project game is played, and where you can best position yourself on the field to move the story to the finish line.

2. Make Personas the voice of the story

In contrast to old-school requirements, which are written from the perspective of computers, i.e. “The System shall…” do this or that, Stories are written from the human perspective, e.g. I want to be able to do this or that.  This shift in perspective is a great example of how Agile is much more human-centered compared to waterfall.  But when bringing UX practice to Agile, we have an opportunity to take this even further, as part of integrating Personas, by making the Persona the voice of the story.

In other words, if we do a Persona workshop in the early stages of the project, each story that is created should correspond to one or more Personas.  Let’s say our substitute teacher persona is Becky. After putting in all that work into modeling Becky, we can now leverage that in how we create and talk about our stories.  For example, we can add a Persona prefix to our story statements:

Becky says:
As a substitute teacher, I want to view a list of all students in my course, so that I can call on them by name.

With this short prefix, we’ve both made the user feel more real, and in conversations about this story, we can talk about what Becky would want or not want, rather than what some anonymous and disembodied substitute teacher would want.

3. Have users write the stories, not you

For an advanced Agile team, this is Agile 101, but if you’re new to Agile, you may be sitting there frantically trying to write story cards while users are telling you what they want.  However, a key aspect of an Agile approach to engaging users or team members is active collaboration and creation of artifacts by the team rather than by individuals.  In the case of stories, this means that you create contexts in which users write their own cards.  There are numerous ways of doing that.  One is the Paired Interviews technique I wrote about recently. That, in turn, is a type of cardstorming activity, which more commonly is done individually, with each team member creating as many cards as they can within a short (e.g. 5-minute) timebox, followed by self-organized group chunking and prioritizing.  Additionally, the overall project infrastructure should be such that cards are available at arms-length virtually wherever you are working (e.g. place cards and markers at the center of every table, and scattered strategically throughout your team room), such that you can capture cards at the speed of conversation.

So why is it so important that the users write the stories?  One main reason is that they will then phrase the card in their own domain-specific language, and in a way that is likely to most effectively trigger the appropriate memories when you ask them about the card down the road.  And on that note, if the cards are written by hand, their handwriting can be used for card traceability, i.e. you’ll be able to know who wrote the card just by looking at it.  And if you are gathering info from many users, well, then they will be able to produce far more cards as a group than you could on your own.

4. Be sure to get your “so thats”

As you may have noticed, the above cards are written in what has become a standard structure for writing stories:

As a [user role]…I want to [be able to do something]…so that [it will provide value in this way].

Now, while there is nothing that says you need to phrase your stories in this way (and when you are capturing new stories, you probably want to just jot down a couple keywords, and write the story in long form later), it is important to be aware of the relationship between the “so that…” part and UX.  Looking at our earlier example with our substitute teacher Becky, the “so that” reveals the Why of the story.  It reveals both the motivation behind the story and often also can reveal something about the context. However, when trying to get a lot of stories created in a short amount of time, this part is often skipped.  And that’s understandable.  However, it is important to then be sure to go back at a later point and get your “so thats.”

To understand why, let’s look at an example where the “so that” is missing.

As an auto mechanic, I wants to be able to search auto parts visually.

Hmm, why would searching visually be so important?  In a later conversation with an auto mechanic, he explains:  “I want to be able to search visually, so that I can find and visually match the part in the search results to the physical part as well as see in the search where in the engine or vehicle the part should be located, to make sure I am ordering the right part.”  Wow, the “so that” part suddenly revealed a desire for a completely custom visual search interface and a desire to be able to search while working on the car, meaning maybe searching with greasy hands and lying on your back. Seriously valuable intel.  Make sure you get those “so that’s” people!

5. Don’t confuse Story Maps with User Interface

Team reviewing a story wall for story completeness

While a story wall provides a good overview of the product, it is much harder to evaluate for completeness compared to a user interface.

Story mapping is a powerful way for managing stories and offering a big-picture view of the product.  But it is also a far more abstract view of the product compared to the corresponding user interface.  It is virtually impossible for a Product Owner or other domain expert to look at a story map and say, yup, looks like we’ve got all the stories there.  You have to actually flow through it in a user interface to see what is missing. In other words, after you’ve developed your story map and think you’ve got good story coverage, assume you’ll be uncovering a good chunk of new stories as part of designing the user interface.

Additionally, even though you may have organized your story cards into thoughtful silos that reflect the structure of your product or domain, that can easily be confused with an actual user flow, in which the reality is that users may be jumping around back and forth between your different silos, even if your silos have been organized in an order that generally matches your domain’s workflow.

Therefore, create story maps and use them for all the reasons that they are powerful, but quickly start to generate user interface concepts based on the cards in the story map to uncover aspects of the product that stories, by themselves, often are not very good at revealing.

To be continued…

This 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, such as story context, story coverage, and story estimation.