RE: [agile-usability] Who is using multiple personae for one job role?
> > In fact, you could make the argumentI agree absolutely!
> > that to a large extent, the individual's goals should be the goals
> > that
> > are mandated by the employer through his job description.
> Yes and no. You're not taking into account "gaming effects", such as
> when an employee follows the rules, as specified, to their own
> benefit, in spite of the fact it will have long term negative
> on the organization as a whole. You see this in sales organizations
> where salesmen sell the highest margin (or most incentivized)
> product, instead of the product that will best serve the customer's
> needs. You also see this in performance review objectives that
> benefit the employee at the overall detriment of the organization.
> Sometimes, in the process of design, I've found you need to
> look past
> the "official" doctrine at what people *should* do, not necessarily
> what the policies and job descriptions say they do. Personas should
> reflect this, I think.
Like I said when I first wrote on this thread, I think both User Roles and Personaes are needed, and I think that this holds for both corporate and consumer software. I'm just trying to figure out why it is that people working on large corporate software seem to favour User Roles more, while people working on consumer software seem to favour Personaes more. This btw (corporate favour User Roles, consumer favour Personaes), is not something I know is true for sure. But I have heard Jeff Patton allude to that, and it seems supported by the fact that Larry Constantine who worked mostly on corporate software came up with the concept of User Roles, while Alan Cooper who (judging from the examples he gives in his Inmates book) worked mostly on consumer software came up with the concept of Personaes. Is this something real or just in my imagination?
If this split is something real, then one possible reason for it is that for corporate software, individual differences matter less than the specific role that a particular user is playing in the organisation, and what she needs to do with the system in order to fill that role. That's not to say that individual differences don't matter. It just means they mattter less.
The reason why roles in the organisation might matter more than individual differences, is that the individual differences (at least the ones that matter in terms of their impact on the system) are largely conditioned by the role in the organisation. This is because the organisations selects people with specific training and qualities to fill those roles. For example, if you are developing software for the medical world, you can assume that all nurses have a certain number of years of education, and the same with doctors. You can also assume that they are familiar with medical terminology, and with the use of computers for tracking patient records (well at least for nurses, maybe not doctors). The reason you can assume those things is that the hospital REQUIRES nurses and doctors to have that kind of training and experience.
In contrast, for a consumer product like a photo organiser, you can't make any assumptions about the person's education, familiarity with photography terminology, nor with photo processing software. There is no organisation that screens your users and makes sure they have certain characteristics. Therefore, you might need to focus more on the characteristics of the individual that on the role they play in some organisation, or vis a vis the system.
Alain Désilets, MASc
Agent de recherches/Research Officer
Institut de technologie de l'information du CNRC /
NRC Institute for Information Technology
Tél/Tel (613) 990-2813
Facsimile/télécopieur: (613) 952-7151
Conseil national de recherches Canada, M50, 1200 chemin Montréal,
Ottawa (Ontario) K1A 0R6
National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
Gouvernement du Canada | Government of Canada
> > 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