User personas need to be realistic
Not too long ago, I was talking to someone who said that his company didn’t create personas any more. I got the chance to read some of the personas that had been created within the company, and while some were great, the more recent ones were done without the benefit of any research. They read like a Creative Writing 101 project. Based on what I read, I wouldn’t use personas either.
One of the personas I was read was for Savanna (I changed her name to protect innocent personas everywhere). Savanna is a software development team leader. According to the persona write-up, she is a coder because she’s good at it, but she’s a party girl (and goth based on the picture used on the persona write-up). She likes to fly to New York or LA on weekends to party. Savanna believes in elegant code, and hates working with code from 3rd party vendors that isn’t well written. She is very outspoken and recently had the opportunity to speak to the Vice President of Information Technology at one of her employer’s customers (a big name company you’ve heard of), and she told the VP how much the code she had been given sucked, and she asked him if he had as many problems with the quality of the vendor’s product as she did.
So what’s wrong with this? A lot.
A Picture’s Worth a Thousand Words
It’s cliche but true, people draw a lot of information from a picture. The picture I’ve included at the top of this post is similar to the one used for Savanna — except the original appeared to be taken in a club and Savanna was wearing a vinyl mini-dress.
The picture immediately drew my attention, but as I read the rest of the persona it didn’t fit. She looks too young to be a lead software developer, and she certainly doesn’t look like someone any company I know of would put in front an executive at another company.
The picture on a persona is important — it needs to reinforce the message you are trying to get across.
It’s important to take a few minutes and show the picture you are thinking of using to a few people to see if it represents the persona to them.
I once presented a persona for what I thought was a fairly average, middle class, non-technical man to the development team. Throughout the meeting, people kept making comments implying that the persona wasn’t very smart — which wasn’t true. When I asked why people thought he wasn’t very bright, and it turned out the problem was the photo I’d chosen — the way the guy in the picture was wearing a baseball cap made people think he wasn’t that bright. I changed the picture, and never heard those types of comments again.
The Devil’s in the Details
According to Savanna’s write-up, she is a software developer because she is good at it and it’s a flexible job that gives her time for her hobbies. Her bio also tells us that she usually celebrates the end of a project by flying to New York or LA to party the weekend away.
Savanna is also outspoken and had the opportunity to trash talk a vendor to the head of IT at a customer company.
None of this is believable to me. I’ve worked with software developers for 20 years, and have yet to meet one who has the money to fly to New York and LA to party on a regular basis.
I’ve also worked for several software development companies — some of them fairly avant-garde. None of them would have put someone who looks like Savanna, and who regularly shoots off her mouth, in front of a major customer.
I worked on another project where we made a smaller mistake with the details. We had talked to several users who all had post-graduate degrees, and when we created the persona to represent them, we gave him an undergraduate degree from the university that one of our interviewees attended, and a post-graduate degree from a university that another of the interviewees had attended. When the persona was unveiled, a key subject matter expert told everyone at the meeting that he didn’t believe the persona. When we asked him why he said that no one had an education as prestigious as we gave the persona. We had no idea we’d picked the two most prestigious universities for that field of study, but we could have saved ourselves some heartache if we had just previewed the persona with a few key people who understood the target audience.
In Savanna’s case, none of the details I’ve mentioned were relevant to the project, but because they don’t make sense, they make me doubt the entire persona. Which brings me to my next point . . .
Be Relevant
It’s great to give the persona some personality to make them memorable. But the personal details you add should be relevant to the type of user you are representing with your persona. Savanna’s partying means nothing to the project, it’s just distracting — and gives the audience a reason to question the validity of the entire persona.
If your persona’s family situation isn’t relevant, don’t include it. But if you are designing a web site aimed at new mom’s, giving your persona a colicky 3-month-old baby that keeps her sleep deprived and distracted may be important.
Personas Should Target the Project at Hand
Personas should be specific to the project at hand rather than generic catch-alls. Savanna’s job is to build applications incorporating code purchased from various vendors. Savanna’s write up tells us she hates working with sloppy code because it makes her job harder. That’s all it says.
If that is all that needs to be said about this user type then someone should have just said it, and skipped the persona.
The project that Savanna was originally created for was developing an SDK for 3rd party developers. What I would have liked to see in her description is information about how she uses an SDK in her daily work. What does she use? What does she ignore? How does it impact her work? What makes her job easier and what makes it harder? What types of support tools does she need? Where does she want leeway to do her own thing . . . etc. etc.
Use Goal Oriented Personas
One of the most important parts of a persona is the goals. These are the often unarticulated goals that you sense after talking to several members of your target audience. If the design and development team can do things that will help the persona achieve their goals — there is a good chance they have developed a winning product.
One of Savannah’s goals is “to have time for fun.” Good development tools could help her do that — there’s something in this goal that the team might be able to sink their teeth into. But wait for it . . . the goal is followed up with, “Savanna writes software because she’s good at it, and it’s a flexible job allowing her to pursue her various hobbies.”
It sounds like she’s achieved her goal just by having this job. If that’s the case, the goal isn’t relevant to the project. But imagine if the goal had said: “Savanna is always on the lookout for shortcuts that let her complete her work quickly so she can get out of the office and enjoy life.”
Now my mind is churning with possibilities of what I can do for her within the bounds of the project.
Start with Research
The best personas are based on research. Observe and talk to target users. That is where Savanna falls apart. She wasn’t based on research — she was created because personas were an expected deliverable at the time. There wasn’t any money available to go out and interview real end users, so persona creation became a creative writing project.
In Savanna’s case, the company that the persona was created for probably employs 100 developers. A few interviews and a few hours observing people within their own company would likely have lead to the creation of a useful persona without the cost of visiting customers to talk to their developers.
Test Your Personas
I have no idea what, if any, testing Savanna was put through. But I do know that I have learned to test my personas to make sure they accurately represent the people they speak for and that they seem genuine.
Before rolling out personas, show them to people that regularly interact with the target users. This could be salespeople, service people or customer service personnel.
If your reviewers disagree with technical details that your research says is true, (for example they think everyone knows how to change their monitor’s screen resolution when your research shows that your target audience has never done this) you don’t have anything to worry about. But if they tell you other details are off, or the persona doesn’t sound like a real person, you need to make some changes.
One of the ways I know I’ve got a persona right is when people say things like. “I met someone just like the persona at a conference,” or “I was talking to a customer just like the persona last week, and she said. . . ” or “Which company did you say she worked for? I think I met her when I was out visiting company ABC.”
Summary
This is getting to be a very long post. So I’m going to summarize my thoughts here for those of you who got bored and scrolled down to see just how long-winded I can be.
- Base your persona on interviews and time spent observing your target users.
- Make sure the stories your personas tell are project specific.
- Include goals that you teased out of your research, and that your design and development team can help the persona achieve.
- Pay attention to details including the details meant to make the persona memorable and believable. Make sure they support your key message and doesn’t detract from it.
- Pay attention to the photo. It’s more than just a pretty picture, it should represent the demographics and attitudes of your target users.
- Test your personas. Show them to a few people who interact with your target users to ensure they ring true.