Do You Know Your Users? - Boxes and Arrows

You think you’re just like everyone else. You think your thoughts, opinions, values, and habits are just the same as other people. Psychology calls this the false consensus bias¹ because we assume much more commonality than reality warrants.

False consensus bias contributes to making bad decisions when we design software.

Alan Cooper noted this type of bias while wondering why otherwise smart, talented people often created such crappy software. He invented the persona-based design methodology to help facilitate insight into a product’s users and remove the designer’s bias. He wrote about the method in his seminal 1998 book, The Inmates are Running the Asylum.²

Have you ever heard anyone on your team say, “what if the customer wanted [some feature]?” Cooper used the term “the elastic user” to reference this shape-shifting, need-changing user who encompasses all edge cases. Good decisions can’t come from elastic users.

Imagine hotel software that is supposed to be suited for a hotel accountant, a front desk agent, and a retail worker in the hotel gift shop. The accountant is heads down in numbers and needs to focus. The front desk agent needs to be able to smoothly switch tasks and be friendly and helpful when guests walk in. And the retail worker may not be in front of a computer at all. Personas can help designers understand the nuances and needs of these different types of workers and create software that fits with their needs.

What are personas? Why use them?

Personas are fictional and archetypal representations of a conglomerate of users that are referenced as a single person. The development, design, and product management team need to feel like the personas are real people. Personas become more vibrant with names, demographic information, a photo, and an expression of the “person’s” job duties, hopes, fears, and goals.

Personas should not be confused with individual people, although some organizations use them that way. It’s better than designing without any user in mind, but by focusing on an individual, the designer will miss designing for a broader set of focused needs. A single persona represents a broad set of attributes and is a container for an entire set of similar users.

Personas are also not market segments. This means they don’t have age ranges or any other characteristics that would never be found in a single person.

Software development always has limitations in time and money. The Pareto Principle,³ or 80/20 rule, says that roughly 80% of the effects of a process came from 20% of the inputs. In UX terms, getting your software features and functionality dialed in for 80% of your users will make them happier than trying to get it right for 100% of them. Personas can be help figure out what’s in the 80% that matters and what’s in the 20% most people won’t care about. This happens by creating empathy with the user via referencing the persona as a real life human being when speaking to stakeholders. You’ll create a shared vision about what your customers need.

How to create personas

How can UX designers create and utilize a persona-based design methodology?

Identify core personas. The audience for personas can end up with cognitive overload if there are too many personas to learn about. George A. Miller⁴ identified 7 +/- 2 as the magic number for how much information people can readily process. And this turns out to be a good number of personas, even for enterprise applications. Software usually has a good number of secondary users, but personas should focus on primaries only.
Preliminary research. Before going into the field, learn about the persona’s job. Interview internal stakeholders. Find some job listings and get an understanding of job duty descriptions, pay ranges, and qualifications. What educational background does the job need? Speak to internal stakeholders and SMEs about their understanding of your personas. See if there are any blogs written by individuals in the roles you’re interested in learning more about. Try to get as immersed as possible before moving on to the next steps.
Field research. Go out into the field. Sit with users. Watch them work. Ask the user to speak as if they were training a new person to do their job. This helps them to speak in an organic way about why they’re doing the things they’re doing.
Interview people. Ask them what keeps them up at night about doing their job. What is the hardest part of their job? What are their favorite parts? What are their aspirations? How do they see their role in the company? How is their work performance evaluated?
Observe. Look at their work environment. Are they heads down? Are they frequently interrupted? How is the noise level? What about lighting? Are they near other people? Do they talk with others and collaborate or keep to themselves? Are they single focused or multi focused? Do they look for help from peers or by searching the internet?
Look for artifacts. Are there sticky notes on their desk or computer monitors? If so, what’s on them? Are they referencing binders of information? These may indicate that their current processes are not well supported by the software they’re using.
Look for patterns. Patterns should emerge after sitting with four or so people with the same job role, across different companies.

Once you start finding patterns, you can start to create a persona.

It can take some fine tuning to get the right amount of persona detail. Too little detail, and the persona will feel flat and lifeless. There needs to be enough detail that the team can imagine knowing this person. It may not matter that a persona has two cats and a 3 year-old daughter, but it may matter that she is 24 years-old, has some college but didn’t graduate, has worked at her company for three years, has basic computer skills, and isn’t sure about her long term career goals.

Persona example

Let’s take an example from the hotel industry with a focus on the front desk. First, identify the kind of people that would fill this role. The persona is derived from the research findings below:

Demographics. Typically female and between the ages of 20-28. She has a high school diploma.
Job responsibilities. The front desk clerk greets guests, checks them into and out of rooms, helps with billing issues, and provides information on local restaurants and attractions.
Soft duties. She must make guests feel welcomed.
Pay. This is an hourly position that pays $9-15/hour.
Needs. To make guests feel welcome, she needs to be able to make eye contact.
Pain points. Her current software uses small text; it’s hard to find things on the screen, and it requires too much of her attention, which makes it harder for her to be welcoming and focus on the guest.
Goals. Her work is primarily judged by customer survey information, so it’s critically important for her to make the guest interactions as pleasant as possible, even when resolving issues or when many guests are queued up.
Aspirations. She would like to go back to college and get a degree in business.
Quote. “I am the face of the hotel and it is my job to make a great first impression on our guests. I need to put the hospitality into hospitality!”

There are many persona templates out there, and designers who are newer to this method may find it hard to know which to use or what bullet points are the most important. Some of that will vary by persona and by industry. For example, a medical doctor persona doesn’t need an explicit statement that the doctor has their M.D. degree. But information about job responsibilities, goals, aspirations, fears, and pain points are likely to be rich sources of information.

There are a few tricks that can help personas be more memorable for the whole team. A quote can help bring vibrancy to the persona or function as a type of personal mission statement for your user. People are also more likely to remember a persona’s name if there is an alliterative first name paired with a job title.

Using personas

Personas come alive by usage. For that to happen, the team needs to get to know them and reference them. If there are more than 5-7, it can be hard for the team to track the cast of characters.

In real life, if you met seven people in an hour, you’d likely have a hard time remembering some of their names or their background. And real life, breathing humans in a room will always feel more vibrant and memorable than a cast of characters that live in a document on a computer. It takes work to breathe life into a persona, and it’s an impossible task when the cast of characters is large.

Aim for stable personas. However, sometimes enough new information comes in from customer research or feedback that indicates the persona set isn’t tracking up well. Changing personas creates a heavy cognitive cost because the team needs to re-align and get to know these characters again. If an existing persona can’t be rolled forward via a storyline—job promotion, change in companies, or the like—consider having a kick-off meeting to introduce changes.

In the 1990s, Cooper recommended putting one-page persona descriptions on the wall—one for each core persona for a product—so the team would see them every day when they walked into the office. Today, many teams are not
co-located and may never even see the same walls, which can create challenges for incorporating personas into the team’s thought processes.

It’s harder to socialize personas when the team isn’t co-located, but it’s not impossible. Some things that can help:

Introduce the personas to the team. Spend time talking about the research that went into them and how they were derived. Show the team the photos; talk about the persona’s needs, wishes, fears, personality, and anything else that may be relevant.
Utilize the personas in requirements meetings. “Would Fiona Front Desk want that feature? I think it might take her away from being able to talk with the hotel guests.”
If you use Agile Scrum, use personas in your user stories. “As Fiona Front Desk, I want to be able to understand, at a glance, which rooms are away from the elevator in order to identify quieter rooms for noise-sensitive guests.”
When designing, take a moment to imagine the design being used in the persona’s work context. Think about the lighting, what might happen when the user is trying to do her job, etc. In our example, consider trying to find a room away from the elevator while focusing on the guest, rather than the software.

In sum, personas help focus design and help people step outside of their own needs and goals and into the hearts and minds of the people who will use the products. This is even more important in enterprise software where the product creators most likely aren’t very similar to the product users. Personas come to life by being used. The more the team references them, the more they become like a living, being user.