Chapter 1. Personas

The bedrock principle of all user experience design is understanding who the users of this particular app really are—not who you wish they were or hope they’ll somehow morph into. Without this knowledge, the UX always gets designed for a user who resembles the developer, which the real users are guaranteed to hate.

It is, however, extremely difficult to grasp the concept of “the user.” That nebulous term wriggles and twists as you try to apply it to specific situations. We need to understand and represent the users of our program in a way that our minds can grasp and absorb. In this chapter, we learn to construct an artificial user called a persona, which makes the user population real to us.

The charity Save the Children figured this out in its marketing years ago: “You can save Maria Pastora for $16 a month. Or you can turn the page.” So did Stalin, with his (probably misattributed) quote: “A single death is a tragedy; a million deaths is a statistic.” When we start designing computer programs, we find that our brains can grasp and understand a specific person far more easily and clearly than the nebulous concept of “the user.”

Let’s prove this with an experiment. Ask yourself, “Is the user going to like this feature?” Now do the same with a specific person: “Is Aunt Millie going to like this feature?” You can feel different parts of your brain lighting up as you contemplate the specific person rather than the vague concept.

If that example doesn’t grab you, try this one. When my daughter started using Facebook, I warned her that if she didn’t carefully lock down her account, anyone in the world could see what she posted there. For my caring wisdom, I got an eye roll and a roar that I can’t transliterate. Seeing that the generality had no effect, I tried a specific example: if she didn’t lock things down tighter than a gnat’s ass, I would be able to see everything that she posted there. That got her attention, and she locked her account down very tightly indeed.

To make our user population understandable to designers and developers, we paradoxically need to boil it down to a specific individual who embodies the characteristics of our group. We do this by creating an artificial person. We call such a construct a persona, from the Latin word for “mask.”

We will then conduct all design discussions in terms of this persona. We will not ask, “Should our app show the time in local or UTC?” or even “Which would the user understand better, local or UTC?” Instead we will use the persona: “Who is in charge of billing? Eva is. Is Eva thinking in terms of local time or UTC? Does Eva even know how to spell UTC? I think Eva would be a whole lot happier with local time.” Again, note the differences in your thoughts as you consider the nebulous case of “the user” as opposed to the specific person, even though the latter is fictional.

Figure 1.1 shows a persona for a genealogy (family tree) app that I worked on once. (I’ve placed this persona and the Microsoft Word template into this book’s downloadable resources for your benefit.)

Figure 1.1 Genealogy app persona.

I always like to start my personas by choosing a name. The name converts the persona from a stranger into someone you know. The first thing you give a new baby is a name; “the baby” doesn’t cut it for long, does it? In addition to being a handle for the person, the name communicates a great deal of information to your subconscious mind, for example, ethnicity (Sunil, Maria, Gurun). More subtly, it places your user in an age bracket: Mary was the most popular name for girls in the United States through about the 1960s, so you will tend to picture anyone named Mary as middle-aged or older. A name also sets the formality of the relationship you want to have with the persona: William Jefferson Blythe III versus Bill Clinton. I’ve given this persona the name Aunt Millie. Ah, feel her settling into your mind.

The genealogy program for which she represents the user population deals with the tracking of family relationships. The title “Aunt” starts you thinking along family lines and also suggests someone a generation older than you. The diminutive name “Millie” suggests informality and also reinforces the suggestion of her relative age. The name “Mildred” peaked in popularity around 1920. You don’t see many Millies walking around today, and any thoughts you have of them will tend to be of older ladies. “Aunt Jennifer” or “Aunt Ashley” suggests a completely different person. See how even the first two words of the persona are communicating with your subconscious mind?

Your persona needs a picture. Your subconscious mind absorbs an enormous amount of information visually via the right side of your brain. Geeks often omit the picture, because they’re left-brain kinds of people. But a persona won’t work if you do that.

Figure 1.2 shows some of the pictures that I’ve used in personas. Notice how much they communicate: the geeky software architect sketching out the system, the puzzled manager who’s in way over his head but unable to retire because his pension isn’t vested, that nasty office accountant who denied reimbursement for your $5 airport cappuccino because you lost the receipt. I don’t have to label them, do I? You know from the pictures who I’m talking about. Aunt Millie’s picture shows an older lady, grandmotherly, smiling nicely—someone you want to help.

Figure 1.2 Example persona photos. (Photos © iStock.com/-MG-, junial, and DRB Images, LLC)

When you create personas to represent the users of mobile apps, you will find that the picture also helps you grasp the context in which that app will be used. Where are the users going to be? What’s going on around them? Who else is in the environment? That’s critical for mobile apps in a way that it isn’t for desktop apps. Figure 1.3 shows some examples.

Figure 1.3 Example persona photos for mobile device apps. (Photos © iStock.com/Susan Chiang, FredFroese, and Anna Bryukhanova)

You can get pictures in many places on the Web. I usually start with iStockPhoto.com. That site has a lot of good pictures for low prices, $10 to $20 apiece, and a decent search engine. Don’t use a photo that you stole that contains a watermark. It looks like hell and you look like a crook, a lazy crook at that. Buy it fair and square, as I (mostly) do.

After the name and picture comes the tagline. This is a short, memorable phrase that sums up the persona in as few words as possible. It’s sort of like a slogan, but more explanatory if possible. “Failure is not an option” is a classic. Aunt Millie expresses herself by saying, “I want to get all of this down for my grandchildren, while I’m still here and have most of my marbles.”

You can tell when you get this basic persona right. Look at Figure 1.4. The picture is world-shaking. The guy’s tagline is a little long, at 54 words, but I let him have that much space because he uses it so well. The name is the only one he could possibly have. Do you have the slightest doubt just what kind of a person this particular user is? Can’t you just predict what he’d like and what he’d hate, what sort of software would work for him (had he lived to become a user of software)? Sure you can. The picture, the name, and the tagline all work together, and it’s a beautiful thing.

Figure 1.4 Name, photo, and tagline working together beautifully.

I asked the client who built the genealogy application mentioned earlier what his user demographics were. He told me that his user population was 75% female. That’s why I chose Aunt Millie instead of Uncle Henry for the persona.

Age is also key to understanding your user population. Almost all programmers and designers are young, since this profession hasn’t been around as long as, say, masonry. They do not automatically understand what their older users need. Older users tend to have worse vision and less precise hand movement. They are not as quick to understand new things. They don’t multitask as well, and they find excess motion confusing. And they tend to have older, less powerful hardware—often their adult children’s castoffs, with tech support provided by their grandchildren.

The user’s age also indicates how long computing has been part of his life. At my parents’ retirement community, all official communication is still done on paper—the menus, the activity schedules, the party announcements; everything. That age cohort didn’t get their first computers until their fifties or sixties, so they never got really comfortable with digital technology. On the other hand, if you’re looking to reach today’s college students, you can reach them only on their smartphones. A Windows PC is something that their parents use for boring stuff like balancing checkbooks.

My genealogy app client told me that 85% of his users were 50 years or older, and 40% were age 70 or older. I guess younger people are more interested in finding a partner with whom to create descendants than they are in writing down their ancestors. I placed Aunt Millie just around the app’s median of 68.

Finally we come to educational level. Developers all have college degrees. Twenty years ago, most users also had college degrees, but today four out of five do not. You need to know what type of educational level to expect in your user population. An app aimed at college grads will not appeal to high school dropouts, and vice versa. Aunt Millie’s high school education, with the secretarial curriculum, is a little bit lower than my client’s customer base. I wanted to make sure that the developers didn’t assume too much on her part.

For Aunt Millie, I included some information about her genealogy, the number of relatives she has in each generation.

Aunt Millie, typical for users of her age, has an old Windows XP PC. She doesn’t see any reason to upgrade. It does what she needs it to do, and she wouldn’t want to spend money improving it. If one of her kids offered her a Windows 7 PC, she might take it. Then again, she has this one set up the way she wants it, so maybe not. No way, nohow would she want the tiles of Windows 8 or 10. And constantly raising her arm to touch the monitor would be hell on her arthritis, so no touchscreen. Windows XP will probably outlast her.

I call this “grokkability,” from the verb “to grok” in Robert Heinlein’s Stranger in a Strange Land. He defines grok as “to understand so thoroughly that the observer becomes a part of the observed. . . .” That’s what we want our persona to help us do with our users.

The grokkability items can be anything that makes sense to you, whichever receptor site your brain finds itself binding to. Following is a selection of some of the things that I’ve seen over the years. Don’t pick too many, perhaps three or four, and don’t spend too long on them. It’s spice, not substance.

Car

Cell phone

Drink

Exercise

Family members

Fears

Goals

Hobbies

Hopes

Last book read

Music player

Music taste

Movie favorites

Political views

Religion

Restaurant

Tablet

TV programs

For Aunt Millie, I put in details about her car, which makes her seem sensible and boring and not especially wealthy. I gave her a hobby, sewing, which reinforces her age and gender cohort. And I gave her a preferred drink of inexpensive wine, suggesting that she’s frugal and not all that interested in “the finer things in life.”

The first is the notion of what other people think about the persona. As Robert Burns yearned (“To a Louse,” 1786), it helps to see the person as someone else would see her. So I include a section entitled “Other People Say.” I often customize it to identify the other person doing the seeing. For a business persona, I might use “Coworkers Say” or “Customers Say.” In Aunt Millie’s case, I’ve made it “Friends Say.” And what her friends say is: “A little spacy. Talks best early in the day. Really proud of her grandchildren.” This tells us she’s older, she’s family oriented, she’s starting to lose it, and her friends are starting to adjust.

My other favorite personality cue is a user’s pet peeve. As Frank Herbert asked in Dune, “What do you despise? By this are you truly known.” If you want to understand someone, understand what he hates. And then put it into the persona, because it really helps you figure out what he’s about. In Aunt Millie’s case, it’s “When the computer does all that stuff that it shouldn’t do.” Do you think that’s vague, that it won’t help you understand and help her? Her very inarticulateness speaks volumes for the kind of person that she is, and the way your program will have to work if you want to satisfy her.

It is extremely difficult to write in this form factor. You need to throw all your ideas onto the page, and then tighten, tighten, tighten. You need to be willing to delete sentences and even entire ideas. That can be difficult, because you fear that you might change your mind and want the deleted items later. This reluctance to delete anything will constipate your thoughts.

Here’s a technique I’ve found for overcoming this block. For each essay you write, keep a separate file that contains the items you remove from the essay. You’ll find it much easier to cut a sentence from the essay if you can paste it into this holder file instead of shredding it completely. I find that I rarely need to bring something back from the removed items file. But the ability to do so eases the initial removal, which is the key point.

Following is Aunt Millie’s personal essay. Note the rambling, the difficulty in concentration, and the lack of what we would call “computer literacy skills.” That’s who this user is, and if you want her business, that’s who you’ll have to please.

Don’t just print it out and put it in a three-ring binder. I’ve seen this done, even done it myself. In today’s electronic world, no one will ever look at it, let alone use it.

You want your persona to sink into your staff’s subconscious minds. That means repetition. A good idea is to make some posters of the same persona, but with different pictures and taglines from the main persona. Most photographers produce multiple photos from a session with a model, so extras should be available without much trouble or expense. Figure 1.5 shows examples of this idea.

Figure 1.5 Additional posters of a persona.

As you’ll see throughout this book, the UX design process is an iterative one. You don’t just write a persona (or any other UX item, as we’ll see in later chapters) and never touch it again. You update it as you gain new insights, adding new items and removing or correcting old ones. If you can change the posters, or at least move them around once in a while, that helps too.

To help this process, it is great if you can dedicate a specific wall space to the persona. You will put all the posters there (in addition to scattering them around), and the full persona write-up, with all the grokkability information and the personal essay. You want it in a location that gets lots of traffic.

You also want some way for passersby to contribute any ideas that the persona evokes, or submit new items that you ought to consider. A stack of sticky notes taped to the wall works well, along with a felt pen for scribbling (tied down so it won’t disappear). Posted thoughts like “Stella’s [military wife persona] husband just got new orders, time to move again” help a persona become real.

When I read this essay to that company’s technical staff, they grokked it immediately. Their chief architect said, “I see that Robert is taking a serious personal risk by using [our thing]. We have to make him feel comfortable with it.” I knew that my persona had done its job.