Published: May 22, 2007
Next time you have a chance to watch someone reading a map, look for the first thing they do. They'll likely do the exact same thing everyone else does: find themselves on the map.
It doesn't matter what kind of map it is, whether it's of their neighborhood or an amusement park. They'll open the map and find something that is personally meaningful, such as their house or their favorite roller coaster.
Psychologists call this 'grounding'—the natural behavior of initially finding a known reference point in a foreign information space. Once the person has grounded themselves, they can then use the starting point to understand the rest of the space.
While grounding helps people adjust to complex situations, it can be detrimental when it happens during the design process. If, while conjuring up an interface, designers ground themselves in the design, they run the serious risk of creating an interface that only they can use.
Creating an interface for yourself is great if you're going to be the only user. When we decide how we'll arrange our kitchen cabinets—where the plates, glasses, pots, and pans will go—we want to put ourselves into the design. But, we don't expect other people to wander into our kitchen and start grabbing things without help.
When we're creating online interfaces, it's a whole different story. Here we're designing for others, not for ourselves. We may know too much about the layout and structure. We'll understand the relationships between various design elements ("That button is only used with this dropdown"). We are very familiar with the jargon and business rules.
Therefore, when a designer grounds themselves in their own design, they run the risk of designing an interface that only they can use. Any tools that help designers prevent the natural behavior of grounding helps them attack the design more objectively, with their target user in mind.
We recently had the opportunity to talk with several design teams currently using personas to help create their designs. We discovered, while studying how they integrated their personas into their design work, one major benefit was to prevent grounding.
Personas are model users that the team creates to help understand the goals, motivations, and behaviors of the people who will use the interface. The persona represents behavior patterns, helping the designer understand the flow of the user's day and how the interface will fit into it.
The teams we interviewed used personas as a way to avoid the grounding problem. Instead of asking, "How would I use this system?" they asked, "How would Mary use the system?" They found their persona's (Mary) initial reference point instead of their own, making judgments about the design from the persona's point of view.
One team in our study was working on an investment tool, primarily used by retirees. The team, who consisted of primarily 20-somethings, naturally assumed that, when they retire, they would have simple investment and financial needs. As a result, they created the initial design for simple transactions.
Their subsequent field research produced a persona named Ron, an active 76-year-old who had nine sources of income, three mortgages, and needed to write 21 checks every month from his multiple accounts. In the field, the team had seen many people similar to Ron and their transactions were anything but simple.
As soon as the team looked at their design from Ron's perspective, they realized that their simple transaction approach was going to complicate his life immensely. Putting Ron into the design, instead of themselves, made them realize that they needed to take a different approach.
It turns out that preventing grounding wasn't the only major benefit of personas we discovered during our research. Two others jumped out at us as well.
As we studied teams who made substantial use of personas, we noticed that the personas were talked about frequently, almost in mythical terms. The team members had made up lives for these people, usually based on the actual observations they made when they studied real users. They constantly used these imaginary lives to relate important stories about how these users would interact with the proposed designs.
Storytelling is an age-old tradition. Long before the written word, humans have used stories to teach their children values and prepare people for the world ahead.
This tradition hasn't gone away. A few years ago, Xerox Corporation set about studying how field repair technicians learned to effectively deal with infrequent, yet complex problems.
The researchers originally assumed that it was a mix of training and mentoring that played the biggest role. They were shocked to discover that those technicians who were best prepared for the craziest problems didn't learn how to solve them in a classroom or by tagging along with a more senior technician.
Instead, they learned that the war stories exchanged when the technicians got together were the biggest contributors to their education. In these informal get-togethers, technicians would brag about their accomplishments and try and shock their peers with stories of woe and wonder. It was in the details of the stories that the field technicians attributed their best education.
The teams we researched did the same thing. They got together and told stories about how their personas would tackle some problem. In the details of these stories, team members would start to get a real sense of who these users were and the problems they might encounter.
Using just the oral tradition, the stories become distorted with every new telling. Many of the teams prevented this distortion by capturing the stories along with the persona descriptions. (One team went so far as to create a screensaver that would randomly display the pictures, backgrounds, and stories of each persona on the development team's
machines when they were idle.)
Along with preventing grounding and encouraging story telling, we found personas had a third benefit to the teams we studied: enhancing role playing.
From an early age, we use role playing as a way to safely explore the world around us. By pretending to be different people, we can try things out from their perspective, seeing if their viewpoint is different from our own.
Role playing has long been a part of design processes. For example, in the '80s, designers at Apple used comic strips and play acting to think through the lives of their users and how they would integrate a variety of products, real and imaginary, into those users' lives.
One design team we studied, who was in charge of a major electronic retailer's e-commerce site, had an analyst role play each of four personas, walking through the site as each character. For example, one persona was a mom who wanted to buy educational software and technology for her children. She wasn't a technical wiz, but wasn't
completely ignorant of the technology either.
The analyst adopted her role to play the shopper on the site. From that perspective, the analyst identified several issues with the design of the site that hadn't been discussed previously. As the analyst adopted the other three personas, different issues surfaced.
(Interestingly, we were independently doing a usability study on the site simultaneously and discovered many of the same issues as the analyst found from the four personas.)
When we adopt a role, we can start to view the world around us from that person's perspective. Using the persona as the target role, we can identify how that person will interact with the design and the issues that will arise. We start to see things we can't see any other way.
Personas don't automatically get the benefits of preventing grounding, encouraging story telling, and enhancing role playing. They have to be carefully crafted to get those benefits.
To get the benefits, the personas have to have rich, relevant detail. They need to accurately represent the users the team is aiming for. And they need to have a solid foundation in the experiences of real users to be believable and meaningful.
Our research into the usage of personas has taught us that the most successful teams are those that are constantly feeding their persona information. They conduct frequent field studies to understand who the users are and what goals and motivations they have. The teams regularly use usability testing to expand their knowledge of their users. They think of their persona documents as living descriptions—constantly changing as they learn new things from their ongoing research, studies, and design exercises.
Personas are becoming a regular staple in many of the development teams we talk to. The method helps teams make a smooth transition between requirements and design, resulting with much cleaner designs. The benefits of preventing grounding, encouraging story telling, and enhancing role playing are rarely discussed, yet very present when you see the method in full force. It's these benefits that guide our belief that personas will be a trusted method for many years to come.
If you're interested in personas, you'll want to check out Kim Goodwin's UIE Virtual Seminar Designing with Scenarios: Putting Personas to Work. In this seminar, Kim outlines the relationship between personas and scenarios and how to bring them into your design process.
Has your design team created personas? What benefits have you seen? Join the discussion about this week's topic on the UIE Brainsparks blog.
Read related articles: