{"id":5003291,"date":"2015-12-16T23:30:15","date_gmt":"2015-12-17T07:30:15","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=5003291"},"modified":"2024-08-12T11:11:56","modified_gmt":"2024-08-12T18:11:56","slug":"personas","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/personas\/","title":{"rendered":"Personas"},"content":{"rendered":"<p>When the project calls for it \u2013 for instance when user experience is a major factor in project outcomes \u2013 the team crafts detailed, synthetic biographies of fictitious users of the future product: these are called \u201cpersonas\u201d. (In Alan Cooper\u2019s concise terms: \u201cmake up pretend users and design for them\u201d.)<\/p>\n<p>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: \u201cAmanda Jones, 34, press officer at a major food retailing organization, etc.\u201d<\/p>\n<p>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.<\/p>\n<p>The biographies are displayed in the\u00a0<a href=\"http:\/\/guide.agilealliance.org\/guide\/teamroom.html\">team room<\/a>.<\/p>\n<h2>Expected Benefits<\/h2>\n<p>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\u2019s integrity.<\/p>\n<p>Instead, personas provide designers and developers with an anchor for justifying design choices: rather than appeal to vague notions of \u201cease of use\u201d, they suggest questions of \u201cwhat Amanda would do\u201d or \u201cwhether Bob will understand\u201d a given feature, interaction, or visual cue.<\/p>\n<p>Because personas are part of the team\u2019s shared assumptions, each team member is made aware of the consequences of design choices. Knowing that the product will be used by \u201cEileen, 72, retired\u201d, 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 \u201cthe user\u201d.<\/p>\n<h2>Common Pitfalls<\/h2>\n<p>Personas should not be confused with other conceptual tools used in defining software requirements or in product marketing:<\/p>\n<ul>\n<li>they are not \u201cuser roles\u201d (such as salesperson, administrator, etc.) primarily defined in terms of tasks or job descriptions; personas put the emphasis on goals, behaviors, and <a href=\"https:\/\/personalitytests.com\/what-is-personality\/\">personality<\/a>.<\/li>\n<li>they are not \u201cmarket segments\u201d (such as \u201c18-25s who exercise\u201d) primarily defined in terms of demographic attributes; personas are users rather than buyers.<\/li>\n<\/ul>\n<h2>Academic Publications<\/h2>\n<p>Two interesting empirical studies examine this practice:<\/p>\n<ul>\n<li><a href=\"http:\/\/portal.acm.org\/citation.cfm?id=1043147\">\u201cAn Empirical Study Demonstrating How Different Design Constraints, Project Organization and Contexts Limited the Utility of Personas\u201d<\/a> by Ronkko et al. (2005) is a case study based on three projects, suggesting that ordinary corporate politics might undermine much of the benefits of the practice<\/li>\n<li><a href=\"http:\/\/www.frontend.com\/products-digital-devices\/real-or-imaginary-the-effectiveness-of-using-personas-in-product-design.html\">\u201cReal or Imaginary: The effectiveness of using personas in product design\u201d<\/a>\u00a0by Long (2009) is an experimental study, with a student population, which tends to confirm the benefits of the practice<\/li>\n<\/ul>\n<h2>Origins<\/h2>\n<ul>\n<li>1999: personas are first described in one chapter of Alan Cooper\u2019s\u00a0<a href=\"http:\/\/www.amazon.com\/Inmates-Are-Running-Asylum-Products\/dp\/B001CBPOPM\/\">\u201cThe Inmates are Running the Asylum\u201d<\/a>, building on prior work in \u201cGoal-Directed design\u201d<\/li>\n<li>2002: an early practitioner\u2019s report discusses personas within the broader context: Jeff Patton\u2019s\u00a0<a href=\"http:\/\/dx.doi.org\/10.1145\/604251.604255\">\u201cHitting the Target: Adding Interaction Design to Agile Software Development\u201d<\/a> is perhaps the first formal description in an Agile context, although the topic has been discussed informally in mailing lists since at least 2000<\/li>\n<li>2008: Alan Cooper\u2019s\u00a0<a href=\"http:\/\/www.cooper.com\/journal\/agile2008\/\">keynote at Agile 2008<\/a>\u00a0marked a formal reconciliation, of sorts, between Agile discourse and interaction design, which had long been perceived to be at odds; invited by \u201cthe Agile leadership\u201d as an \u201coutsider\u201d, Cooper came to be perceived over the following year as very much an \u201cinsider\u201d<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Personas are synthetic biographies of fictitious users of the future product. <\/p>\n","protected":false},"author":8027401,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[904],"tags":[],"class_list":["post-5003291","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-business"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003291","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8027401"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=5003291"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003291\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=5003291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=5003291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=5003291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}