Re: [agile-usability] Who is using multiple personae for one job role?
- On Nov 30, 2006, at 10:44 AM, Desilets, Alain wrote:
> I agree that this comparison is not fair, because I am comparing twoI don't believe that's true in most cases. The "uniformity" always
> nurses working in the same unit, whereas I am comparing two arbitrary
> users of the photo manager. But that's the kind of the point. With
> corporate software, there is an existing structure that groups
> people by
> function, education, and those introduce a minimal amount of
> (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
exists at some level ("we're all made of meat" - http://
www.terrybisson.com/meat.html ), but when you get into the
particulars that will inevitably affect design, you rarely see
uniformity across a role.
Two nurses in the same unit could have substantially different needs
from the CBC Blood Order page. One nurse, new to the unit, primarily
spanish speaking, with tremendous familiarity with computer
technology, but no previous experience with other parts of this
particular system, could have very different design requirements than
another nurse, familiar with the unit's practices and the existing
system, primarily english speaking, and timid with anything but basic
mouse functions. One role, two personas.
Look closely at anything and uniformity disappears. ( http://
> For consumer products, you have to discover these groupings theHaving worked in "consumer products" (which I still think you've
> hard way. All the pre-established categories like Age, geographical
> region, language, revenue, etc... are not likely to be useful by
> themselves for predicting the needs and behaviours of the user
> w.r.t. to
> the system.
misnamed) for a long time, I can tell you that demographic
categories, such as age, geographical region, language, and revenue,
are rarely useful in determining design requirements. (How do wealthy
people use a photo editing tool different than poverty-level folks?)
What we need to look for are factors which determine differences in
behavior, which our design will then need to compensate for.
I have the advantage that I switch frequently between the
environments you claim are distinct. In those travels, I see few
differences in how you approach design. At least, when there are
differences in approaches to design, they don't divide on the lines
> > 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