An Iterative Approach to Scenarios and Personas

by Jared M. Spool

Great design anticipates the users’ needs. It matches what the user is trying to accomplish.

Not all people have the same needs, even if they desire the same outcome. The variations between users and how they go about achieving their objectives can be subtle and nuanced. Teams need to have a clear picture of those variations to design for users who require different things.

Scenarios and personas work best when they provide the team with a detailed understanding of who the users are and what those users need. The scenarios and personas function as a role-playing tool, showing designers where their design works well and where it could still use improvement.

The trap: The all-at-once approach.

A common trap that design teams run into is when they make their scenario and persona efforts as a single phase of the project. They spend whatever limited research budget they have all at once, trying to produce a single set of definitive documentation that describes their identified scenarios and personas.

This all-at-once approach does the opposite of the team’s intention. It creates a limited, static view of the users and their needs. That view is not supposed to change for the duration of the project.

Their static scenarios describe what the team believes the users need to accomplish. The static personas describe what the team believes makes one user different from another. The design team can use the documents they produced for the rest of the project.

At least, that’s the theory.

In practice, the team built out those scenarios and personas with limited research. The approach assumed they saw everything they needed to see from that one research effort.

We know that design is iterative. Yet, using this approach, the team doesn’t give themselves an opportunity to iterate over the scenarios and personas they’ve developed.

A plan for iterating on our scenarios and personas.

An alternative is to create the scenarios and personas iteratively. We can do this by integrating them into a steady stream of research throughout the project.

For many projects, we start with stakeholder interviews. That’s research we can start with. We take what we learn about our users and their needs from those interviews and craft the first draft of the scenario and persona descriptions.

When stakeholders give us requirements, we can reframe them as assumptions that need validation. We use that opportunity to launch a small research project to meet some users and investigate the stakeholders’ beliefs. We add what we learn to our scenario and persona descriptions.

As the design project progresses, we find more opportunities to meet and observe our users. Each time we uncover new insights about the users and how they interact with our design, we update our descriptions.

Even the process of recruiting participants for these ongoing research sessions is research in itself. As we talk to potential participants, we’ll find out what makes them similar or different to other users we’ve interacted with. Maybe they don’t fit the particular study we want to do? That’s telling us what we don’t want. We can add that into our descriptions.

The descriptions are only a souvenir.

As we do research throughout the project, we’re continually refining our understanding of the user. With this knowledge, we improve the description documents. They become an up-to-date resource, representing the insights we’ve learned throughout the project.

However, documents are problematic. They only contain a snapshot of what we’ve learned. They’re a souvenir of our research.

A souvenir serves as a reminder. When we look through a fun vacation’s souvenir booklet, it has the benefit of putting us back into the experience of that vacation.

But that only works if we were the ones who experienced the vacation. Looking at someone else’s souvenir booklet doesn’t thrust us into their fun experience.

That’s why everyone on our team needs to have exposure to our users. They need to form their own experiences by meeting and observing the users. And they contribute their own insights to the descriptions, making the souvenir valuable to them.

Building scenarios and personas is an ongoing process.

Most products and services we work on live beyond their first release. There are feature enhancements and subsequent improvements.

Continual research will tell us how our users have adapted to the design. We’ll see them use the design in ways we never expected. We’ll see differences between users we hadn’t seen before. Once again, we update our descriptions.

Those description documents represent the cumulative knowledge and insights we’ve acquired about our users’ scenarios and personas over the life of the product or service. Every update helps us develop a deeper understanding of what we need to build.

We use this forever-growing knowledge to create great designs. By investing in continual research, we learn what it takes to deliver well-designed products and services to our users.

About the Author

Jared M. Spool is a co-founder of Center Centre and the founder of UIE. In 2016, with Dr. Leslie Jensen-Inman, he opened Center Centre, a new design school in Chattanooga, TN to create the next generation of industry-ready UX Designers. They created a revolutionary approach to vocational training, infusing Jared’s decades of UX experience with Leslie’s mastery of experience-based learning methodologies.

Enroll in Our Four-Week Live Course on Outcome-Driven UX Metrics.

Establish your team’s 2025 UX metrics and goals by investing just 4 hours a week in our new Outcome-Driven UX Metrics course, featuring 8 hours of pre-recorded lectures and 8 hours of live coaching sessions with Jared.

You’ll learn to set inspiring UX goals, boost your team’s strategic impact, and receive personalized coaching, all while gaining access to a community of 51,000+ UX leaders.

Join this course and establish your UX Metrics today.