Pragmatic Personas


The second thing I got hung up on was building the personas based on research that some teams didn't have. We had some direct experience with users, but it wasn't written down in any useful way. It wasn't until I worked with my friend David Hussman that I stopped questioning if I was using personas correctly and started having good team conversations about users. David calls his approach to personas "pragmatic personas," and now so do I.

How to Make Pragmatic Personas
1. Start by Naming Types of Users
When we talk about users of business systems, it's common to list their job titles. When using use cases, we might name users as "actors." Some folks use "user roles" to describe different ways to name users. There's a soup of ways to name people, and they're all right.

Titles name the relationship between a person and something else. A job title names the relationship you have with your employer or profession. "Father" names the relationship I have with my daughters. "Frequent flyer" names the relationship I have with my airlines. It's fun to think about the different ways we refer to people, but don't get caught up in doing it "right."

In your small group, quickly brainstorm types of users for your system. If you've got a bunch of types, then group similar types and rename the group with a new, single term. While there's no right way to name them, looking for names that describe the users' relationships with your product is a good starting point.

For a typical software product, I usually expect to see three to ten types of users. Rank your user types by asking, "If the system were to be successful, which user type(s) is it most critical to please?"

2. Profile a User
Start with one of the critical user types that must be satisfied and add some information. I use the word "profile" to describe lots of general information we could collect about a type of user. Start by profiling quickly with your group, using the information you know. Most folks are surprised by how much they do know, and everyone has some gaps where they need to learn more. Discussing it gets it on the table. Make notes on a whiteboard or flipchart paper while you do this, so everyone in your group can see.

I use the general categories of information below as a starting point for discussion. This isn't a template, so don't trying to fill it out like one. You might find some of this information isn't relevant to your product, and you might discover information you should be discussing that's not listed here.

General stuff about these kinds of people:

  • Number of people of this type: Is it a couple, dozens, hundreds, or thousands? Knowing this helps you get a feel for the impact of your decisions about this user and lets you guess at the diversity of the community.
  • Technology skills: How good are they at using computers and software?
  • Subject matter expertise: If you were a non-profit organization building an application to collect donations, then you might ask how much they know about donating, charitable organizations, or the cause to which they're donating. What subject matter expertise is relevant for your application?
  • Relevant demographics: These are items such as ages, genders, and professions.

About the author

Jeff Patton's picture Jeff Patton

Jeff Patton leads Agile Product Design, a small consultancy that focuses on creating healthy processes that result in products that customers love. Articles, essays, and blog can be found at Information about public classes, including Certified Scrum Training, can be found at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!