A User Story Template for Effect Maps


If you are into User Experience (UX), you may be using effect maps, also known as impact maps or goal maps, to guide software development towards the intended effects. These maps are used to describe how your business goals will be achieved by helping important target groups fulfill their goals of using your product or service.

If you are using agile software development, you are probably using user stories to describe your features for development using some common template. In this post I will suggest a new user story template, specifically designed to be combined with effect maps.

New Template

The template I suggest looks like this:

In order to <achieve business effect>,
As <target group representative>
Wanting/Needing <goal or need>,
When <use scenario>
I want/need <feature>

The first line describes the business effect, to which this story will contribute. The 2nd line describes a representative of the main target group affected, e.g. a user role or persona. The 3rd line describes the main goal the user has when using the system. For example, when using a cash machine, my main goal is probably to withdraw some cash. The 4th and 5th lines describe the process and a step to achieve my goal. The idea here is that a series of features, each described by a user story, will be used in a scenario, cf. Story Mapping. A scenario may lead to my ultimate goal or it may just represent a sub- or side-process.

The order of the lines are important, primarily because they move from the important and large (the intended, long-term business effect) to the less important and small (the feature). This makes it necessary to use three parts, hence the commas after line 1 and 3. These are inserted only to improve readability.

Some examples are in order. Let’s say you run a poetry publishing house. It’s not lucrative, to say the least, but you have high hopes for your new app. The main idea is that people will read a “Poem of the day” and if they like it they can easily buy the book from you.

In order to increase poetry book sales,
As an avid poetry reader
Wanting to acquire great poetry books with ease,
When ordering a book
I want to view the cover of the book in which the poem is published

The marketing department are keen on finding out how well the app is doing so they wish to track if a visitor came from the app:

In order to use our marketing budget optimally,
As a market analyst
Wanting to make market decisions based on facts,
When reading a web statistics report
I want to view a record showing number of visitors from the app

Effect Maps

Some readers may have recognised effect maps in the description above. This is a tool part of effect management in the use-centred school of user experience design. Although all UX is about achieving business effects through users, effect maps were first presented by Ingrid Domingues and Mijo Balic in their groundbreaking book Effect Managing IT. Effect maps are well known in the UX community, but are now also getting attention in agile circles, mainly because of their usefulness in connection with BDD/Specification by Example.

Effect maps are based on the notion that there is often a wide gap between what a business wants and the techniques to achieve it. This gap needs to be filled with people, because only people can use the tools you supply and it is only when they use it that business value may emerge.

Effect maps typically contain four levels:

  1. Desired business effects, possibly with measurements (answers “Why do we want this?”)
  2. Target groups (answers “Who can help us achieve it?”)
  3. Needs or goals (answers “What do they need for this?”)
  4. Actions (answers “How will we achieve this?”)

The observant reader may have noticed that the user story in the suggested format passes through each node and arc on a line going from a business goal to the actions.

User Stories

User stories were popularised in the Extreme Programming (XP) development method by Kent Beck. The main idea was to put the customer (user) back in the centre – not the person paying for the software, but the one most affected by it.

In its general form its simply a one or two sentence description of something that we want. A software feature, typically. It is deliberately very short to keep people from specifying too much. The intention is to work more like a memory note, reminding us to have a conversation later about this thing that we think we want.

The original user story was free format. However, two popular story templates have emerged. These templates are helpful, especially to beginners, since they remind us to think of important parts of a story.

The first template, developed by a team at Connextra (2001), looks like this:

As a <role>
I want <goal/desire>
So that <benefit>

for example,

As a poetry reader
I want to see the origin of a poem
So that I know which book it was from

This template puts the user role in the forefront. Its value part typically describes value as seen from the user. Sometimes, value from the business’ point of view is used, but it may be hard to make that coherent.

The second template was developed by Chris Matts as part of Feature Injection to put more emphasis on business value. To develop some feature we are striving for some business value. This template looks like this:

In order to <receive benefit>,
As a <role>
I want <goal/desire>

for example,

In order to increase poetry book sales,
As a poetry reader
I want to see the origin of a poem

The two popular templates are both conceived without regard for effect management. I want to use a format that takes effect maps into account. Both the old templates have placeholders for value and role, which are similar but not the same as business effect and target group here, which are more specific and related to the effect map.

Pros and Cons

I believe this user story format has some of the same advantages as effect maps. It gives us a good overview. It clearly shows what we’re looking for, who’s going to help us, and what these people want in connection with this. Another advantage is traceability. Each user story clearly maps to your effect map. A third advantage is that it test drives your effect map. If your map is incoherent, your user story won’t make any sense. Example:

In order to increase uptime of our servers,
As a system administrator
Wanting stable systems,
When migrating book ordering to our new platform
I want to view the cover of the book in which the poem is published

The downside of the template is that it is long and therefore hard to remember. The smaller formats are more elegant. However, if you know your effect maps, it should not be hard to remember. If you are not using effect maps, I would suggest using a simpler template.

The user story templates are like little checklists that help us remember to work with needs instead of technical solutions. Like all checklists you adapt it to your situation.