[an error occurred while processing this directive]

Resources: UPA 2005 Idea Markets

Have Personas Delivered the Goods?

Activator: Mary Sorber, Cisco Systems

The Activator's Introduction

Personas, introduced by Alan Cooper in 1998, are intended to correct misconceptions about users, shorten internal design debates, and improve product quality, among other things. At Friday’s Idea Market, we had a lively discussion of Personas where we shared our experience using Personas and discussed several questions about whether Personas had, in fact, delivered on the promise. The conclusion – yes, for the people who had used them. Surprisingly, Personas were used effectively for general education in addition to their role in driving specific design decisions. Several new practitioners who had not yet used Personas gave input on what would entice them to start – namely more information about the what and how of Personas.

Individual questions are below, with answers from the group. Question 5, on best practices, is the most detailed.

1. What were you hoping to achieve when you created Personas?

  • We created Personas to determine if features meet the needs of the intended audience.
  • We wanted a benchmark or touchstone.
  • Originally I expected nothing, but now I’m a convert.

2. What benefits did you see?

  • Personas get rid of the “I like”. Using Personas it’s not me suggesting this, it’s the Persona.
  • They keep us on track.
  • Pulling out the Personas is good way to stop arguments. They help resolve conflicts. They’re good ammunition.
  • Personas help decide what level of complexity to design to. They help determine the importance of features. They expand the design spectrum so were not developing for a single customer.
  • Customers were impressed with visits by cross-functional teams during Persona creation.
  • They’re good for Sales demos
  • They’re good for internal education.

3. What did you expect that didn’t see? What did you get you didn’t expect?

  • I thought Personas would give me the answers instantly. They didn’t.
  • My developers created parody Personas for fun.

4. What surprised you about the creation process? What disappointed you?

  • I learned not to get into the minutia – knowing which details are relevant to include is challenging.
  • People had strong reactions to the pictures. Some of them thought the pictures were “smarmy”.

5. What best practices do you recommend?

  • Include actionable details
    • Match details to actionable steps.
    • Make them really detailed.
    • Detailed – have picture – we can tell you what she wears to work each day.
    • Getting too real is a problem if you can identify the people the Personas are based on; need to abstract from colleagues in the office to provide anonymity.
  • Research externally, validate internally
    • Base them on Contextual Inquiry data.
    • Credibility comes when Personas are tied to research
    • Have management come along on research; that helps with credibility of the end product
    • Develop based on customer research, not on information from subject matter experts (SMEs). SMEs do have a validation role to play. Also, SMEs could be their own personas for some applications.
    • Based on research. 1 year visiting customers. Validated w/ internal customer-facing people.
  • Give them a long lifespan
    • Don’t change them (1 year life, and still going)
    • Created 5 yrs ago; still valid, new personas developed to fill in when necessary. “Joan” has not changed.
  • Use them for hi-level stuff and education
    • The trick is not to rely on them too much
    • Use for hi-level stuff
    • They’re better as a reflection point of design, rather than the detailed design creation.
    • Recruiting, communicating w/ execs, and in stakeholder discussions
    • New features evaluated in terms of personas – “We’re designing this for Joan”
    • Define primary/secondary personas to resolve conflicting needs.
    • Task flows combined w/ Personas is strong
  • Be creative
    • Post on wall, characteristics on post-its w/ timestamp back to research video.
    • Take to each team meeting (fun idea – give Personas their own chair!)
  • Keep Persona family small
    • 5 main Personas, + ~2 fringe Personas

6. Were your Personas a success, a shipwreck, or something in between?

  • They are very foundational to our work.
  • Success tied to including real relevant details. Customer visits are essential.
  • My clients love them. But do they use them

7. What would convince you to create Personas if you haven’t already?

  • More information on what personas are.
  • Need data on success.
  • Personas are too general / generic. There isn’t always an ideal fit.
  • They’re open to interpretation; what does “impatient” mean?
  • Is information tangential? How far a field do the details go? Do colorful details add benefit?
  • How do you get design decisions out of Personas? How does the information translate?
  • Understand what to use them for. Understand if they’re relevant to me.

Additional Questions

8. Have Personas caused problems?

  • No.
  • They raised expectations beyond what can be executed; they excited the engineers who work in a constrained packaged software environment and therefore can’t execute

9. Open Questions

  • Does the next practitioner believe existing work?
  • How do you balance user needs vs. executives?

10. Are Personas the same as or different from other techniques in sales and/or marketing?

  • This technique comes from marketing.
  • Some of our sales people use our personas.

11. What do you use instead of Personas?

  • Higher level roles (from “Submit now” book). E.g. for music shoppers, create a matrix of product attributes vs. user attribute

12. What is a Persona?

  • Describes goals of user
  • Outlines tasks they do w/ your product in their day
  • Characteristics
  • Caricature
  • Generic stereotype
  • Archetype
  • Based on research


Usability Resources UPA Store UPA Chapters UPA Projects UPA Publications Conferences and Events Membership and Directories About UPA