From user story to user flow

A user story describes the type of user, what they want and why, in one sentence. They help to create a simplified description of a requirement and the list of user stories can function as the backbone of a product or service.

A user story is usually formulated as:

As a [persona], I want to [task] so that I can [goal].

For example:

As a reporter, I want to submit my material as fast as possible so that the NGO can be added to the website.

In addition to these 3 items, I thought it can be useful to add “When I” for additional context.

So the full user story becomes:

As a [persona], when I [context] I want to [task] so that I can [goal].

Added to the aforementioned example it becomes:

As a reporter, when I‘ve finished investigating an NGO I want to submit my material as fast as possible so that the NGO can be added to the website.

It also helps to to gain insight in how valuable each of the user stories are, which can determine the priority of development. So I aim to gauge early on how important it is through adding a “value” number that can range between 0-100.

So eventually I end up with a long list of user stories that all need to be addressed in one way or another. The question that remains is how.

Sometimes the answer to addressing a user story can be found in a single component, sometimes in a combination of components over multiple pages or sometimes it can be spread out over multiple products. For example, as part of a registration process the user requires to check their email to find a registration code.

So rather than confining a user story to a single object, it makes more sense to call the addressing of a story a “solution” that solves their goal.

As we saw earlier, examples of solutions can be components, pages (consisting out of multiple components), emails or a combination of any of those. These combinations can be greatly depicted in user flow charts.

The user flow chart shows how the user travels within the context and constraints of a product or service (or a set of products and services) to achieve their goal. Charts can both be created for current states and future states. Often a current state analysis could point out the various annoyances a user needs to jump through fairly quickly.

For future state charts, they help enormously in determining higher level functions of individual steps that need to be completed in order to achieve a user goal. This in turn helps in drafting the IA, page models and eventually the wireframes of products and making sure they all work together to address whatever it was that they were built for, leading to my final point; they also help in determining what should be tested for usability.

For Fair Photo, I created future state flow charts for the high value user stories. The following user flow is the user flow that applies to the example that was mentioned above.

Sometimes there can be multiple ways to do the same thing, though the path in red indicates that this route is important and should function as a must have (from the MoSCoW method). This is giving priority in design, development and testing.