Fundamental Elements of Effective User Personas

No Persona

Once all the rage, personas have recently come under scrutiny, as many question their usefulness as a design tool. There is some merit to the notion that personas don’t lend much to the UX design effort, though.

Personas aren’t bad. Most people just don’t know how to create personas that successfully influence their designs.

I’ve been creating personas since before Alan Cooper incorrectly described them in his book “About Face”. Actually, I’m not sure the blame lays solely on his definition or should be shared with the multitude of designers who misinterpreted that definition.

The trouble with personas, as they are created and used these days, is that they fail to capture information that would more accurately guide design decisions.

Most personas I’ve seen are little more than vague descriptions based on useless demographics like marital status, income, geography, number of children, gender, etc. These facets of the customers are fine for marketers but lack the type of descriptive attributes necessary to influence a design effort. How would the gender or income level of your user change your design?

Effective personas are based on attributes that can’t be found by researching simple demographics, nor by simply perusing the Internet. The well-defined persona is born from actual user observations.

I’ve seen cases where entire sets of personas were created without anyone speaking to or observing their actual users. Those were not personas. They were just collections of (mis)assumptions. They didn’t accurately portray real users or contain information that really matters to a UX designer. Moreover, they tended to describe a user as a whole person instead of the different roles a user might assume.

Roles, Not Personas

HatsThinking about your users in terms of the specific roles they assume helps better delineate your personas and avoids incorrectly describing a persona as a single, whole person.

Throughout each day, each of us wears different hats. With each hat, we endeavor to achieve different objectives and bring varying degrees of knowledge to the task.

Describing a persona as a whole person incorrectly assumes that just because a persona is an expert at one task, they are, therefore, an expert at all related tasks. Instead of looking at your users as a single person, describe them more specifically by the roles they assume when performing within separate task domains.

For instance, in ecommerce projects, there are generally three basic user roles:

  • Browsing Betty, who, without any specific objective, ambles through the mall looking at various shops and items.
  • Surgical Sam, who knows exactly what he wants, where it is, how much it costs, etc. Sam has either already shopped around to find the right deal, or is repurchasing a common commodity.
  • Birthday Bob, who has 40 minutes left on his lunch hour and $40 to buy a birthday present for his 6-year-old niece. He doesn’t know what 6-year-olds like or what his niece likes, but he’s got 40 minutes and $40 to find something.

It’s common for users to start out in one role and then switch to another.

For instance, Betty may find a nice pair of pants and then realize that the belt she saw at another store would go perfectly with them. So, she buys the pants and then switches to the Sam role, heading back to buy the belt. Birthday Bob, having previously searched various pet supply sites for the pet food he needs, returns to a site for his natural dog food as Sam, already knowing what product he needs, how much it costs, etc.

Knowledge-Based Personas

brain-scanThe poorly defined persona typically lacks a key attribute, a description of the knowledge base of that persona or role.

Knowing what a user knows going into a task and what they need to know to complete the task identifies the knowledge gap that your design must bridge. Good design is based on bridging that knowledge gap. This is how a well-defined persona influences design decisions.

In order to better influence a design, good personas need to capture four key items:

  1. The task trigger, how they know they need to do something.
  2. Their task goal or desired outcome, how will they know when they are done.
  3. What knowledge or expectations do they already have about the task.
  4. What knowledge will they not have but need to successfully complete the task.

For instance, the following attributes fit Birthday Bob:

  • Has a need, but doesn’t know which specific product to buy.
  • Determining what to buy is the most important objective.
  • Likely to have some mix of knowledge about who to buy for and have a cost expectation.
  • Cost isn’t as important as product fit, ease of shopping, and trust of the brand.
  • Likely to comparison shop on high-level information, then drill down to more detailed comparison data on a selected item.
  • More open to product suggestions – hot items by category, up-sell, sale items, etc.

It also helps to give the persona a catchy name, such as Browsing Betty or Birthday Bob. These names make it easy to reference the persona during design meetings. When designing a page, think about how Bob might use that page, or Betty, or Sam.

The question to ask is, “How will Bob know what to do on this page?” This ensures that the design does not require or depend on knowledge that that persona doesn’t have. It won’t be long before everyone in the company uses those names when referring to a user.

It’s common for designers to add features during design, but asking how that feature helps a persona identifies the real value of a feature and helps avoid adding things that don’t actually help the user. Moreover, bouncing the design off of a persona may indicate that something is missing and suggest a feature that is necessary for the user to succeed at the task.

The Persona-Task Relationship

Persona definitions rely on the task at hand. Most simple websites tend to focus on one task, so this isn’t a big problem. However, more complex websites require additional personas.

You may need a different persona definition with each task. That may seem like a lot of personas, but focusing on the most common users, comprising about 80 percent of the users for that task, typically reduces the number to a manageable few.

As a side note, many marketers are loath to eschew even a few users and want websites that try to appeal to 100 percent of their visitors with a single interface. That’s a known recipe for failure.

Focus on only the most common 80 percent of the users with each interface. If there are two distinct user personas with highly divergent knowledge requirements, then consider two separate interfaces.

As the old saying goes, you can’t be all things to all people. Trying to design for all of the users results in an interface that serves none of the personas well or all of the equally badly.

Trying to appeal to all of the visitors displays a lack of focus and adds a lot of additional design and development effort that rarely pays off. Don’t be greedy!


The fundamental element of any persona is an accurate depiction of the knowledge base of the intended user. A more thorough description of a role helps inform the design efforts so that you more accurately provide the tools and information users need to succeed.

Without that information, how is a persona supposed to guide design decisions? It can’t.

So, before casting aspersions about the value of personas, make sure that the personas are defined accurately.

Remember, personas aren’t bad, but they have been defined badly. Or, in the words of Jessica Rabbit, “I’m not bad, I’m just drawn that way.”

Related reading

Google Sandbox Is it still affecting new sites in 2019
A guide to implementing Google’s “How-to” schema
How progressive web apps positively impact your SEO
Improving your site's SEO by checking duplicate content