Personas vs Business Needs?

How do you use personas? I don't mean how are you supposed
to use them
(Cooper-style or whatever), but how do you *actually* use
them in your
work, if at all?

The reason I ask is that I'm having an interesting time
making sure that
the personas I'm constructing as part of a large discovery
phase
correspond to the client's business needs. This process is
taking me
further than I'd like to from what my user research is
telling me, and
I'm worried that the value of the whole exercise will
degenerate into
selectively justifying foregone conclusions.

Personally, I use personas as a means of arriving at design
directions.
They are necessarily vague, and journeys constructed using
them are not
supposed to document the system's features. Usually, a
brief explanation
of this is enough to keep a client from wanting the personas
to answer
all the design questions, but sometimes it's not.

I'd be interested to hear whether others have hit
real-world problems
around the use of personas on projects.

Jonathan




____________________________________________________________
_________
This e-mail has been scanned for viruses by MessageLabs.

------------
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments

Searchable Archive at http://www.in
fo-arch.org/lists/sigia-l/

Most presentations/papers and posters have been loaded to
the IA Summit 06 website:

http:/
/iasummit.org/2006/conferencedescrip.htm
http://iasummit.
org/2006/posters.htm



________________________________________
Sigia-l mailing list -- post to: Sigia-lasis.org
Changes to subscription: http://
mail.asis.org/mailman/listinfo/sigia-l

Jonathan,

Personas aren't about business needs, they're about the
customer's  
behaviors, goals, wants, and needs (at least that's how we
use them).

I think what you're asking, or should be asking is how do
you match  
up Business goals with Customer behaviors, goals, wants, and
needs.

We use something called a task analysis grid. It's a large
matrix,  
based on data from our initial research and personas, that
outlines  
all the tasks and steps involved in completing a task that a
customer  
would go through in using a product. For instance, if
you're going to  
sign up for web hosting service, it outlines your initial
comparison  
shopping, how you make your decision, how you sign up and
how you  
would setup your hosting service (including confirmation and
welcome  
emails sent by the service provider).

To us, it's a pretty simple artifact, but to our clients,
it's often  
been the silver bullet. Each item is color-coded and
prioritized from  
1 (must haves) to 4 (sometime in the future). Those
prioritizations  
come from discussions with the business unit and are framed
around  
the Customer and Business needs. So, if it's a 1, it's
because both  
the customer and business unit think we have to have it. If
it's a 2  
(We really want it, but if something has to slip before
launch,  
that's one that gets cut) then the Business has decided
that we can  
live w/o it (either it wasn't critical to the business or
the  
customer, or possibly either/both).

The nice thing is that this shows the big picture for a
project (what  
is involved if we build the entire thing) as well as what's
in for  
right now (the no. 1s). One of our clients described it as
"You've  
just distilled our 60 page requirements document into one
page."

I can send you an example if you'd like, just let me know.

On Jul 19, 2006, at 7:57 AM, Jonathan Baker-Bates wrote:

> How do you use personas? I don't mean how are you
supposed to use  
> them (Cooper-style or whatever), but how do you
*actually* use them  
> in your work, if at all?
> [...]
>
> Personally, I use personas as a means of arriving at
design  
> directions. They are necessarily vague, and journeys
constructed  
> using them are not supposed to document the system's
features.  
> Usually, a brief explanation of this is enough to keep
a client  
> from wanting the personas to answer all the design
questions, but  
> sometimes it's not.
>
> I'd be interested to hear whether others have hit
real-world  
> problems around the use of personas on projects.
>
> Jonathan

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | designing and usability consulting
--------------------------------------
Contact Info
Voice:    (607) 339-9640
Email:    toddmessagefirst.com
AIM:       twarfelmac.com
Blog:      http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.


------------
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments

Searchable Archive at http://www.in
fo-arch.org/lists/sigia-l/

Most presentations/papers and posters have been loaded to
the IA Summit 06 website:

http:/
/iasummit.org/2006/conferencedescrip.htm
http://iasummit.
org/2006/posters.htm



________________________________________
Sigia-l mailing list -- post to: Sigia-lasis.org
Changes to subscription: http://
mail.asis.org/mailman/listinfo/sigia-l

Jonathan Baker-Bates:

> How do you use personas?

Only when I want to look hip. 

Substitute "personas" with "usage
patterns" (either field-observed or
conjectured) you'd arrive at an unpretentious design
practice. Reduced to
its essence, not all potential usage patterns can be within
the business
scope of a design. Usage patterns are at least a level of
abstraction above
a collection of features.

For example, many Microsoft apps, like Office, are a flat,
horizontal
aggregation of features. Indeed, features are the app. Many
Apple apps, on
the other hand, are vertically focused along certain usage
patterns, at the
expense of "missing" many features. If users fit
one of those small set of
usage patterns they are generally very happy with Apple
apps. If they don't,
like gearheads, they'll end up incessantly complaining
about various
"missing" features.

I don't believe in designing by feature matrices. Users
don't forage for
features, they try to accomplish their goals. Feature
matrices can easily
lead to unfocused app design. (Microsoft has admitted that
the vast majority
of help calls it gets is about feature requests that are
*already* in the
app.) 

I design workflows. When I start I don't think about
features. I literally
try to discern flows of interaction, getting things done,
moving from input
to outcome, etc. Those give me usage patterns, and the
discipline to
streamline the design.

----
Ziya

"Innovate as a last resort."



------------
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments

Searchable Archive at http://www.in
fo-arch.org/lists/sigia-l/

Most presentations/papers and posters have been loaded to
the IA Summit 06 website:

http:/
/iasummit.org/2006/conferencedescrip.htm
http://iasummit.
org/2006/posters.htm



________________________________________
Sigia-l mailing list -- post to: Sigia-lasis.org
Changes to subscription: http://
mail.asis.org/mailman/listinfo/sigia-l