Agile Glossary

Personas

What is Personas?

When the project calls for it – for instance when user experience is a major factor in project outcomes – the team crafts detailed, synthetic biographies of fictitious users of the future product: these are called “personas”. (In Alan Cooper’s concise terms: “make up pretend users and design for them”.)

Personas are concise and visual; a common layout is a single page including a photograph (from stock shots or magazine cutouts), a name, and social or professional details: “Amanda Jones, 34, press officer at a major food retailing organization, etc.”

As a software product is generally intended for use by more than one category of person, with potentially different preferences and expectations of the product, the team creates one persona for each category it deems important to serve well.

The biographies are displayed in the team room.

Expected Benefits

In a nutshell, personas are an answer to the observation that a designer who tries to please everybody ends up pleasing nobody because too many compromises kill the product’s integrity.

Instead, personas provide designers and developers with an anchor for justifying design choices: rather than appeal to vague notions of “ease of use”, they suggest questions of “what Amanda would do” or “whether Bob will understand” a given feature, interaction, or visual cue.

Because personas are part of the team’s shared assumptions, each team member is made aware of the consequences of design choices. Knowing that the product will be used by “Eileen, 72, retired”, a developer will weigh more accurately the consequences of filling up a modal dialog with 50 tiny dials and settings, which would not necessarily be the case if they thought in terms of “the user”.

Common Pitfalls

Personas should not be confused with other conceptual tools used in defining software requirements or in product marketing:

  • they are not “user roles” (such as sales person, administrator, etc.) primarily defined in terms of tasks or job descriptions; personas put the emphasis on goals and behaviors
  • they are not “market segments” (such as “18-25s who exercise”) primarily defined in terms of demographic attributes; personas are users rather than buyers.

Academic Publications

Two interesting empirical studies examine this practice:

Origins

  • 1999: personas are first described in one chapter of Alan Cooper’s “The Inmates are Running the Asylum”, building on prior work in “Goal-Directed design”
  • 2002: an early practitioner’s report discusses personas within the broader context: Jeff Patton’s “Hitting the Target: Adding Interaction Design to Agile Software Development” is perhaps the first formal description in an Agile context, although the topic has been discussed informally in mailing lists since at least 2000
  • 2008: Alan Cooper’s keynote at Agile 2008 marked a formal reconciliation, of sorts, between Agile discourse and interaction design, which had long been perceived to be at odds; invited by “the Agile leadership” as an “outsider”, Cooper came to be perceived over the following year as very much an “insider”
Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Privacy Preference Center

Not yet a member? Sign up now