Back to Basics: Differentiating Personas

Originally published on The Pastry Box April 3, 2015

I work in Big Financial, which means the software that I use, design on, and design for, is generally Big Enterprise. I also work on the company intranet. The Biggest of Big Enterprise Web Design for intranets is, of course, SharePoint, so, well. Yeah.

(Don’t worry, I get to do a lot of other things too. SharePoint isn’t even our primary intranet.)

In my world, virtually any one of over 10,000 people who work in Big Financial can request a SharePoint site, build it out with their own content, strategy, and tactics, then publish it for the other 10,000 people to see. The design quality can be… haphazard.

I’m the Information Architect on call for whenever someone says, “Hey, this SharePoint site, well, it isn’t working as well as we thought….”


The first step I take when a site isn’t working is to ask, “Who is your audience?”

The first answer is always a blank stare, followed by “Everyone.”

I have learned that my business partners find raucous laughter an inappropriate response to that answer.

As designers, we all know that no one can design for “everyone” for the same reason that no one can design for “a normal person”. People are just too diverse in their thoughts, needs, motivations, and expectations for a single thing to satisfy everyone’s needs.

Our goal is not to design for everyone. Our goal is to facilitate the process of discovering who the audiences for the site really are. We lead the research and analysis, so that our business partners (the people asking for help) understand and can engage with their own audience.

This is where personas, fictional characters we create to explore and identify different user types, help us decide exactly who “everyone” really represents (and who it doesn’t).

As Andrew Hinton reminded us in Personas and the Role of Design Documentation, it’s not the output of a written-down persona that makes the difference in our design activities, it’s the exercise in creating them. When we’re successful, we build better designs. We also develop a stronger relationship with our business partners, because we’re all working toward the same goal: satisfy our audience’s needs so our audience in turn satisfies our business needs.

Persona creation is as variable an act as people are diverse. (I bet you’re just shocked.)

On the other hand, I didn’t get labeled “the most process-oriented designer ever” at work by accident.

Here’s my process for getting from “everyone” to 1-3 primary audiences and 5-7 secondary audiences. Your milage may vary. (Still shocked, I know.)

In general, this takes from an hour for very small sites to four one-hour sessions for medium sized or complex sites. We’ve been mapping personas for the whole intranet for, um, ten months now, so “huge” is as expected.

Thing The First: Explain the process

Explain your role as a designer, what personas are, and how the team will use them. (Seriously, I tried skipping this step, it doesn’t work. Explaining the value of a design exercise gives you at least a ten minute head-start before the business folks might think you’re wasting their time.)

Thing The Second: Ask a ton of questions. Take notes.

Ask who the audience is. If they continue to answer “everyone”, name the most ridiculous example that shouldn’t fit as you can come up with. “The cleaning crew?” or “The customer service reps on the phones?” or “the CEO?” or “Me?” or “My dad?”

The goal is to help the team understand that “everyone” is not everyone, even to their stakeholders. (If on the other hand, the cleaning crew ison the list, hey, now you’ve got an interesting business problem. Keep going.) Cracking that nut once usually allows the rest to fragment.

Ask “Who are the most frequent or most important people coming to your site?” Write them down as your first cut of personas.

For each group of people, ask, “Why do they want to come to your site? What’s in it for them?” These are the persona’s goals, and also a list of tasks the site will need to accomplish or information the site needs to provide.

Be attentive and keep your team honest. “They want to come to my site to learn Thing Company Is Cramming Down Their Throat” is probably not true. Thing Company Is Cramming Down Their Throat is a business goal, and likely has to do with saving money, making money, or not getting shut down for legal/ethical/practical reasons.

The corresponding user goal might be “Not get reprimanded because I didn’t know Thing” or “Learn something totally unrelated and trip over Thing”. No user anywhere is excited to come sign the Corporate Communication Policy. They do, however, generally have a vested interest in not getting fired.

For each user group, ask about that group’s experience. Is there a difference between how new users in a group will behave vs people with more experience? Is there a difference between how people new to a job or task behave vs more senior folks? How does age or tenure fit in? Familiarity with the specific software? Familiarity with the topic? An MD who isn’t very tech savvy will have a very different experience on WebMD than a young adult patient who’s extremely tech savvy and has no knowledge of medicine.

If experience or tenure results in different behavior or different needs, split that group into two personas. (The reverse is also true: if the behavior and needs are the same, the user profiles might be wildly different but grouped together.) Sometimes my personas are based on roles or expectations. Sometimes my personas are based on “analytical thinkers” vs “global thinkers”. It depends on the project.

Avoid differentiating by gender, race, religion, ethnic class, accessibility challenges, etc. unless you have quantitatively justifiable user goals or behavior differences to account for. (Personally, I prefer to write my personas to be diverse, with as little out-group homogeneity as possible, so I assign gender, race, and accessibility concerns randomly after discovering the primary needs and goals of the users.)

Ask, “How much of their day is actually about [site topic or task]?” We should have realistic expectations of our personas’ interest levels on the subject. If Adam spends less than 5% of his workday using my tool, I shouldn’t expect him to visit my site six times a day and be in awe of its glory and wonder. If Ellen spends 80% of her time using my tools and forms, I’d better satisfy Ellen’s needs or she can’t do her job.

If the user does the task today, find out how (which is good research for scenarios) and also what their biggest loves and hates of the system are. What existing features would make Adam weep if you wrecked them? What does Ellen wish the system could do?

Find out what our users do with the rest of their time. What are their top priorities at work or at home? For example, the Customer Service Rep’s top priority is handle the calls in the queue as quickly and accurately as possible. It’s all about the numbers. They get really angry if you slow them down with your gorgeous three-minute instructional video. The Knowledge Worker in the next building, on the other hand, may find the video perfectly appropriate for their daily goals and needs.

Ask, “How do they feel?” In cases where emotion is a factor, it’s the most important differentiation between groups. For example, Eric Meyer explains, urgent visits to a hospital website aren’t the same as frequent visits. Designing for crisisis very different than designing for the ideal user in the ideal situation on an ordinary day.

Similarly, designing for someone who is nervous, anxious, afraid, distrustful, or angry is very different from designing for those who are at ease with the topic and the company. Intuit, I think, does a great job of designing for people who are afraid to do their own taxes. If taxes were a ho-hum no-risk topic, the process could be a lot more like a spreadsheet. The anxiety inherent in the topic benefits from calm, friendly handholding, and that’s what Intuit’s TurboTax site provides.

Thing the Third: validate, validate, validate.

By this point in the process, you have groups of user written down, how they feel, what they need, and all kinds of other details about them. You could write a profile or draw a picture of them (and in fact you shortly will), but you probably don’t have validation of this information. You have “gut” and you have business domain knowledge. Lots of groups think this should be enough. They “know” their users… until they find out they don’t.

We are not our users. In some cases we might be a user, but we’re no more our entire user set than we are designing for everyone.

If you don’t validate your personas through user research, you’re not designing, you’re writing fiction. Granted, it may be web-based interactive fiction, but it’s fiction nonetheless. Basing a business case on fiction is a huge risk. As designers, we owe it to our business to take as few huge risks as possible.

If like me you’re lucky enough to work in Enterprise Intranet and have a captive audience of 10,000 people, user research is surprisingly easy to do. Talk to people who are in your user groups directly if you can, and if you can’t, find someone else who can represent them honestly. Ruth Ellison’s Guerilla User & Design Research techniques are fantastic for internal projects or fast, small work with low risks.

If your audience is not a captive audience, the user research is harder, but the payoffs are higher. The size of the intranet’s audience is capped at the size of the company, but the size of the outside world is capped at the current population.

Involve everyone in the design team, especially the business folks who opened the request. It gives the team insight and ownership of their research. It’s easier for the team to become passionate in defending their users from bad experiences when they had coffee and chatted about the latest crazy trade Chip Kelly’s made for the Eagles with said users just yesterday.

Thing the Last: Formalize your deliverables, but don’t put them away

Finally, write your personas. There are plenty of persona templates out on the web, but I’m not going to tell you which one to use because by this point you know your users better than any template can describe. You’ll likely want to invent your own.

If possible, share the formal personas with the folks you worked with for research, to confirm they sound accurate. (Easier in intranet than world wide web!)

At this point you’ll want to start other design steps, like scenarios or capability strategy, if you haven’t already. You know your users. You’re ready. But don’t put that set of personas away. Hang them where the project team can see them. Pull them out midway through developing your other deliverables and ask yourself, “Am I meeting all of Bob’s goals? Did I forget about Amanda’s pain around this process?” Use your personas as references during big design debates. “Bob would hate that! Look, he told us so!”

Lastly, remember what you’ve learned. It’s always a good idea of going through the exercise of researching the audience types you have, but by the third project involving the Customer Service team, you probably have all the quantitative data you need to describe them for the ninth project. Reuse (and re-validate) your persona information on a regular basis where it’s appropriate, and you’ll make design more efficient and more accurate for everyone.