Storymapping: A MacGyver Approach to Content Strategy, Part 1

By Lis Hubert and Donna Lichaw

Published: February 24, 2014

“The nonprofit needed help solving a common problem…. They asked us to create a digital product of some kind that would enable the intended users of the programs’ content to continue reaping its benefits.”

Wouldn’t it be great to experiment with a new user experience method at a company that truly needs it—with people who are not only great UX colleagues, but also great friends? Sounds like an ideal situation doesn’t it? Well, that is the situation in which we found ourselves back in November 2013. A nonprofit based in New York City hired us to help them figure out their long-term strategy. Without hesitation, we jumped on board.

The Problem

The nonprofit needed help solving a common problem that many companies and organizations face. With a nonprofit program nearing the end of its grant, they were looking for a way to disseminate the content from that program once the money ran out. Ultimately, the nonprofit wanted to be able apply whatever solution we came up with to their other programs as well. They asked us to create a digital product of some kind that would enable the intended users of the programs’ content to continue reaping its benefits.

Working with nonprofits whose programs are coming to an end may not sound like the type of problem that many UX professionals would have, but translate this nonprofit’s need into something like: “We need a way to put our content online so…,” and you have a common issue that abounds in the world of UX design. In fact, there are many methods in our UX toolbox that can help us to solve such problems.

Out with the Old

“If time and budget were no issue, we would have approached this project just as we’ve approached successful projects in the past—with an in-depth discovery phase that might have lasted anywhere from a week to many weeks.”

If time and budget were no issue, we would have approached this project just as we’ve approached successful projects in the past—with an in-depth discovery phase that might have lasted anywhere from a week to many weeks. This phase would start with us interviewing stakeholders, so we could collect, define, and prioritize organizational and project goals. Next, we would conduct user interviews, which would lead to our creating detailed personas that would model the user types that are the audience for the organization’s content. We would then create an inventory of all of the content, so we could determine the content’s strengths, weaknesses, and gaps. Lastly, we would set priorities and plan our strategy and roadmap for the organization’s content. All of this is consistent with what we’ve learned about how we should do good UX strategy—given certain circumstances. But we should ask ourselves: what makes these methods so good?

The Good

“Bringing the entire group of stakeholders together to discuss everyone’s goals, needs, and priorities is … a sure-fire way to come up with a prioritized list of organizational goals to guide design.”

Well, the first thing that makes these methods good is that they work! Taking the time to talk with each stakeholder to understand their individual business needs and goals, then bringing the entire group of stakeholders together to discuss everyone’s goals, needs, and priorities is not just good practice. It is a sure-fire way to come up with a prioritized list of organizational goals to guide design.

Interviewing users to understand their behaviors, goals, needs, and tasks, then modeling these into detailed personas is a great way both to understand users and to help others to have empathy for them. This understanding is at the center of the user-centered design philosophy that UX professionals live by.

And lastly, given content inventories’ detail and structure, they provide a perfect tool for understanding an organization’s content—both what is available and where there are gaps. They let us look at the big picture, giving us an eagle-eye view of an organization’s content. Once we have that overview we can start to see what content should be digital and what should be analog. This was exactly what the nonprofit organization that hired us needed—an organized and prioritized view of their content.

However, these methods that we have come to know and love are not all roses….

The Bad

“The first and perhaps the greatest issue with incorporating these methods into a project is that they take time—and lots of it.”

The first and perhaps the greatest issue with incorporating these methods into a project is that they take time—and lots of it. On this project, we did not have a great deal of time for interviewing each stakeholder, conducting in-depth user research, and modeling personas; then sifting through, cataloging, and prioritizing a potentially endless amount of analog and digital content.

The second reason that these methods wouldn’t work for us on this project—and this relates to our not having a lot of time to dedicate to this project—was that the organization we were working with did not have the resources to pay two consultants to do full-time, long-term work. In short, the funds were just not there to cover an intensive, drawn-out discovery phase.

The third and most important reason why these traditional methods would not work for us is philosophical and methodological. Through many years of working both in-house and as external consultants, we have both come to believe that the best work happens when UX professionals are embedded with a team on site, teaching and facilitating the doing and the learning among the team members and its stakeholders. Following traditional methods wouldn’t have allowed us to spend as much time empowering the team to understand their own organizational content goals, users, and priorities.

Thus, we knew that we needed to achieve somewhat typical outcomes—an understanding of the content that the organization already had, what content they needed, what content was missing, and what content should be digital versus analog—using non-traditional methods that would be possible on a small budget ¬†and in very little time. So we devised a repeatable approach that would let us prioritize goals, understand users, and assess and prioritize the content—an approach that we like to call storymapping.

The Storymapping Approach

“First, we would need to get out of the building and start talking to and designing with actual users. Then, we needed to understand the content, so the team could start digitizing and filling gaps.”

We knew that, to complete this phase of the project, we had to accomplish four things:

  1. Create a prioritized list of program goals.
  2. Establish a baseline understanding of user needs and goals.
  3. Conduct a content audit and create a well-organized and prioritized list of content.
  4. Plan next steps.

Until we had accomplished all of these things, we couldn’t get any idea of what sort of digital product we should create for this nonprofit. First, we would need to get out of the building and start talking to and designing with actual users. Then, we needed to understand the content, so the team could start digitizing and filling gaps. If this sounds a little bit like a chicken-and-egg situation, it was. But we were working with what we had.

Once we had set our goals and drafted our personas, we decided to turn to an approach that Donna has adapted from her years as a filmmaker: narrative storymapping.

What is a story map? A diagram that maps out a story using a traditional narrative structure called a narrative arc. Why stories? Using stories in UX design, product management, product development, or engineering is nothing new. For years, agile development teams have articulated and structured their work as user stories, enabling teams to align around user needs and develop products with a clear purpose and specific outcomes in mind. UX designers have also used stories as a way to imagine and explore scenarios of use through the written word, storyboards, and comics.

“What is a story map? A diagram that maps out a story using a traditional narrative structure called a narrative arc.”

While all of these methods help us to ideate, explore, and record user needs, what if a narrative-arc diagram could also help us to rapidly assess content strengths, weaknesses, and opportunities? Film-making is a very deliberate art in which filmmakers plan, structure, and test everything. So is product development. Why not, indeed?

Because of the tight budget and timeline for this project and a lack of additional resources, we had to think quickly. Using storymapping, we found success by doing a month’s worth of work in just a week. Coming up in Parts 2 and 3 of this series, we’ll provide the science and research behind the storymapping approach, detail the workshop setup, describe how to use this approach; and discuss our results—both good and bad—takeaways, and outcomes from using this approach. This story is bound to be a good one, so we hope you’ll stick around to find out more about it!

2 Comments

Hello, I work for SamsClub.com with my agile team. Our IA and Designer are embedded on the team.

I like your post a lot. We started using storymapping this year. It has given us a jump on the backlog, enables a multi-sprint release plan, and our UX people are no longer trying to keep up with the Engineers.

When will Parts 2 and 3 be published? Or please help me find them?

Thanks!

Maryann

Hi Maryann, the second part has been published here.

Join the Discussion

Asterisks (*) indicate required information.