RE: [agile-usability] Who is using multiple personae for one job role?
- Recently, I have come to the conclusion that Roles and Personaes are essentially orthogonal to one another, and that you need both. In particular, you need to look at mutliple personaes acting in the same roles and doing the same tasks.
I came to this conclusion after facilitating an Agile UCD exercise à la Jeff Patton at the XP Ottawa chapter last Summer. In this exercise, we tried to quickly draft a design for an OpenSource Photo Organizer using Business Goals, User Goals, User Roles and User Tasks.
Everything went fine until we got down to prioritising User Tasks to do a Span Plan. When we got there, we realized that we couldn't do that without referring to Personaes.
For examples, we had no difficulty agreeing on roles like PhotoEditor (someone who modifies photos to make them look better) or StoryTeller (someone who uses photos to tell a story about an event or series of events). We had no trouble either agreeing on UserTasks for those UserRoles either.
But when we started trying to prioritize tasks done by a PhotoEditor against tasks done by a StoryTeller, we found we could not agree. The reason was that while everyone was talking about the same UserRoles and UserTasks, we had very different models of the actual people acting in those roles and doing those tasks. For example, some were thinking of a personae which we later called JimTheEagerHobbyPhotographer, while others were imagining more a personae which we eventually called MarthaTheSeventyYearOldGrandma. Obviously, the priorities for Jim and Martha will be quite different. Jim probably puts higher priority on tasks related to PhotoEditing, whereas Martha probably puts higher pirority on tasks related to StoryTelling.
So the only way to agree on prioritization seemed to be to agree on which persona would be our primary target (we never did agree on that btw).
I think this is typical of a situation where one is designing for the consumer market where there will be huge variability in the types of people using the software.
I suspect this is less of an issue with software developed for the corporate world, because there is less variability there. Although, I suspect even there personaes will be useful. For example, while a doctor and a nurse may both act in the role of TreatmentHistoryReviewer, their needs will probably be very different, and so will their context of use (doctors for example may have less patience with slow software than nurses, or maybe the other way around, I don't know).
> > With corporate software, there is an existingI do find that I use personas less often in the
> > structure that groups people by function,
> > education, and those introduce a minimal amount
> > of uniformity (again, I'm not saying that
> > individual differences don't exist within
> > a same work unit... Just saying that there
> > is a bit more uniformity there).
> Look closely at anything and uniformity disappears.
> ( http://
> www.despair.com/individuality.html )
enterprise and more often in the consumer world, but I
would attribute this to the relative "horizontal-ness"
of the system under consideration, rather than the
"enterprise-ness" of system.
When you have a very vertical application in the
enterprise context, roles can go a long way and are
often a good enough model to use--especially when
combined with feedback from actual users.
But when the system is more horizontal--a phone system
perhaps--personas become more useful because the role
"phone user" doesn't get you very far.
I agree with Jared that the closer you look, the less
uniformity you have. Thus "horizontal-ness" is
something of an artificial distinction. If are
motivated to look at any vertically-defined role
closely enough, if you spend enough money and time,
you can make a vertical role as horizontal as you
So what determines "horizontal-ness?" I would argue
that (in terms of deciding whether you use personas as
a design tool) you consider both the intrinsic
differences of behavior and motivation, but also the
extrinsic factors: namely the relative value of
investigating those differences on any given project,
and the relative motivation of the client to pay for