Personas, or archetype users, allow teams to concretely talk about users in specific roles and to understand needs outside the scope of user stories. In an agile environment, you may not have the time or resources to build traditional personas. Instead of eliminating the concept altogether, try a leaner version.

Gathering Data

Personas are typically built based on extensive contextual user research; however, they can be just as effective with low-cost methods such as interviews. A good persona includes at least some information from each of the categories below.

  • Goals: What does the person want to do and why? User stories are a good way to communicate goals and motivations.
  • Workflow: How does the person accomplish his or her goals? Reality maps are one way to show this information.
  • Demographics: What is the person’s age, gender, ethnicity, and employment status?
  • Environment: What are the person’s physical and cultural surroundings?
  • Capabilities: What are the person’s technical skills? Does the person have domain-specific expertise?
  • Attitude: How does the person feel about situations, products, and people? What are his or her values and frustrations?
  • Interactions: How does the person interact with other people, related products, or existing services?

Communicating the Persona

When? The scope of an agile project can change frequently. For example, user stories written for a specific role could move from high to low priority and never make it into development. To avoid waste, try defining personas just in time for when they are needed. If you are holding a planning session for the next group of user stories, take a few minutes at the beginning of the session to define the personas for any new roles specified in those stories.

How? Tell the team a story to make the persona feel real and build empathy. Keep it lean by providing only the essential information from each category in the list above. Provide a visual representation of the persona to make it more accessible. You can use anything from a stock photo, to a picture you took of a user in the field, to a stick figure. Just make sure to include the user’s name and role. Keep the image in a visible place or redraw it when you’re making decisions that will affect users with that role.

An Example

Neil the Product Owner

Here’s an example of a story to share with the team that illustrates the list of important components above. It would be complete with a set of user stories and a reality map.

Neil is a product owner in his 30’s who works at a startup (Demographics). He uses a laptop at a small table near his team and is frequently interrupted by questions from the team and calls from the business owners (Environment). Neil is very comfortable with technology and is an expert in agile development and project management (Capabilities). Neil gets frustrated by a shortage of personnel and quckly-changing priorities, but is extremely dedicated to providing his team with the resources and stability they need to build quality products (Attitude). Neil doesn’t have the budget to buy tools to help manage his team, so he uses a combination of spreadsheets and visual boards in the office (Interactions).

It takes less than five minutes to get the team acquainted with a persona, but this time will help them make more informed decisions and drive a better user experience.


Designing for the Digital Age describes an incredibly thorough process for mapping research data to a quality set of personas. It refers to the concept of Provisional Personas as a lower cost version of this process.