Functional Level Personas Was d&d character sheet as a persona model

30 Dec 2008 - 4:35am
5 years ago
7 replies
952 reads
James Page
2008

Jared,

So just after you have got everybody reading about Activity Theory, now you
are getting them to read up about Functionalism :-) So we now have as basis
of design. UCD, SCD, ACD, and now FCD.

Functionalism is an interesting an idea to use for design. see:
http://en.wikipedia.org/wiki/Functionalism_(sociology)<http://en.wikipedia.org/wiki/Functionalism_%28sociology%29>and
I believe it could be a good time to revisit it. Functionalism went
out
of fashion in the 70's because it was viewed as a method that was not
predictive. Functionalism should be a faster method to use compared to
Grounded Theory, if its limitations can be overcome. Malinowski (one of the
founders of Ethnography) used it to analyse his Ethnography of the Trobriand
Islanders. The interesting point with Malinowski and functionalism is that
Malinowski viewed Anthropology as the study of how people related to each
other with objects. The object could be a church, or a fetish, or even a
table. It would be interesting if we look at how his methods could be
related to a computer, or even a virtual object such as software.

I like your idea of using functional Persona, as it then should be easier to
validate against real people. My argument before that Persona is not a valid
method as there is no way to validate if a persona reflects a real person
applies to design-project-wide personas, and may not apply to Functional
Level Personas. This is because the scenarios can be tested if they are real
or not, even if the Personas can't.

It would be useful if you could share some of your scenarios and Personas so
we can try testing the design of them theoretically, and see if they
overcome the challenges with project-wide personas, which I think by your
brief description of them they do.

James

2008/12/28 Jared Spool <jspool at uie.com>

>
> On Dec 27, 2008, at 11:47 PM, Angel Marquez wrote:
>
> I was thinking you would do your research, create personas based on your
>> findings, find their real life equivalents, and use something similar to
>> the
>> character sheets to track their behaviors during usability testing with
>> prototypes etc..
>> THEN
>>
>> Use those stats to fine tune the design while collecting the character
>> types
>> and offering them to the cyber community.
>>
>> It was a fleeting morning coffee thought though...
>>
>
> It's an interesting notion.
>
> I like the idea of tying together with some uniform structure all phases of
> the deliverables, from early design through refinement and launch. At an
> abstract level, I think that's what you're describing.
>
> I'm a big fan of functional-level personas: personas that are created and
> curated with specific functionality in mind. Using this approach, when
> you're designing the print functionality of your product, you'd create and
> use different personas than if you're creating a data-merge capability. This
> way the personas and scenarios are tightly tied to the functionality you're
> focusing on.
>
> I like functional-level personas better than design-project-wide personas
> because it's easier to have them inform the specific design requirements. No
> doubt, they take more time and effort (at least to get started -- over time
> the team creates a substantial library of personas which can be rejuvenated
> for new functionality). I think the initial cost is worth it, but I know a
> lot of folks disagree.
>
> I think in my approach of these lower-level personas, sharing them with the
> cyber community is less valuable, since it's unlikely that they are
> expressed in any applicable form for people not working on the localized
> project.
>
> However, there's a lot to be said for some relative of the DnD character
> sheets to help with the curation of the ever growing library of user
> research data, personas, and their match with the library of patterns and
> components.
>
> Don't give up on this idea. I think there's something to it.
>
> :)
>
> Jared
>
> Jared M. Spool
> User Interface Engineering
> 510 Turnpike St., Suite 102, North Andover, MA 01845
> e: jspool at uie.com p: +1 978 327 5561
> http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

Comments

30 Dec 2008 - 5:54am
Todd Warfel
2003

On Dec 30, 2008, at 4:35 AM, James Page wrote:

> My argument before that Persona is not a valid method as there is no
> way to validate if a persona reflects a real person applies to
> design-project-wide personas, and may not apply to Functional Level
> Personas.

Once we've developed personas, we ask the stakeholders a few questions
to help validate them:
1. Do you recognize a customer you've spoken to, or seen an email from?
2. Can the sales person honestly say "Yeah, I've spoken to that person
on the phone, or had lunch with them?"

It's important the personas are familiar to the stakeholder. The
stakeholder really needs to feel like they can see on of their
existing or target customers in the profile, activities, and behaviors.

Additionally, we pass them back by the people we know, whom we used as
an input source for the personas, to validate them further.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

30 Dec 2008 - 7:36am
James Page
2008

Todd,

You run into the challenge with that the Persona are validated by opinion.
Most Persona I have seen would be statistically imposable to relate back to
a real person. As **Chris Boese discussed before on this list you should not
generalize qualitative data. Or as some Anthropologists would say you run
the risk of a Cargo Cult method. That is the idea that if one builds a
runway in the middle of the Jungle a plane will land on it, and deliver lots
of valuable stuff. If you ask peoples opinion they will say it looks like an
airport, but it isn't and no plane will land on it.

You can use a qualitative method, and you can use quantitative method, you
can use both, but it is important to keep the results separate. Both methods
may help you build a strong basis of evidence for your solution, but they
are separate pieces of evidence.

Jared's Functional Personas as well as Don Normans Throw Away Personas *may
*overcome this challenge of testability, the other solution is to use real
people. If the Persona is a Hypothesis with the output being a scenario. The
scenario is testable against if real people have that particular projected
course of action.

It is important that one applies some robust theory as if one does not it is
possible to run aground rather like what has happened on Wall Street. Where
they used untestable theories that seamed scientific but where not and lost
lots of money. Or you end up like the Highlanders of Papa New Guinea
spending allot of time building perfect airports in the middle of nowhere,
and getting nothing in return.

All the best

James
http://blog.feralabs.com

2008/12/30 Todd Zaki Warfel <lists at toddwarfel.com>

>
> On Dec 30, 2008, at 4:35 AM, James Page wrote:
>
> My argument before that Persona is not a valid method as there is no way to
> validate if a persona reflects a real person applies to design-project-wide
> personas, and may not apply to Functional Level Personas.
>
>
> Once we've developed personas, we ask the stakeholders a few questions to
> help validate them:
> 1. Do you recognize a customer you've spoken to, or seen an email from?
> 2. Can the sales person honestly say "Yeah, I've spoken to that person on
> the phone, or had lunch with them?"
>
> It's important the personas are familiar to the stakeholder. The
> stakeholder really needs to feel like they can see on of their existing or
> target customers in the profile, activities, and behaviors.
>
> Additionally, we pass them back by the people we know, whom we used as an
> input source for the personas, to validate them further.
>
>
> Cheers!
>
> Todd Zaki Warfel
> President, Design Researcher
> Messagefirst | Designing Information. Beautifully
> ----------------------------------
> *Contact Info*
> Voice: (215) 825-7423Email: todd at messagefirst.com
> AIM: twarfel at mac.com
> Blog: http://toddwarfel.com <http://toddwarfel/>
> Twitter: zakiwarfel
> ----------------------------------
> In theory, theory and practice are the same.
> In practice, they are not.
>
>
>
>

30 Dec 2008 - 11:36am
Todd Warfel
2003

On Dec 30, 2008, at 7:36 AM, James Page wrote:

> You run into the challenge with that the Persona are validated by
> opinion.

Actually, if you look at the model I use, it's heavily based on data.
So, they are created from a combination of qualitative (interview and
observation) data and often qualitative (survey) data. We build our
personas off of the data models, which is why we call them Data-driven
Personas.

The validation is initially against the data, which they are
originally based on. We do additional validation by checking with the
stakeholders and the real people we use. So, it's more than mere
opinion.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

31 Dec 2008 - 5:39am
James Page
2008

Todd,

What challenges me in what you say about your Data-driven Personas is best
answered by Chapman and Milham see:-
http://cnchapman.files.wordpress.com/2007/03/chapman-milham-personas-hfes2006-0139-0330.pdf

The key point is "there is essentially no way to generalize from
> a well-specified persona to a population of interest, and thus no way to
> say anything about the users of interest. There is no way to distinguish
> which characteristics of a given persona are indicative of users and which
> are irrelevant

Have a look at the paper and see either if your Data-driven Personas
overcome the challenges that they point out.

All the best

James
http://blog.feralabs.com

2008/12/30 Todd Zaki Warfel <lists at toddwarfel.com>

>
> On Dec 30, 2008, at 7:36 AM, James Page wrote:
>
> You run into the challenge with that the Persona are validated by opinion.
>
>
> Actually, if you look at the model I use, it's heavily based on data. So,
> they are created from a combination of qualitative (interview and
> observation) data and often qualitative (survey) data. We build our personas
> off of the data models, which is why we call them Data-driven Personas.
>
> The validation is initially against the data, which they are originally
> based on. We do additional validation by checking with the stakeholders and
> the real people we use. So, it's more than mere opinion.
>
>
> Cheers!
>
> Todd Zaki Warfel
> President, Design Researcher
> Messagefirst | Designing Information. Beautifully.
> ----------------------------------
> *Contact Info*
> Voice: (215) 825-7423Email: todd at messagefirst.com
> AIM: twarfel at mac.com
> Blog: http://toddwarfel.com <http://toddwarfel/>
> Twitter: zakiwarfel
> ----------------------------------
> In theory, theory and practice are the same.
> In practice, they are not.
>
>
>
>

31 Dec 2008 - 7:24am
Steve Baty
2009

James,

The key point is "there is essentially no way to generalize from
> a well-specified persona to a population of interest, and thus no way to
> say anything about the users of interest.

The process should work in reverse: a persona is a representation of a
specific sub-population derived from the research. From that process, you
should arrive at representations that are illustrative, predictive to some
meaningful extent, and identifiable in the sense that stakeholders should be
able to 'see' in the persona some real person from the population.

The mathematics and statistics in the article you've cited are not very
good, and the arguments presented based on those are specious. They ignore
areas of analysis such as principal components analysis, multi-dimensional
scaling, or factorial analysis; or the basics of clustering and
segmentation. The example of "Patrick" is worse than meaningless.

I find this statement from the article particularly amusing:
"Unfortunately, both personas themselves and the raw data used to develop
them are generally protected by non-disclosure agreements. Without
verifiable data, we have nothing more than assertion of validity by persona
creators and advocates themselves."

I'm not a card-carrying fan of personas. The article cited, however, is
clearly the opposite.

Steve
--
Steve 'Doc' Baty | Principal Consultant | Meld Consulting | P: +61 417 061
292 | E: stevebaty at meld.com.au | Twitter: docbaty

Blog: http://docholdsfourth.blogspot.com
Contributor - UXMatters - www.uxmatters.com
UX Book Club: http://uxbookclub.org/ - Read, discuss, connect.

31 Dec 2008 - 8:44am
Todd Warfel
2003

On Dec 31, 2008, at 5:39 AM, James Page wrote:

> What challenges me in what you say about your Data-driven Personas
> is best answered by Chapman and Milham see:-
> http://cnchapman.files.wordpress.com/2007/03/chapman-milham-personas-hfes2006-0139-0330.pdf

Their opening abstract shows that their lack of experience with real
data-driven personas:

"We believe personas are likely to lead to political conflicts and to
undermine the ability for researchers to resolve questions with data.
We suggest potential research to evaluate the Personas method more
thoroughly. Until the methodological issues are resolved, it is best
not to consider personas to be a means to communicate data.fictional
individuals."

Personas actually avoid political conflicts and are a key artifact to
communicate the data for researchers. So, their assumption, or
abstract is quite mistaken.

They are correct that there is no systematic approach to evaluating
personas, that the industry differs in their approach and attitude
towards personas. This is one of the reasons I started making data-
driven personas. I would agree that we need better rigor with the
approach, however, they seem to be throwing the baby out with the bath
water here.

They also assume that because there are only a handful of personas,
they can't possibly be effective, because some people might fall
through the cracks:

"Given several personas, there is no good way to assess whether the
group of personas appropriately represents the population of interest.
How many users does a given persona describe? How important are those
users for the project? If several personas represent several slices of
the population, how many people fall between those slices?"

Well, that's the point—80/20.

Several years ago, we did research for large grocery store chain. We
studied a few representative markets around the states and found that
people shop grocery stores one of three ways and create lists for
their groceries one of three ways. Over 300,000,000 people in the US
and they all fall into 1 of 3 methods (except for singles, who fall
into their own method, which makes 4 total).

Do some people fall through the cracks? Yes, but that's the point.
You're not designing for 100%. Designing for 100% will ALWAYS fail.
Designing for 80/20 has a much higher degree of success.

I'm a researcher first, designer second. I appreciate and advocate
rigor in research work. But the problem I have with academia's
approach to research is that often times they dismiss anything that
doesn't have 95-99% statistical significance, when frankly, in the
real world, that's rarely realistic or needed.

When you need 95-99% statistical significance, then do it. But know
when you do and don't and act accordingly.

Finally, they have some good suggestions:
* Have some teams create a product w/o using products and others
create the same product w/personas and see which one is more usable
(albeit I would change this to better, because usable is only part of
the equation).
* Give the research data to multiple teams, have them create personas,
and see if they create similar personas.

Based on their paper, my expectation would be that they have very
little actual hands on experience with creating, validating, and using
personas in practice. Their paper is much more theoretical than
practical.

My experience has been much different than what they speculate.
However, that could be due to the amount of rigor we put into our
personas at Messagefirst, the fact that they're data-driven, and that
we continually evaluate and evolve our methods.

The problem with personas isn't personas, it's the lack of knowledge
people have with creating personas based on data. Fix that and we'll
address the theoretical problems discussed in this paper.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

31 Dec 2008 - 9:46am
Jared M. Spool
2003

On Dec 31, 2008, at 7:24 AM, Steve Baty wrote:

> a persona is a representation of a
> specific sub-population derived from the research. From that
> process, you
> should arrive at representations that are illustrative, predictive
> to some
> meaningful extent, and identifiable in the sense that stakeholders
> should be
> able to 'see' in the persona some real person from the population.

I'd go further to suggest that personas aren't really a representation
of populations (or sub-populations): they are vessels to describe
collections of behaviors and the elements driving those behaviors
(intentions, context, knowledge, skills, and experience - as I
described here: http://is.gd/ehca ).

This is why you can't just take outputs of demographic and
psychographic studies and use them as the starting points for the
persona characters. The behavior groupings from personas don't
translate from demo/psycho variables. (Saying that video game players
are 18-24 year-old males doesn't mean every 20 year-old guy loves to
play videos nor does it explain the 44 year-old women who really get
into Halo.)

My push for having personas closer to the specific functionality in
question makes it easier to talk about the behaviors (and less about
the non-behavioral details that sometime emerge when working at a
higher level).

Validation of personas is not impossible. It can be done (more
importantly, validation of the data behind the personas can be done)
through standard resampling techniques, such as bootstrapping or
jackknifing. You can also do it through parallel inferential
development techniques. These techniques are commonly used throughout
the social sciences and have a great track record.

However, I believe validation is a red herring. If designers (or their
overlords) required validation for every inferential technique used in
the research & prototyping stages, all of today's design and
development work would grind to a halt. Personas aren't an alternative
to some yet-to-be-named proven, rigorous method. Personas are an
alternative to shoot-from-the-hip-design (aka making-shit-up-design)
and ego-design (designing for "me") techniques. (And don't get me
started about validation of how marketing, advertising, and sales
budgets are spent in organizations...)

As I've said before (http://is.gd/ehgh), the value from the personas
are not the resulting documents or even the characters as described.
It's the process of the team getting to the personas.

Personas will fail when the team delegates their creation and isn't
involved. Personas will succeed when the team is heavily involved in
their creation. Validation or no validation.

My $0.02.

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool

Syndicate content Get the feed