Article written with Doug Kim
In 1983, Alan Cooper gave life to the first design persona with a wave of his hands. A pioneering software developer, Cooper had just interviewed a group of potential customers. He realized that focusing on real customer motivations rather than his own needs could spark better solutions to complicated problems. For the rest of his design critique, Cooper began assuming the gestures, speaking habits, and thought processes of made-up individuals who were loosely based on the people he’d interviewed.
Personas quickly took off in both design curriculum and the software industry. And for good reason: personas help us gain a better understanding of our customers’ needs and anticipate how they might act in situations where direct communication with them isn’t feasible.
But we’ve since realized a problem with personas. They are inherently an amalgamation, an average of attributes that we imagine our average customer has. And there’s no such thing as the average customer.
In the 1950s, the US Air Force conducted a famous study on pilot size. They measured the physical dimensions of more than 4,000 pilots and calculated the average size along 140 dimensions, like height and chest circumference. They arrived at an average range for all 140 dimensions and theorized that most pilots would fit within that range. As it turns out, not a single pilot of all 4,000 fit within the average range for all 10 dimensions.
The consequences of designing for the average pilot were potentially deadly. The ergonomics of planes, which were built based on “average” pilot size, were so off that pilots were crashing as a result. The planes were created for everyone but really no one at all.
We repeat the same error every day in product development. We imagine a persona — let’s say his name is Ted. We give him attributes, like a family, a high-powered job, a suburban house, and two cars (see main image). Maybe he’s got a cat. Then we’ll have debates about what Ted would or wouldn’t like. “Can you really imagine that Ted would be ok with that product decision? From what I understand about Ted’s profile, I don’t think so.”
And really, no one knows what Ted would like because Ted doesn’t exist. It sounds obvious when you put it that way. But it’s challenging, because the more “human” we try to make Ted by adding specific personality traits and details about his habits, the more we unconsciously stereotype him. We make it harder on ourselves in the heat of the moment to remember that Ted is an abstract representation of research insights.
Even worse, every bit of overly specific detail we attribute to Ted makes him less representative of the general audience we want to design for. In such design work, the person who doesn’t exist can begin to erode and erase the presence of people who actually do. Often, ‘Teds’ are: created in siloes without a defined goal or purpose, kept static across time and use cases, not flexible and adaptable, and, grounded in artifacts product teams/designers can’t use.
As we move toward building intelligent, responsive systems, we need new tools that further embrace diversity and respect multiple contexts and capabilities.
We need tools that reintroduce diversity into our design process. Every decision we make either raises or lowers barriers to participation in society. Inclusive design emphasizes our responsibility to solve for mismatches between humans and their products, environments, and social structures. We need ways to check, balance, and measure the inclusivity of our designs.
So how can we put real customers first and circumvent the notion of an artificial average? One way is to kill your personas (sorry, Ted) and adopt a model of persona spectrums. Instead of defining one character, persona spectrums focus our attention on a range of customer motivations, contexts, abilities, and circumstances.
A persona spectrum is not a fake person. It’s an articulation of a specific human motivation and the ways it’s shared across multiple groups. It shows how that motivation can change depending on context. Sometimes, a trait can be permanent, like someone who has been blind since birth. A person recovering from eye surgery might temporarily have limited or no vision. Another person might face this barrier in certain environments, like when dealing with screen glare out in the sun. How would your product adapt to this range of people and circumstances with similar needs?
Persona spectrums aren’t perfect, but they help us create more equitable experiences. They use the power of personas to ground and humanize user insight while keeping different human attributes distinct. By designing along a spectrum of need and motivation, we avoid the biases and assumptions built into a persona. We design for a diverse range of real users instead of one average, theoretical Ted.
Persona spectrums are more than just a tool for empathy. They also make a business case. Say you’re designing for someone with one arm. There are roughly 20,000 people in the US with one arm. But if you add up the numbers of people with one arm, people with a temporary wrist injury or a broken arm, and folks with one free hand in a specific circumstance (like new parents lugging a baby around), you’re at 20 million in the U.S. alone.
At Microsoft Design, we’re working to use persona spectrums across a range of products. We’re asking hard questions about the intent and limitations of our personas, so we can design for real people in real situations. We use these spectrums to ideate and iterate in the design process alongside a series of physical, social, economic, temporal, cultural contexts.
It’s important to learn from diversity and bring people into the process from the very beginning. By gathering real insights from real people who share the motivations we’re designing for, we can start understanding and incorporating the full range of human diversity, designing for individuality and the motivations that unify us.
In the coming weeks, we’ll share actionable insight for building your own. In the meantime, learn more about how to design with inclusive in mind by downloading our Inclusive Design tool kit. Check out other ways we’re applying spectrums in our product work: Designing for Guidance and Designing for Focus.