UX Centered Product Leader

Agile Personas and Context Scenario

After sitting through a grueling week-long inception with our stakeholders and the project team, we have a good set of user stories. Everyone feels pretty good about choosing the right stuff to build and the order in which to build it. I know that when we start building the thing via these individual stories, it will be hard to figure out how everything hangs together.

As developers start to build the functionality, the individual pieces look and work OK, but the software feels like “Frankenware”–lots of pieces bolted together into something that neither looks nor feels good. Our business owners, who are proxies for our end users, acknowledge that the software has all the features they prioritized as high, but the features are not exactly useful in the context of the daily task.

It’s like I was saying to my buddy Mark just yesterday — if we were designing a tool that would help someone do everything they needed to do to get out of the house in the morning, we’d start with a story that we’d plop in Mingle. It would say something like: ” The user wants to get out of the house so that she can go to work.” The BA would look at that story and come up with all the functional requirements to build a door that opens — so that the user could get out of the house. There would be another story to close the door … and to lock it.

What I said was — “there is no way I am getting out of the house without coffee. That’s a requirement.”

What we need is one big story that makes sense of all the little user stories.

A User Context Scenario is the connective tissue story we are looking for. This is a narrative description of a person using our solution to successfully reach a goal. In the course of telling this story, we select a persona who needs to use a number of the features (represented by stories) that our software has in scope for this iteration.

We work with our existing personas. In this example, we meet Betty, an HR generalist.

Betty is an HR generalist. We’ve identified her persona through research. This is an “agile” persona.

Betty has goals. GOALS are important to the context of the story. Notice that Betty’s goal is not ” Find a user in the database”. Her goal as a networker and ambassador for her company is to “Put a face to Vijay’s name”. The context of that goal implies features and functions that should be considered in the application.

This is where we articulate Betty’s goals in the context of some features we’ve identified in stories.

Notice that sprinkled throughout the scenario are the goals of the software’s primary user (Betty) and its secondary user (Vijay), along with commentary that gives us an idea of how often this process occurs, how long it might take, and what’s going on in the real world while the Betty is using the system. These things make the scenario tangible and memorable.

We can use concept wireframe sketches to describe the activity visually.

The best way I have found to work through these stories is to pull together a group of people that includes end-users and those familiar with the features in scope. A group of three to five people is a good size. Start by discussing the user and the context . Describe the person, the place, and the situation, and then proceed to describe the scene that plays out. As we discuss it, we work through the context scenario on a whiteboard where everyone can see it. Once it is drawn there, we can take pics and then sketch it up using In Design, MS Visio or Balsamiq.

We talk about specifics in the story. What happens if there are a bunch of search results?

Context scenarios are pretty awesome for building and validating a lo-fidelity UI prototype. A UI prototype set to a user scenario is referred to as a storyboard — for this purpose, I will sometimes put together a power point click -through like you see in this example.

Try to write the scenario in such a way that it doesn’t restrict any options in the UI and get bogged down in the technical!

By walking through stories at the beginning of a release cycle when the team is choosing stories for development, providing a context view from the user perspective is critical for uncovering out some of the little things, like “how to get back to the beginning of a process” that will crop up during development. Scenarios make good test cases for lo and hi-fi testing. If we can get our training folks involved during the creation, it makes it easier for them to start their work earlier in the release cycle.

A lot of good things happen when you write a scenario. Those implementing the software clearly understand the context of use–where the user is and the kinds of features that need to be in the software

As a creative person, I admit that it’s tempting to engage in creative writing for the sake of story-telling. At times the scenario can draw attention to a feature or detail that is actually insignificant. All in all, I have found context scenarios to be really helpful in communicating to the team. They are also nice in that they help us connect the stories into usable flows.

Now, how do I do that as an “Agilest”? I’ve done it a bunch in long-drawn out processes — where I could Ideate all this stuff and then hand it off. Now I am trying to work ahead of the curve.

Right now, it looks like in iteration ZERO while developers are figuring out the data model, I am putting together context stories for iteration One.

3 Comments

[…] Pressed to explain that context scenarios don’t just come out of thin air — I put together a list of questions we need to have answered before we can write some narratives about users solving their problems…. […]

[…] get to a scalable solution a component approach to design. Our approach to this is to take the context scenarios we wrote a few months ago and break them apart into types of work the user is doing along the way […]