UX Prototyping
Story Mapping

Mick McQuaid

2025-02-01

WEEK FOUR

Story Mapping

The bird on the cover of Jeff Patton’s book, User Story Mapping, Patton (2014), is a lilac-breasted roller.

You should certainly read at least the Read this first chapter, followed by chapters 1 and 2. I’m just going to show you some pictures of story maps and give you some pointers on features they may share. Throughout this, bear in mind that the story map is not an outcome, but a prop in your conversation leading to a shared understanding of how your prototype will look.

A basic story map

Here the steps are the steps in the user’s journey toward some favorable outcome. The details can be components of the steps, both technology-based and other.

Giving instructions doesn’t always go well

Here are some instructions

• Customer: Hello, I’d like to order a cake.
• Employee: Sure, what would you like written on it?
• Customer: Could you write “So long, Alicia” in purple?
• Employee: Sure.
• Customer: And put stars around it?
• Employee: No problem. I’ve written this up, and will hand it to my cake decorator right away. We’ll have it for you in the morning.

Try to imagine what the employee is writing down while listening to the customer. Try to imagine the scenario of the employee. For example, is the employee juggling the phone and a notepad and pen? Or perhaps trying to write into a computer program with both hands while holding the phone against their shoulder? Details may matter in this communication breakdown.

And here is the result

This and the previous picture are from the CakeWrecks website, in this case documenting what the maintainer calls literals but which Jeff Patton refers to as failures in system requirements.

We need some way to get on the same page

The key feature of this cartoon is that everyone is contributing their take on what the solution looks like, and their take is exposed to everyone else. Everyone needs to speak, to write, and to draw for this to work.

A productive conversation with supporting artifacts

The centerpiece of developing requirements is a conversation. The words and pictures are supporting artifacts, not the main attraction. The artifacts: post-its, diagrams, sketches, can be quite messy, not at all like a refined requirements document. That’s fine. People misunderstand refined requirements documents.

A basic change-the-world model

Patton claims that, every time you set out to build software, you are setting out to change the world somehow. It may be a small change but it should be a worthy change, a change that will impact someone’s life. He claims that, every time you set out to build software, there are outputs and outcomes. He identifies the outcomes as the important things, the things you want to maximize, and the outputs as intermediate products, the things you want to minimize. So the requirements documents are not the important things, the shared conversation that gets everyone moving in the same direction is the important thing. He asserts that the purpose of this book is not so much to help you create better stories as to have a better story mapping process that supports the shared conversation.

A more refined change-the-world model

In Patton’s refined model, the emphasis is on the impacts of the outcomes. What does the software do in the real world?

A yet more refined change-the-world model

The final picture in this series says to minimize outputs and maximize outcomes and impacts. So you have to understand the difference between outputs and outcomes. Outputs include things like requirements documents and product specifications. These are typically difficult to understand. For example, I once participated in the creation of an RFP (request for proposals), where we wanted to buy a system from vendor A and avoid vendor B. So we put in code words and phrases that would be favorable to vendor A and unfavorable to vendor B, based on what we knew about their computer systems. We were a government agency, so we were required by law and regulation to accept the lowest cost bid that met our requirements. We weren’t really saying what we meant with our requirements. We were writing defensively, trying to stave off a vendor we knew to be clever in adding costs after the contract was concluded. We knew that they would come in with a lower bid, but would make their implementation more expensive in the long run. None of this stuff was about the software outcomes. Our documents were indecipherable to the average reader, but a land mine field for vendor B.

An early story map by the author and a collaborator

When Patton started using story maps, he created some very large story maps for elaborate processes. He used index cards and created a row of “big picture” activities in the real world, seen across the top in this picture. There appear to be about ten of these in the picture. Next is a row of concrete steps, perhaps thirty in number. Some of these steps have been expanded into details in columns of cards beneath them. The longest columns have about ten cards. So there are essentially three levels: activities in the real world, concrete steps, and details.

Flow of the early story map

The story is read from left to right. In this case, the software under consideration is supposed to support the promotional activities of musicians and musical event producers. There are two groups of people to consider in this story: band managers and fans. The software creates and manages promotional emails. This seems like an extremely simple task, yet notice how many index cards are needed to document the entire story.

One branch of the early story map

Here we see one branch of the story, with a single activity card, five step cards, and the six detail cards for one of the steps highlighted.

Annotated early story map

We may think of the story as the big left to right arrow, but there are many contextual items that don’t fit the flow, including

• products
• goals
• users
• ideas
• product principles
• details that don’t fit particular steps

We need all these contextual things, although they look like a big mess because they don’t fit into the flow.

THINK - WRITE - EXPLAIN - PLACE

As you develop the story map, you will THINK of things to add. When you THINK of something, immediately WRITE it down before explaining it to the others. Then EXPLAIN it, then PLACE your written artifact (probably a post-it) on the map. By the way, you are likely to use Figjam, Miro, or some similar software to create the map rather than physical post-its, especially if you want to work remotely.

Another story map

Suppose you have different users at different stages of the story. You annotate the flow with cards depicting those users at the appropriate activity stages. Bonus points for you if you recognize the Dalek from Doctor Who.

Organizing details into three product release slices

Notice the three horizontal sections numbered 1, 2, 3, and separated by thick lines. Each one of these represents a specific product release, perhaps beta, release, and version 2. The details are the aspects of the software that will be implemented for each of these releases.

Story maps support a conversation that builds shared understanding

• The map is a prop, not an outcome
• Maximize outcomes, minimize output
• Prioritize outcomes, not features

Agile software development is generally organized around product features. Patton argues that this approach misses the impactful nature of software on real world outcomes. He suggests keeping these points in mind during the creation of a story map. He also places the map in a very humble position as a prop. Don’t highlight the story map—instead use it to promote outcomes. There’s no need to formalize the story map after it’s been created. You can revisit it, but not with a view to formalizing it.

Scenarios

We suspect storyboards are a longstanding tool of humans, but we can’t be sure exactly how old they are. This cartoon was reprinted in Simon (2007).

Detail from the cover of Costola (2022)

Scenarios have been a building block since at least 1545, when Commedia dell’Arte began in Italy. There, the scenario consisted of ingredients that actors could use to improvise a comic routine.

Now we fast-forward to 1955, when Alfred Hitchcock, like many filmmakers, used storyboards to plan his projects. Hitchcock hired a sketch artist and zoomed around his office with his arms outstretched to simulate the menacing airplane in this scene from North by Northwest.

The storyboard was a means to an end and the end is seen in this still from North by Northwest.

Beginning of the Picking Up a Key exercise from McCloud (2006)

Storyboards are sometimes an end in themselves in comics, although they are used to plan comics. You did an exercise in using a storyboard to tell a complete story with Picking up a key.

Example from Aaseng et al. (2020)

You don’t need much skill to draw the figures you need in a storyboard. Try imitating this action pose.

Example from Aaseng et al. (2020)

There are many ways to convey dialog or thoughts in storyboards. You don’t always need words but, when you do, you can contextualize them in many types of balloons.

Difference between scenarios and storyboards

• The scenario is the concept
• The storyboard is the implementation
• Both words are often used interchangeably

How to use scenarios

• represent the story of the work
• represent a successful process
• inject the personas into their work
• illustrate what you found from contextual inquiry

types of scenario frames

Characteristics

• Readable like a comic strip
• One step per frame
• Rough user interfaces
• Manual actions
• Cartoons of people

Evaluate the scenario

• include words where a stranger would not understand
• show storyboard to someone: ask what it says
• check for
  • confusion
  • inconsistencies
  • too much detail

Advice

• avoid design choices
• avoid cut and paste artwork
• use hand drawn pictures
• show a progression
• tell a story

More advice

Here’s an example from class where the student used the hat and the ponytails to easily identify the two main characters. Matt Groenig, the inventor of the Simpsons, claims that each character needs an easily identifiable characteristic to differentiate that character from others.

example: from Nielsen Norman group

https://youtu.be/bNh54LNUtv8

let’s do a storyboard in Figma

divide up canvas like a comic book page

set a timeline

• amount of time to decide what each panel will convey
  • 10 min to plan
• amount of time to spend on each panel
  • 5 × 4 = 20 min on four panels ✓

Process

• start at beginning
• then add the end
• finally, fill in the middle

storyboard topic

• use a project idea if you have one
• else … use Luigi!
• Mick wants to buy from Luigi
• can be a case or strap

Parameters

• Mick is concerned about appearance of camera in case or with strap
• Mick is concerned about size and placement of straps when carried
• Mick is concerned about comparative prices
• Mick is impressed by aura Luigi has among photogs

remember the blank panels?

after feedback, they tried again

References

Aaseng, Maury, Bob Berry, Jim Campbell, Dana Muise, and Joe Oesterle. 2020. Art of Comic Book Drawing, the. Mission Viejo, CA: Quarto Publishing Group.

Costola, Sergio. 2022. Commedia Dell’arte Scenarios. New York, NY: Routledge.

McCloud, Scott. 2006. Making Comics: Storytelling Secrets of Comics, Manga and Graphic Novels. Harper Paperbacks.

Patton, Jeff. 2014. User Story Mapping. Sebastopol, CA: O’Reilly Media.

Simon, Mark. 2007. Storyboards: Motion in Art. Burlington, MA: Focal Press.

END

Colophon

This slideshow was produced using quarto

Fonts are League Gothic and Lato