Originally published: May 07, 2014
“The medium of the designer is behavior.” - Robert Fabricant
As designers, this is what we do. We observe our user behaving in a way that we think we can improve. And then we set out to improve it.
Maybe they aren’t quickly finding the information they’re seeking? Or they can’t fill out the form without receiving error messages? Or we can imagine a more delightful way to help them with an important task?
In that moment, we see the user’s behavior we want to change. We change our design and look to see if that behavior changes as a result.
We don’t directly manipulate the user’s behavior. It’s indirect magic that happens through the designs we create.
Yet, with practice, we become good at it. We can learn how changing pixels, text, images, and controls can change how the user interacts with the design.
Knowing how to change the users’ behaviors is one thing. Knowing which behaviors to change is another.
There are often many approaches to improving a design. Everyone can think they are working towards a better overall experience, but if each team member chooses a different approach, the design becomes confusing and complex.
When we’re working on a team, getting the entire team to work together from the same approach becomes job one. Smaller teams (such as those with six or less folks) have always had an easier time of this than larger ones. This is because it’s more likely the smaller teams are checking in and talking to each other.
Fortunately, there’s help for larger teams. It comes in a technique that is as old as humanity - storytelling.
We’ve all experienced that family member who tells the same story at every family get-together. Their story never changes and you could probably recite it verbatim, as if it had happened to you.
That’s the beauty of great storytelling. It brings the listener into the story, helping them live through the described experiences.
This is what makes storytelling ideal for communicating the behaviors we want to design for. We come up with a compelling story for our design and repeat it to help everyone on the team know it as well as we do. That story becomes the guiding force behind the individual design decisions. And stories are more fun, and therefore more effective, than a long, technical design specification.
With this approach, the designer shifts from being the one who makes every design decision, to a type of narrator, that paints the scene and characters for those decisions. The individual members of the team then craft/mold the design to fit the story. Fitting the design to a story brings the team’s discourse to a higher level, giving more power to build great experiences.
The user experience toolbox already provides us with some techniques that make storytelling easy.
Every screen, dialog box, and form option takes place inside the user’s context. We can design what the user does when they interact with those elements. But, that doesn’t explain why they are interacting at that moment.
Scenarios give us the motivation behind the users’ interactions. Conventionally, we’ve used scenarios to help identify how features should work. By returning to the scenario frequently throughout the design process, we can now use them to reiterate the overall story of the design.
Scenarios are stories about the users’ behaviors. These stories don’t say exactly what the screen should look like or what buttons the user will press. They leave those details for the design.
Instead, scenarios showcase the contours of where the design needs to fit in the users’ life. The scenarios describe the steps that brought the user to the moment of using the design and the activities that follow. They put definition around what a successful interaction looks like.
When the designer plays the role of narrator, they need to constantly resurface the project’s scenarios. Using every opportunity, they need to make the scenarios drive the ongoing design discussion. (Techniques, like the Short-form Creative Brief help make this a habit.)
Developers manage their backlog by constructing user stories. These simple statements often take the form of “As a <type of user>, I want to <achieve this goal> so that <some reason>.” By blasting through a list of user stories, the developers can quickly assemble the functionality necessary to operate the design.
User stories are a great development tool. However, they work best if the designer can bring back the scenarios from which they emerged. If the developers understand both the user story and the scenario, they’ll know to pay attention to the other functions that come before and after the point in time that the user story takes place.
For example, a team might have a password reset function on their backlog: “As a customer, I want to reset my password so that I can log in when I’ve forgotten it.” This is a complete user story, but it doesn’t tell us why the user came to the site in the first place.
Matching the user story with a scenario could tell us that the customer was responding to a marketing campaign and, after they’ve reset the password, it should return them to the landing page for the campaign. (Or, even better, not require authentication to see the landing page until the user wants to perform an action that warrants the security.)
Mapping the journey of a user provides another storytelling prop for designers. Journey maps are often simple diagrams that show how a user interacts with the design over time. Teams love them because they clearly express where a design becomes frustrating and where it does a great job of delighting its user.
Like any good map, designers can zoom into the user experience at an appropriate level for the problem at hand, then zoom back out to look at the bigger experience. This gives the designer flexibility to tell the story in a way that makes sense for the team’s current objectives.
Designers can start design discussions by taking a moment and saying, “here’s where we are,” pointing to the place in the map where the interaction will take place. The team can construct what the zoomed in section looks like now and draw out how they think the new behaviors might change it.
Most frequently, we see journey maps representing what the current users’ experience is. It shows the highs and lows as users interact with the design today.
But we’ve been seeing more teams overlaying that experience with an aspirational journey, which shows the journey the team is aiming to create. They imagine the behaviors they want to see from their design revisions and put those thoughts on the map, next to the current journey.
The space on the map between the current users’ experience and the aspirational journey becomes a vision of what the design could be. By sharing both journeys throughout the design process, the designer can help the team better see where they are going. Individual team members can ask, as they face important decisions, if what they are planning will get them closer or farther away from that vision.
As the design is changed, the team can plot its progress on the map, showing how close to the aspiration they’ve gotten so far. As user research tells them more about what their users want and need, they can also add that information to the aspirational journey.
As teams develop a richer sense of design, keeping them on the same page will be the designer’s biggest challenge. Infusing the design culture with a rich sense of storytelling, and using the tools in the UX toolbox to help tell those stories, will reduce that challenge substantially.
Dive deep into scenarios and journey maps with Kim Goodwin’s workshop, Use Scenarios to Solve Design Problems at the User Interface 19 Conference, October 27-29 in Boston. Use promotion code ARTICLE for $200 off the current registration price.
Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems. You can follow Jared on Twitter @jmspool.
How do you encourage creating stories in your design team? Tell us about it at the UIE blog.
Read related articles: