Agile Personas

One of the most consistent patterns I see among those integrating UX and Agile is a business-as-usual approach to Personas, i.e. continuing to create them largely in the same way as in a traditional waterfall practice.  Doing so, in my opinion, is a mistake, and reflects a lack of understanding both of the purpose behind Personas and the thinking underlying an Agile practice.

Personas are research artifacts based on real people and real research data that humanize and capture key attributes about archetypal users.  What are their goals?  Preferences?  How do they work? And so on.  They serve both to inform design decisions and, maybe even more importantly, increase designer empathy.  In other words, they are a reminder that these are real people.

So what’s wrong with that?  From a user experience design perspective, what could be more important than to understand your users?  Yes, that is all good and well. The problem with Personas is that they can become an excuse to not work face-to-face with real users.  In a traditional waterfall model, Personas effectively function as a surrogate for being able to interact with flesh-and-blood humans while designing the product. The expectation is that you will spend the majority of your time away from the real users and therefore need something to evoke who they are, so that you don’t fall into the trap designing who you imagine the user to be and not who the user is, or worse, end up designing for yourself. (And don’t get me started on designers who create “Personas” out of thin air based on imaginary users rather from actual research data. At that point, you may be creating a nice reminder that you’re designing for real people, but the persona itself is basically useless or even misleading.)

But in an Agile model, you should be in regular contact with the actual people for which Personas are intended to serve as surrogates.  That means that your approach to creating Personas should shift significantly from how they might be approached in a traditional model.  Depending on how frequently you are in direct contact with actual users, the persona can be correspondingly light-weight.  In other words, if you meet with users every day or every few days, a light-weight persona can contain as little as the person’s first name, a picture of the person in the actual environment in which they will be using the product, and a few bullets re. goals, motivations, and perhaps a “money quote.”  But that’s it.  Anything longer or more detailed, such as this very polished Persona and you’re back in waterfall world, spending more time on designing documents than designing software.

Btw, the name of the persona should be a real name and just a first name, for two reasons.  Referring to someone only by their first name is both more intimate, and also provides that person with a bit of privacy to those outside the project who may see a persona posted on an information wall. Additionally, by having a real name, the name itself becomes a shorthand for the persona, since all you need to do is say their name during team meetings and team members, who in an Agile model all will have met this person, will have a clear image of the persona you are referring to.  In other words, in an Agile model, Personas are…real people!

Being able to glance up at a persona on your information wall to remind you of that real person can be valuable.  A possible downside is that you may end up designing for only the people you are working with and not the archetypal user, but that can be mitigated in a number of ways, such as ensuring that you have a regular cadence of a wide range of users interacting with the working software.

Furthermore, traditional Personas are also based on a sampling of the overall demographic.  And since they often only are created once, as part of a discovery phase, they are effectively a freeze-frame of a real person. But real people are quirky and weird and often inconsistent in their behavior and maybe you caught them on bad day or whatever during the discovery phase.  By working the actual people over time, you get a more normalized version of a traditional persona, one that reflects all of people’s normal fluctuations in character and temperament over time.  An Agile Persona, in other words, can be easily updated throughout the project as you continue to discover new things about your users.

Yes, sometimes you will not have the ability to work face-to-face with actual users, but in those cases I have found lots and lot of pictures of a wide range of users in their normal environment to be far more valuable than text-heavy Personae.  (And I just had to throw that ultra-nerdy plural usage in there at the end…)

15 thoughts on “Agile Personas”

  1. Great post. Text heavy personae don’t work for me – if I can’t get who the person is right away and what they care about, then I can’t decide what to do for them.

    Another thing I notice a lot is the word persona used to describe this kind of abstract, high level customer profile based on a job title, often transcending verticals, pay scales, etc…this seems to allow organization of content or themes for marketing to some degrees but in no way ensures experiences are optimized. Generally I have seen that the experiences are not optimized downstream in the waterfall when this forced abstraction is not exposed to real users or the process is not iterative.

    And I think your nerdy plural usage is simply correct.

  2. I know this is slightly off-beam, but I am very interested in the problems of teams who’re trying to shift themselves from a position of abject ignorance, possibly faced with sceptical management who won’t support any initiative till they’ve seen evidence that it will work.

    … don’t get me started on designers who create “Personas” out of thin air based on imaginary users rather from actual research data. At that point, you may be creating a nice reminder that you’re designing for real people, but the persona itself is basically useless or even misleading

    Fair enough, but what if the developers know that personas have value, but they don’t have access to UX professionals or researchers, whether because of management inertia/ignorance or budgetary problems?

    Are you saying that their amateur efforts are worse than useless, that they are in danger of deluding themselves that they are doing something worthwhile?

  3. Got some great feedback on Twitter: @willsansbury: “Want to agree, but worry about individual bias,” @mojoguzzi (Joe Sokohl): “real person!= archetype. Users!=designers”

    Looking back at my post, I realized it seems to make a point I did not intend to make: that a single real persona can replace a well-crafted Persona. Just like Personas are based on a small but carefully selected sampling of users, so too should Agile teams not be working with just one user, and I don’t think Agile teams are doing that. But after you have done some initial research with that sampling of users, traditional Personas tend to culminate there and sort of get frozen in time. In the Agile model, we have something you simply cannot get from piece of paper: A Living persona, i.e. a Persona seen over a period of time. And by that I do not mean just one person. Yes, you may work with one real user for a few days and then with another real user for a period. One of those real people, in my experience, tends to become an archetypal user, such as Barb who is an archetypal administrative asst. say. When we talk about “Barb” as a team, we both have a clear image of a real person with real needs, but we also understand that Barb is one of many administrative assistants. Additionally, when working software is released, every couple weeks or whatever, it gets used by and received feedback from a much broader group, which normalizes any bias issues.

  4. Hi James – yes, I actually think that creating fake Personas can be worse than useless, since you effectively are fabricating a user, and will then consequently be designing for that imaginary user – few things are worse than designing a product for someone other than the people will be using them.

    But let’s be clear, in an Agile model, it would be difficult for developers who are in contact with real users on a regular basis to do that. If all they are doing is simply collecting pictures and key attributes of the actual people they are in contact with, without necessarily thinking of or approaching them formally as Personas, that is nonetheless likely to still be a valuable document to have as a reference for when actual users are not around.

  5. Hi James, I liked your post. I agree with you that paper-2d-persona is a very waterfall solution… What do you think about using altergames (it simulation games) instead of paper personas? During the game the team ma feel/act as if they were end-users. It is a kind of 3D persona….

  6. Hi James,

    I liked the post because it investigates agile and UX. You are right about not wasting time in developing detailed documents in a fast paced development environment. Who has got time for it?

    However, I am skeptical about using real person as a persona. One downside you already pointed, which is getting biased by one person. The other downside is the name itself. One person on the team may like this “real” persona and other may not. These personal opinion about the real persona may end up in heated arguments and twisted design. Even clients has internal politics, which we regularly face as designers. I would rather stay away from this “real” person. Did you use it in your project? Was it a success?

    The possibility of meeting the end users during the design depends on the project. For example, the project that I lately worked in agile mode barred us to meet end users because of client’s legal issues. All we had to depend on was Client’s SMEs, Market Research, and Best Practices. It was really difficult to work in such a situation. For that project we had to rely solely on fictitious persona based on the marketing data and SMEs input. For every sprint we would quickly walk this persona through the scenarios (functionality).

    As you mentioned, our persona was very light weight with couple of bullet points and it worked well for us.

  7. Hi Anders, Awesome post! I like your suggestions for how to move from the static persona to ones that fit the more dynamic development environment. I feel like I’ve been doing this intuitively and after reading this, I actually have an idea of why and how to make it useful.

    How do you make sure the agile pesona stays light-weight and can “be easily updated throughout the project?” Do you update the goals & motivations, add a new picture, swap something out?

    I use personas to help with storytelling and to remind myself that I have different user groups and not to start blending interviews. Any specific advice for me?

  8. Hi Melissa, Anders,

    I’ve been working on the Agile-persona issue. The way I’ve introduced personas into Agile is by segmenting/dividing/separating the personas by experience (i.e. the buy experience, the help experience, the download experience, etc.). This works well when we segment development by themes.


Comments are closed.