Examples where personas are *not* useful

13 Nov 2007 - 3:19pm
6 years ago
138 replies
3833 reads
oliver green
2006

Hi everyone,

I am trying to understand the finer nuances of using personas. The
various articles/book chapters that I have read talk about instances
where using personas would be useful. But I feel that to really
understand a methodology, one should be familiar with the weaknesses
as well. So, can you give me examples where using personas would not
be advisable/helpful?

Thanks,
Oliver

Comments

17 Nov 2007 - 11:58am
Andrei Herasimchuk
2004

On Nov 17, 2007, at 7:04 AM, Todd Zaki Warfel wrote:

> On Nov 16, 2007, at 5:13 PM, Jared M. Spool wrote:
>
>> One could just as easily argue that Dreyfuss's 17-page example is
>> excessive. If he can't do it in 2 pages, then no one will ever pay
>> attention to him. But, they don't, because that's just crap too.
>
> No kidding. 17 pages is excessive. Talk about something that a
> client would never actually use. If we can't do it on 1-2 pages,
> then in most cases it's an artifact that's not going to work.

Once again... it's *NOT* 17 pages. It's a chapter in a book that
describe getting to know your customers, and the chapter is 17 pages.
Inside the chapter are all sorts of diagrams, posters and design
deliverables that do a damn good job of giving designers data and
information that can inform their work far better than the report
format most people use to disseminate personas.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

17 Nov 2007 - 10:15am
Ron Perkins
2007

----- Original Message -----
From: "Jeff Patton" <jpatton at acm.org>
To: "'Jared M. Spool'" <jspool at uie.com>; "'Todd Zaki Warfel'"
<lists at toddwarfel.com>
Cc: "'Jeff White'" <jwhite31 at gmail.com>; "'ixd-discussion'"
<discuss at ixdg.org>
Sent: Saturday, November 17, 2007 5:40 AM
Subject: Re: [IxDA Discuss] Examples where personas are *not* useful

Jeff, I agree 100%. But looking at the title, I'm thinking that my example
below is a case where personas were useful, but they were not the extensive
data gathering type that Jared mentioned.

As a consultant, I can't get clients to buy in to do quantitative surveys of
their customers to form the basis of personas. If they did, I'd call that a
customer profile, not a persona anyway, and it would be totally subject to
the survey creators questions, and possibly not cover all aspects of
customer experience.

On a recent project, I had the designers create 4 personas based on their
experience with customers, representing the spectrum of customer types and
use cases. They put them up on the wall in the conference room where we
met. These were based on a number of customer visits, (another difficult
idea to sell) so they were not totally fabricated so they knew from
firsthand experience watching customers. This I think made a big
difference.

I knew that it was successful when the designers and others in the meeting
room constantly referred to the wall posted personas by name when arguing
their points, so the arguments were much more constructive and everyone had
a shared view of the customer. I think that was much more powerful than
whether details based on survey data might have informed the emerging
design.

So I agree with you that any assumptions, as long as they are shared, are a
good starting point for design.

>>Finally, I find that even a crappy pile of assumptions we all agree to use
as a common design target is better than no design target - or the disparate
assumptions a group of designers and developers carry around in their head
and don't have any easy way to share.

Ron Perkins,
Principal, www.designperspectives.com

17 Nov 2007 - 12:33pm
Andrei Herasimchuk
2004

On Nov 17, 2007, at 8:01 AM, Jared M. Spool wrote:

> With that criteria, why are you picking on personas? Practically
> every modern design technique falls into this distinction,
> including user-centered design and agile methods. There are no
> 'industry-standard practices', short of build-it-and-ship-it.

1. I'm an equal opportunity curmudgeon in case you haven't noticed.
If you want to bring up a topic or practice that I find something
lacking with, I'm sure I'll pipe in there as well.

2. "Personas" are something the ID world has fairly well established
as a general practice. The way they use this data and do the research
and how it gets implemented is useful information to see how the high-
tech world can do the same since we aren't doing it as well as they
are. So in that sense, I'm picking on them because they are highly
successful in other design practices.

To circle back a little then, I could say the same thing about
prototypes. Part of the reason I get agitated about the topic on this
list is because hi-fi prototyping is such a general practice in every
other major design profession but ours and that upsets me.

> What we've found is, while 'personas' are used throughout the
> entire spectrum, what we call 'robust personas' are typical in
> projects on the higher end of our success scale. These teams are
> using these techniques to inform their design process and producing
> great designs as a result.

I don't doubt that. I use these similar methods where I employ
feedback from users through the entire design cycle, start to middle
to end. Of course that kind of methodology works. More feedback and
more data is always better for designers to make more informed
decisions.

> Robert is correct in that it's mostly about insights. But the
> insights aren't delivered by the persona description document. The
> insights come from the process in its entirety. (As an aside, in
> our work, we think personas are more than for insights, because the
> team may need them just to confirm hunches and beliefs they already
> have. If the team designs a quality experience without gaining new
> insights from the persona creation process, we still consider it
> successful.)

Which then limits the usefulness of them to the select few who have
been involved in the process itself. Don't you think it would be
useful to try and break that and make it work on a larger scale and
so that not everyone has to invest all of their time in this process?

> Yet, we've found many teams, like Robert, believe personas *are*
> just a report format. Teams that believe this, in our research,
> rarely succeed at designing great experiences for their users.
> (Similarly, they often believe requirements documents, market
> statements, and other written deliverables are just report formats
> too and fail to get the potential value from those deliverables too.)

So why is this the case? Certain people on this list need to stop
defending the persona process itself and start figuring out why they
are done the way they are in our industry. And I assert a core part
of why they are done poorly or improperly is the "report" or
deliverable format. I have no data or research to back that up, just
my personal experience on many large scale software products where
people substitute the persona document for a larger process that
needs to integrate customers into the feedback loop of the design
process itself.

> We can be in agreement here: poorly-done personas don't add much to
> the process and eat up a lot of otherwise useful resources.
>
> We recommend to our clients avoid investing in poorly-done
> personas. If they can make the investment (and it's not a huge
> one), we recommend a robust persona creation technique. If they
> can't afford that investment, we recommend other techniques.

That's fine. So do I. At the same time, don't you think it would
behoove our industry to figure out why personas have become
potentially bastardized?

> Someday, I hope you have the opportunity to work on a project that
> employs robust personas. I'm betting you'll see their utility at
> that point. If I'm wrong, then I look forward to learning from
> your story of your experiences.

I don't use "personas" the way you do. I prefer to avoid turning
people into reports. (And largely because in watching others
bastardize personas, I find the process often does more harm than
good.) I use real people and customers through the entire design
process. I show them early concepts, get their feedback all the way
through, iterate and show them more, then get them in front of
prototypes, etc. That's just my thing. I prefer the human element all
the way through the design process if I'm allowed to do it. And when
not allowed due to time or budget, I'll still find ways to do it.

But personas can have their place if done properly. Again, it's my
opinion that the "report" format is crushing the process. And the
report format is not providing designers the tools they need to make
more informed decisions. Just like engineers ignore specs when the
document is written in a way they find less than useful, designers
tend ignore personas for the same reasons I think. It's simply not a
deliverable that helps them. And sure, if they went through the
research, that's fine, but it's simply impractical to ask companies
to send 20 person design teams on a research project. 2-5 is often
the most anyone can afford, even large companies like Microsoft and
Adobe. If that is the case, it is my opinion that the deliverable is
*vital* to the success of the entire process.

Especially if it is to become industry practice.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

17 Nov 2007 - 12:57pm
Jared M. Spool
2003

On Nov 17, 2007, at 12:33 PM, Andrei Herasimchuk wrote:

> And sure, if they went through the
> research, that's fine, but it's simply impractical to ask companies
> to send 20 person design teams on a research project. 2-5 is often
> the most anyone can afford, even large companies like Microsoft and
> Adobe. If that is the case, it is my opinion that the deliverable is
> *vital* to the success of the entire process.

It's funny, because the same companies won't think twice about
sending 400 salespeople to a week of golfing in Palm Springs under
the guise of a sales meeting.

In fact, I was just at the Adobe MAX conference where they had 1600
employees on what I estimated to be about a $8 million event.

So, I'm thinking they could take 1% of that budget and put it towards
decent customer research, they'd see huge improvements.

Oh, and by the way, companies like Intuit *do* send their entire
engineering departments on that kind of research regularly. So, it is
proven to be practical.

:)

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

17 Nov 2007 - 4:02pm
liyazheng
2005

If it's too cute, then just stop at the behavior patterns. Give each pattern a name and call it a day. Don't do anything you can't use.

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com on behalf of Todd Zaki Warfel
Sent: Sat 11/17/2007 10:13 AM
To: Robert Barlow-Busch
Cc: ixd-discussion
Subject: Re: [IxDA Discuss] Examples where personas are *not* useful

Then change it.

On Nov 16, 2007, at 8:46 PM, Robert Barlow-Busch wrote:

> I think Andrei's entirely correct with this suggestion. The format of
> personas is so... well, it's just so CUTE. Not surprisingly, a lot
> of people
> can't get past this fact.

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
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

________________________________________________________________
*Come to IxDA Interaction08 | Savannah*
February 8-10, 2008 in Savannah, GA, USA
Register today: http://interaction08.ixda.org/

________________________________________________________________
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

17 Nov 2007 - 4:44pm
David Walker
2007

This is very true. It also happens with marketing and political campaign
personas: witness how the media keyed on "Susie the Soccer Mom" from Bill
Clinton's first election campaign.

The cuteness factor needs to be addressed, especially in corporate cultures
where <fun> acts as a discount inside conference rooms.

19 Nov 2007 - 10:26am
White, Jeff
2007

I never really thought the "cuteness" thing was an issue at all. I
thought the writing style of the persona is much more of a roadblock.
I've looked at the example from Chopsticker 4-5 times (it was posted
in another previous thread as well) and I've never had the attention
span to read the whole thing. It's a bunch of long paragraphs, and
that's what makes it hard to digest, IMO.

Also, how relevant is the information? What design decision would you
make based on the following information from the persona?

"He doesn't suffer fools, just as he won't put up with anything that
stands in the way of getting his job done."

I realize part of the perceived value of personas is the narrative. I
do think, as someone in this thread suggested, that formatting the
data in more of an outline format - headings, bullets, etc - removing
some fluff, would go a long way towards getting people to actually
consume the data.

If I'm expected to constantly refer back to a document when I'm
designing something, then don't format the thing so it takes 10
minutes to read, and you have to sift through long paragraphs of
content to find valuable info.

The two goals at the very beginning and the chunks of data below
Timothy's picture on the first page were the most valuable things to
me - it took me 30 seconds to digest that information. But then again,
I haven't read the whole thing :-)

I'm not trying to be harsh towards the creator of the Chopsticker
persona, I think the persona has many strengths, but also areas for
improvement.

Jeff

On Nov 17, 2007 4:44 PM, David Walker <davewalker at interfacevisuals.com> wrote:
> This is very true. It also happens with marketing and political campaign
> personas: witness how the media keyed on "Susie the Soccer Mom" from Bill
> Clinton's first election campaign.
>
> The cuteness factor needs to be addressed, especially in corporate cultures
> where <fun> acts as a discount inside conference rooms.
>
> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Robert
> Barlow-Busch
> Sent: Friday, November 16, 2007 5:46 PM
> To: ixd-discussion
> Subject: Re: [IxDA Discuss] Examples where personas are *not* useful
>
>
> > I would suggest to those that make persona deliverables that the
> > format, the template and the deliverable is a core reason why
> > personas are having trouble being adopted properly at more places.
>
> I think Andrei's entirely correct with this suggestion. The format of
> personas is so... well, it's just so CUTE. Not surprisingly, a lot of people
> can't get past this fact.
>
> "Oh, wook at the wittle customers. Dey're so cuuuuute! Who's dat big boy?
> Who's dat big girl? Ah, wook at the pictures. Oh! Dey even have *names*!"
>
> This throws up barriers to adoption. Which is unfortunate, because much of
> the power of personas comes from our ability to process character and
> narrative; we're hard-wired to respond to that stuff. Scenarios address half
> the equation by introducing narrative, but they're more easily accepted in a
> business context because they aren't cute.
>
> --
> Robert Barlow-Busch
> http://www.chopsticker.com
>
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> 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
>
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> 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
>

19 Nov 2007 - 11:15am
Becubed
2004

> Yet, we've found many teams, like Robert, believe personas *are*
> just a report format. Teams that believe this, in our research,
> rarely succeed at designing great experiences for their users.

Quick clarification here on my position: the persona *artifact* is a report
format. The persona *process* is where the real value lies because it
generates useful information. These two are often conflated.

People sometimes get excited to try personas, then wonder why nothing good
comes of the artifact they produce. Typically it's because they're focused
more on the artifact than on the *information* it needs to contain. So you
end up with a shallow or overly-cute description of the annoying "soccer
mom" who makes $60K/year and drives an old Volvo -- and who cares, because
that's just not helpful.

IMHO, the persona *artifact* is valuable mainly for these reasons:

- it reminds designers of what they know about the product users

- it's an engaging format to help spread information across a wider team

- it helps to surface different beliefs that people might hold about the
product users

--
Robert Barlow-Busch
http://www.chopsticker.com

19 Nov 2007 - 11:27am
Todd Warfel
2003

On Nov 19, 2007, at 10:26 AM, Jeff White wrote:

> I realize part of the perceived value of personas is the narrative.
> I do think, as someone in this thread suggested, that formatting the
> data in more of an outline format - headings, bullets, etc -
> removing some fluff, would go a long way towards getting people to
> actually consume the data.

I think this is where people often get confused. One of the values of
a persona is the ability to use them to tell a narrative. That doesn't
mean you have to have the entire narrative spelled out in front of you.

The primary goal of a persona is to assist in making informed design
decisions. One of the ways we communicate those details of a persona,
when we're presenting them, is through a narrative. If you've ever
been through a debriefing on an ethnographic-based study, it's all
about the stories. So, we use these personas to tell the story of the
user/customer/participant.

As I've said before, our persona model has evolved over the years (the
current model can be seen at http://www.slideshare.net/toddwarfel/data-driven-design-research-personas
slide 27). We try and create a balance between the narrative and
presenting information in a more consumable decision making format.
There are three main parts to our personas:
1. The day in the life narrative—we try and keep this to a few
paragraphs max. It should provide an overview of how this person uses
the product/service, or how they try and accomplish related tasks in
other products/services is the product/service we're working on
doesn't actually exist yet.
2. The persona DNA—this is a mapping of knowledge, activities and
behaviors, and a product life cycle usage timeline. We're attempting
to map the first two segments (knowledge and activities & behaviors)
on a 1-5 scale, where 1 is less knowledge/activity and 5 is the
highest knowledge/activity present. This enables us to see what's
important, what's not important, and what we can leverage from past
experience/knowledge from this person when designing.
3. Descriptors—don't really have a good name for this section, but
it's basically a bullet point listing of things like Goals,
Influencers, Frustrations and Pain Points, Questions, Other
Applications/Sites. This is where we list out specific items that can
easily be scanned.

The point is that personas as a design tool aren't as effective when
just in narrative format. Designers don't want to read 4 pages of text
to find out what they need to know. They need to be able to see one
page with a list of bullets that says "Here's everything you need to
think about when designing for Susan." This is what we've found from
both our personas and usability reports. In our written reports, they
want a list of bullet points—let someone else read the long winded
descriptions. They don't have time, nor do they want to take time to
read a novel. Cliff notes!

And I have to say, that once we started taking this approach, it made
it more effective for management and even ourselves.

I'm with Jeff on this one—they don't need to be more than they need to
be to get the job done. After all, what's the point in writing a 7
page persona if it ends up not being used because the end customer
finds it too much of a bother? Think about the consumer of the product—
design your artifacts accordingly.

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
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

19 Nov 2007 - 11:40am
Mark Schraad
2006

Very nice presentation. -Mark

On Monday, November 19, 2007, at 11:28AM, "Todd Zaki Warfel" <lists at toddwarfel.com> wrote:

>As I've said before, our persona model has evolved over the years (the
>current model can be seen at http://www.slideshare.net/toddwarfel/data-driven-design-research-personas
> slide 27).

19 Nov 2007 - 11:43am
Jared M. Spool
2003

On Nov 19, 2007, at 10:26 AM, Jeff White wrote:

> Also, how relevant is the information? What design decision would you
> make based on the following information from the persona?
>
> "He doesn't suffer fools, just as he won't put up with anything that
> stands in the way of getting his job done."
>
> I realize part of the perceived value of personas is the narrative. I
> do think, as someone in this thread suggested, that formatting the
> data in more of an outline format - headings, bullets, etc - removing
> some fluff, would go a long way towards getting people to actually
> consume the data.
>
> If I'm expected to constantly refer back to a document when I'm
> designing something, then don't format the thing so it takes 10
> minutes to read, and you have to sift through long paragraphs of
> content to find valuable info.

When building personas, we recommend to our clients they build two
versions: (1) a narrative 2-page description and (2) a short
reference-card version (one flap of a tri-fold, so you can get 3
personas on the same page).

The bullets are useful for outlining the distinguishing elements of a
given persona (what makes this person different from others?).
However, the narrative is also important because, since the point of
the persona creation process is to make these people as real as
possible, stories do a better job of creating real characters in our
minds than lists of bullets.

When we guide our clients on how to build the narratives, we tell
them that every sentence should have a clear implication on the
design. The sentence you quoted:

> "He doesn't suffer fools, just as he won't put up with anything that
> stands in the way of getting his job done."

doesn't really meet that criteria, since it's not clear how this will
impact the design, other than to say it needs to be efficient in its
communication. (It implies a High-D personality, if you're familiar
with the DiSC model.) There are probably better ways to state this
where the implication is clearer.

Recently, I was showed a persona from a client with this text:

> Amy lives with her boyfriend Tom in a two-bedroom apartment with
> his French bulldog Milo. She moved into his place last year right
> after they got engaged. They're not calling the new arrangement a
> trial, but they know that living together will test their
> relationship and say a lot about their compatibility.

At first glance, this seems also to be frivolous. Why do we care
about when she moved in or what the dog's name is?

However, this is for an application in the home improvement market
(can't say any more). The tenuousness of the relationship, the fact
that improvement projects and supplies need to be pet-friendly, and
the fact that it's not *her* apartment does dictate her attitudes
towards improvement projects.

For example, later in the description is this sentence: "Knowing that
the apartment is transitional prevents her from getting too caught up
in all the things she hates about it: the leaky faucet, the
particleboard and laminate cabinets in the kitchen, and the white
walls throughout." A designer of a home improvement resource could
easily imagine providing Amy with resources to help her make quick,
inexpensive, and potentially movable fixes to her temporary living
space.

One could put this type of content into bullets:

+ Recently engaged
+ Lives in boyfriend's apartment
+ Doesn't make changes because they will move soon

You can decide which one helps you better internalize the character,
such that you can role play Amy's life and decision making processes.

When done well (and it always come down to the quality of the
process), the narrative can be a very powerful for many people.

Jared

19 Nov 2007 - 11:56am
Becubed
2004

> I've looked at the example from Chopsticker 4-5 times (it was posted
> in another previous thread as well) and I've never had the attention
> span to read the whole thing.

I strongly believe that a persona *requires* narrative -- much of a
persona's power lies in its ability to create a sense of character, and
story/narrative is the best (perhaps only?) way to achieve that. Narrative
takes up more space than a few bulleted lists.

Also, I'm not surprised you haven't read the whole thing. I react similarly
to personas from projects I'm not involved in. IMHO, that's because the
information they contain isn't important to us at the time. I've found that
2 pages and maximum 1000 words is a good length to shoot for. People
actively involved in the project find it an easy length to read.

> Also, how relevant is the information? What design decision would you
> make based on the following information from the persona?

*Almost* every piece of information in that persona was useful to the design
team. To take your example...

> "He doesn't suffer fools, just as he won't put up with anything that
> stands in the way of getting his job done."

That statement encapsulated a couple of important insights that were
elaborated in the next paragraph. The people represented by Timothy:

- Have no patience for anything considered "extraneous". Stick to the core,
cut to the chase, or you'll lose them forever. (One could argue that
everybody feels that way, but we were stressing that Timothy feels it to a
much higher degree than usual.)

- Send most of their documents just before leaving for home each day.
They're in a hurry and want to leave. Don't stand in their way or they'll
get *very* pissed off.

"Suffering fools" and "standing in his way" actually became mantras for us
as we considered various design strategies. So we got some mileage out of
that particular statement.

> If I'm expected to constantly refer back to a document when I'm
> designing something, then don't format the thing so it takes 10
> minutes to read, and you have to sift through long paragraphs of
> content to find valuable info.

First, I'd argue that 10 minutes is nothing in the context of a design
project. Second, the people who would use these personas were also involved
in their creation, so it didn't take long to internalize them. Third, our
research had uncovered insights counter to what the business had assumed,
and the format helped tremendously in communicating what we'd learned. The
controversial finding? That people such as Timothy didn't really care about
security when sending files.

By presenting that finding through a story that put it in context, people
understood why the finding was in fact valid. Although Timothy seemed "cute"
at first, within minutes of presenting him to the project team, people were
referring to him by name and having some very productive discussions.

There's a real tension between the value of "character", created by the
format of a persona -- and the "cuteness" of that very format. Some people
have suggested that we change the format or abandon the narrative to make it
all less cute. But I don't want to do that because it's such a powerful
pattern.

--
Robert Barlow-Busch
http://www.chopsticker.com

19 Nov 2007 - 1:11pm
Chris Borokowski
2007

This is what sticks in my mind, as well.

While I'm not about to abandon personas entirely, I've skipped instead
to an "idealized user," which is an interpretation of the average
person under the following stressors:

1. Limited time
2. Background distraction
3. Partial knowledge

With the following human (or simian) traits:

1. Likes to forage
2. Needs affirmation
3. Learns best by example

Often, many extended use cases and personae can be replaced by this
user archetype.

--- Robert Barlow-Busch <bbb at terapath.net> wrote:

> There's a real tension between the value of "character", created by
> the
> format of a persona -- and the "cuteness" of that very format.

http://technical-writing.dionysius.com/
technical writing | consulting | development

____________________________________________________________________________________
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/

19 Nov 2007 - 5:45pm
Ron Perkins
2007

Good points, perhaps we could start another thread on what makes Personas
actually useful?
I agree that the artifact alone, especially if it is cute, has distractor
information.

One of the real values I think is that the different personas represent
ways
in which a user approaches a product or service from a fundamentally
different perspective, experience level and or motivation.

So for example in a data mining application, .a system administrator who
might set
up queries for others to use will need different things from a UI than an
analyst who
uses the product every day.

Both of those users will have a fundamentally different experience,
motivation and perspective for the
information from a CEO who may look at a dashboard view many times during
the day to make imporatant decisions. Knowing all of these perspectives in
detail would prevent SQL commands from the UI except in places where Admins
need them, etc. (I saw this happen on a real product once)

So in addition to the communication value, there can be real design
criteria
that emerge from detailed personas and the use cases that are different
under each one.

Ron
www.designperspectives.com

20 Nov 2007 - 11:14am
Adrian Howard
2005

On 19 Nov 2007, at 22:45, Ron Perkins wrote:
[snip]
> Both of those users will have a fundamentally different experience,
> motivation and perspective for the
> information from a CEO who may look at a dashboard view many times
> during
> the day to make imporatant decisions. Knowing all of these
> perspectives in
> detail would prevent SQL commands from the UI except in places
> where Admins
> need them, etc. (I saw this happen on a real product once)
>
> So in addition to the communication value, there can be real design
> criteria
> that emerge from detailed personas and the use cases that are
> different
> under each one.
[snip]

That's been my experience too.... reminded me of something I wrote on
the agile-usability list last year...

<quote>
Yes! This is why I like using Persona names rather than Roles in
stories. Because the interesting breakdowns when thinning stories
happen around persona differences rather than role differences. The
core features for JimTheEagerHobbyPhotographer's CropPhoto will be
different from those of MarthaTheSeventyYearOldGrandma CropPhoto.

By using persona in conversation with the customer you get them to
start thinking about which kinds of user bring the most business
value to particular features. I often start with identical stories
that only differ by persona name, which then get broken down into
quite different features for implementation.
</quote>

Cheers,

Adrian

20 Nov 2007 - 11:22am
Adrian Howard
2005

On 19 Nov 2007, at 18:11, Chris Borokowski wrote:

> This is what sticks in my mind, as well.
>
> While I'm not about to abandon personas entirely, I've skipped instead
> to an "idealized user," which is an interpretation of the average
> person under the following stressors:
[snip]
> Often, many extended use cases and personae can be replaced by this
> user archetype.

Nice idea.

I wonder if this sort of thing could act as a starting point for
persona development, rather than a replacement. A framework that you
can build on as more data arrives.

Just a thought...

Adrian

20 Nov 2007 - 11:39am
Mark Schraad
2006

This is a huge shift. A persona is a deep sample with very specific goals, behaviors and therfore perspective. If you switch to utilizing an architype - (they tend to be more of an agregate character similar to stereotypes) you are looking at a shallow sample with a lot less specificity. The dynamics of this shift are really important to consider. I find that there is certainly a time for aggregate or average data - segmenting, feature importance, use load, etc - but it often muddies the picture of who I am designing for.

Mark

On Monday, November 19, 2007, at 01:12PM, "Chris Borokowski" <athloi at yahoo.com> wrote:

>While I'm not about to abandon personas entirely, I've skipped instead
>to an "idealized user," which is an interpretation of the average
>person under the following stressors:

>Often, many extended use cases and personae can be replaced by this
>user archetype.

20 Nov 2007 - 2:13pm
Chris Borokowski
2007

I agree it's a huge shift, and can be dangerous in the wrong hands.
Then again, I've seen personas run amok and make products that fit no
one, so I can't say anything is 100% safe if applied by people who are
foolish, have poor judgment, are evil or inexperienced.

What I like about it is that it gets back to the core of the task-based
analysis. It's not who the user is; it's what do they do? In all cases,
making something work so it can be done faster, with fewer extraneous
complexities, yet with power user features available where needed, is
desired. I think a lot of use casing exists to try to "prove" these
needs to those who are inexperienced.

Aggregate data, like statistical data, only means what it means, I
guess. Good points.

--- Mark Schraad <mschraad at mac.com> wrote:

> This is a huge shift. A persona is a deep sample with very specific
> goals, behaviors and therfore perspective. If you switch to utilizing
> an architype - (they tend to be more of an agregate character similar
> to stereotypes) you are looking at a shallow sample with a lot less
> specificity. The dynamics of this shift are really important to
> consider. I find that there is certainly a time for aggregate or
> average data - segmenting, feature importance, use load, etc - but it
> often muddies the picture of who I am designing for.

http://technical-writing.dionysius.com/
technical writing | consulting | development

____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

26 Nov 2007 - 8:27pm
Alan Cooper
2004

What's the difference?

__________
cooper | Product Design for a Digital World
Alan Cooper
alan at cooper.com | www.cooper.com
All information in this message is proprietary & confidential.
"There is no country with a military so powerful, an economy so strong,
and a culture so great that its politicians cannot pull it down." -
Donald Gilbert Carpenter

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Jim
Drew
Sent: Thursday, November 15, 2007 9:44 PM
To: ixd-discussion
Subject: Re: [IxDA Discuss] Examples where personas are *not* useful

On Nov 13, 2007, at 1:24 PM, Alan Cooper wrote:

> The place where personas would not be useful is where the persona is
> elaborate camouflage for a designer creating self-referential
> solutions.
> In other words, personas help designers design for users. When
> personas
> are used to help designers design for themselves instead, that would
> be bad.

That's where poorly created personas aren't useful, not where personas
in general aren't useful, no?

-- Jim Drew
Seattle, WA

________________________________________________________________
*Come to IxDA Interaction08 | Savannah*
February 8-10, 2008 in Savannah, GA, USA
Register today: http://interaction08.ixda.org/

________________________________________________________________
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

27 Nov 2007 - 1:16am
White, Jeff
2007

Why not take the bait?

The difference is that there are some situations in which personas in
general are not feasible or realistic, but a time/resource drain on a
project, and thus are not useful. So even if you had a well crafted
persona, it's not adding any value and might actually hurt the
project.

Also - unless there is a large design team which is separate from
research staff, personas might not provide any extra value to those
doing research + design. Chances are they'll acquire any knowledge
from ethnography that a persona might provide and don't need the
"report format" of a persona to refer to during design.

I'm sure I'm completely wrong on some semantic level of course :-)
But, this has been my experience and judging by various comments on
the thread I'm not the only one.

What are your thoughts Alan?

Jeff

On Nov 26, 2007 8:27 PM, Alan Cooper <Alan at cooper.com> wrote:
> What's the difference?
>
> __________
> cooper | Product Design for a Digital World
> Alan Cooper
> alan at cooper.com | www.cooper.com
> All information in this message is proprietary & confidential.
> "There is no country with a military so powerful, an economy so strong,
> and a culture so great that its politicians cannot pull it down." -
> Donald Gilbert Carpenter
>
> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Jim
> Drew
> Sent: Thursday, November 15, 2007 9:44 PM
> To: ixd-discussion
>
> Subject: Re: [IxDA Discuss] Examples where personas are *not* useful
>
>
> On Nov 13, 2007, at 1:24 PM, Alan Cooper wrote:
>
> > The place where personas would not be useful is where the persona is
> > elaborate camouflage for a designer creating self-referential
> > solutions.
> > In other words, personas help designers design for users. When
> > personas
> > are used to help designers design for themselves instead, that would
> > be bad.
>
> That's where poorly created personas aren't useful, not where personas
> in general aren't useful, no?
>
> -- Jim Drew
> Seattle, WA
>
>
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> 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
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> 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
>

27 Nov 2007 - 8:24am
Jared M. Spool
2003

On Nov 27, 2007, at 1:16 AM, Jeff White wrote:

> Also - unless there is a large design team which is separate from
> research staff, personas might not provide any extra value to those
> doing research + design. Chances are they'll acquire any knowledge
> from ethnography that a persona might provide and don't need the
> "report format" of a persona to refer to during design.

I'm not going to try to answer for Alan. (Did that once. Vowed to
never do it again. :) ).

However, there are some factual inaccuracies with this paragraph I'd
like to point out, having studied in-depth how teams are using personas.

Most of the teams we've studied who make the best use of personas are
small -- typically 3-5 individuals on the core team. (We divide
persona creation teams into a core team, who dedicate their resources
to the project, and an auxiliary, who are important to the creation,
but can't dedicate resources for more than a few hours a week.)
Typically, the core team members do all the field research and, in
many cases, each member visited the majority, if not all, of the
field sites.

It is these smaller teams that we've found see the most benefit from
a persona project. Larger teams, where many of the team members don't
get direct access to the field visits seem to get less value. The big
take away we've had is you are better off with everyone on the team
having field access.

One of the problems of field research is the volume of raw data you
collect. If you spend a reasonable time with the informant (what we
call the participant in an ethnographic study), you'll collect a ton
of information and artifacts. (A "reasonable time" is at least 90
minutes, but often as long as 3 or 4 hours. For some projects, a day
or two is warranted.)

Just because you have a ton of data doesn't mean you understand its
implications or how it should influence the design. In fact, field
research done well, in its early stage, will only confuse what you
thought you knew. (Good research disorients before it reveals a
direction.)

The value of the persona creation project is to provide a structured
method of taking this chaotic data and bringing it to order. The
teams in our research that got the most out of their persona projects
spent a lot of time discussing and organizing the raw data. (On
average, the analysis period is 125% of the field research time. A
team that spent 6 days in the field would spend 8 or 9 days doing
analysis.)

The "report format" (as you called it) is the deliverable known as
the persona description. Our research shows this is the least
valuable element of the process. (Yet, interestingly enough, it's
seems to be what everyone who objects to personas focuses on.) As
I've said before on this list, teams that make effective use of
personas see this deliverable as a souvenir of their journey and
don't give it a lot of weight. It's value is mostly for integration
into the development process, to bring out during design and
development discussions for "talking points".

You can have a very successful persona project without ever creating
or using the persona description. (Successful, in our research, means
the team rates it as being an essential process contributor to the
success of the overall project.)

So, in fact, based on the research we've done, none of the statements
in your paragraph prove to be true. Just wanted to point that out
before we took them as fact.

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

27 Nov 2007 - 8:41am
Todd Warfel
2003

Jared already gave a pretty in-depth and accurate response. So, I'll
simply add a short response based on some additional experience.

On Nov 27, 2007, at 1:16 AM, Jeff White wrote:

> The difference is that there are some situations in which personas
> in general are not feasible or realistic, but a time/resource drain
> on a project, and thus are not useful. So even if you had a well
> crafted persona, it's not adding any value and might actually hurt
> the project.

Bullocks. Personas don't take that much time to develop once you have
the data. And since you're going to collect data anyway, or you should
be, then what's an extra day or two to develop some personsa? And
conversely, they end up saving a lot more time in the end, by making
your designs more accurate the first time out, taking less time in the
end by reducing the amount of rework. So, the notion that they are a
drain is simply not true.

In my experience, they save 2-3 times or more the amount of time and
effort they take to create. We've literally seen taking 2-3 days to
create the personas from the data save us months on a project
development time. They are a way to keep the team continually grounded
and focused to prevent scope creep.

> Also - unless there is a large design team which is separate from
> research staff, personas might not provide any extra value to those
> doing research + design. Chances are they'll acquire any knowledge
> from ethnography that a persona might provide and don't need the
> "report format" of a persona to refer to during design.

There are a number of other key people that personas are useful for.
Right now, we've got a client we're redesigning an internal
application for. All the users are at one site—all 30. However, the
client wants us to do personas anyway so that the executives have a
better understanding of what the customer service reps are going
through in their day-to-day jobs. This is to help them understand the
value of redesigning the application. An extra couple of days to get
senior management to buy in? Sounds like a good tradeoff.

Oh, and btw, we tried to tell them we didn't think we needed them as
all the users are right there, but once he indicated why he wanted
them, we obliged.

> I'm sure I'm completely wrong on some semantic level of course :-)
> But, this has been my experience and judging by various comments on
> the thread I'm not the only one.

Once again, that just goes to show that we need more education on how
to create and properly use personas. Used properly, they are one of
our most useful tools. But like any other tool, used incorrectly, or
not at all, well, we all know what happens then. Bad data in bad data
out.

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
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

27 Nov 2007 - 9:42am
White, Jeff
2007

"You can have a very successful persona project without ever creating
or using the persona description. (Successful, in our research, means
the team rates it as being an essential process contributor to the
success of the overall project.)"

Exactly. This is what I meant by:

Chances are they'll acquire any knowledge

from ethnography that a persona might provide and don't need the

"report format" of a persona to refer to during design.

If a persona is a process, not a deliverable, then maybe we should
call it that. If it's a process, how's it any different from
conducting interviews, observation, ethnography, etc?

Guys, I'm not being an anti-persona "dude", I've used them in the past
and they have been helpful. But I disagree with Alan, Jared and Todd
**if** they are proposing that personas are always useful and should
always be done. That just is not realistic, at least for the
environment I work in.

Like I said in the original reply to Alan, I took the bait to continue
the discussion, which I think is a very good one.

Jeff

On Nov 27, 2007 8:24 AM, Jared M. Spool <jspool at uie.com> wrote:
>
>
>
> On Nov 27, 2007, at 1:16 AM, Jeff White wrote:
>
>
> Also - unless there is a large design team which is separate from
>
> research staff, personas might not provide any extra value to those
>
> doing research + design. Chances are they'll acquire any knowledge
>
> from ethnography that a persona might provide and don't need the
>
> "report format" of a persona to refer to during design.
> I'm not going to try to answer for Alan. (Did that once. Vowed to never do
> it again. :) ).
>
> However, there are some factual inaccuracies with this paragraph I'd like to
> point out, having studied in-depth how teams are using personas.
>
> Most of the teams we've studied who make the best use of personas are small
> -- typically 3-5 individuals on the core team. (We divide persona creation
> teams into a core team, who dedicate their resources to the project, and an
> auxiliary, who are important to the creation, but can't dedicate resources
> for more than a few hours a week.) Typically, the core team members do all
> the field research and, in many cases, each member visited the majority, if
> not all, of the field sites.
>
> It is these smaller teams that we've found see the most benefit from a
> persona project. Larger teams, where many of the team members don't get
> direct access to the field visits seem to get less value. The big take away
> we've had is you are better off with everyone on the team having field
> access.
>
> One of the problems of field research is the volume of raw data you collect.
> If you spend a reasonable time with the informant (what we call the
> participant in an ethnographic study), you'll collect a ton of information
> and artifacts. (A "reasonable time" is at least 90 minutes, but often as
> long as 3 or 4 hours. For some projects, a day or two is warranted.)
>
> Just because you have a ton of data doesn't mean you understand its
> implications or how it should influence the design. In fact, field research
> done well, in its early stage, will only confuse what you thought you knew.
> (Good research disorients before it reveals a direction.)
>
> The value of the persona creation project is to provide a structured method
> of taking this chaotic data and bringing it to order. The teams in our
> research that got the most out of their persona projects spent a lot of time
> discussing and organizing the raw data. (On average, the analysis period is
> 125% of the field research time. A team that spent 6 days in the field would
> spend 8 or 9 days doing analysis.)
>
> The "report format" (as you called it) is the deliverable known as the
> persona description. Our research shows this is the least valuable element
> of the process. (Yet, interestingly enough, it's seems to be what everyone
> who objects to personas focuses on.) As I've said before on this list, teams
> that make effective use of personas see this deliverable as a souvenir of
> their journey and don't give it a lot of weight. It's value is mostly for
> integration into the development process, to bring out during design and
> development discussions for "talking points".
>
> You can have a very successful persona project without ever creating or
> using the persona description. (Successful, in our research, means the team
> rates it as being an essential process contributor to the success of the
> overall project.)
>
> So, in fact, based on the research we've done, none of the statements in
> your paragraph prove to be true. Just wanted to point that out before we
> took them as fact.
>
> 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
>
>

27 Nov 2007 - 9:58am
White, Jeff
2007

"what's an extra day or two to develop some personas"

If you're not doing traditional waterfall development, that's a heck
of a lot of time. Also, if you're working more than 1 project at a
time and can't focus all your energy on synthesizing tons of fieldwork
data into a persona, it **might** take even longer.

"They are a way to keep the team continually grounded and focused to
prevent scope
creep."

So is good old fashioned face to face communication and relationship
building with engineers, stakeholders, execs, etc. Just playing Devils
advocate. I know that's not always possible.

"Once again, that just goes to show that we need more education on how to
create and properly use personas. Used properly, they are one of our most
useful tools. But like any other tool, used incorrectly, or not at all,
well, we all know what happens then. Bad data in bad data out."

Please don't stick me over in the corner with the persona dunce hat
on. I've created personas the right way in the past (and I commented
on my disappointment that folks out there are documenting their
subjective opinions and calling them personas earlier in this thread)
and have used them in the all the ways you and Jared suggest. I think
they are very good tools, but not always, that's where I disagree with
you guys. The original topic of this thread is "when are personas not
useful?". Based on my experience, there are times when they are not
the best tool for the job. The same results continued to be mentioned
in this thread can be achieved by other means. Sometimes those other
means make more sense on a particular project than a persona. There
is more than one way to skin a cat.

Thanks for continuing the discussion, I think it's one of the best
I've participated in since joinig IxDA!

Jeff

On Nov 27, 2007 8:41 AM, Todd Zaki Warfel <lists at toddwarfel.com> wrote:
> Jared already gave a pretty in-depth and accurate response. So, I'll simply
> add a short response based on some additional experience.
>
>
> On Nov 27, 2007, at 1:16 AM, Jeff White wrote:
>
> The difference is that there are some situations in which personas in
> general are not feasible or realistic, but a time/resource drain on a
> project, and thus are not useful. So even if you had a well crafted persona,
> it's not adding any value and might actually hurt the project.
>
> Bullocks. Personas don't take that much time to develop once you have the
> data. And since you're going to collect data anyway, or you should be, then
> what's an extra day or two to develop some personsa? And conversely, they
> end up saving a lot more time in the end, by making your designs more
> accurate the first time out, taking less time in the end by reducing the
> amount of rework. So, the notion that they are a drain is simply not true.
>
> In my experience, they save 2-3 times or more the amount of time and effort
> they take to create. We've literally seen taking 2-3 days to create the
> personas from the data save us months on a project development time. They
> are a way to keep the team continually grounded and focused to prevent scope
> creep.
>
> Also - unless there is a large design team which is separate from research
> staff, personas might not provide any extra value to those doing research +
> design. Chances are they'll acquire any knowledge
> from ethnography that a persona might provide and don't need the "report
> format" of a persona to refer to during design.
>
> There are a number of other key people that personas are useful for. Right
> now, we've got a client we're redesigning an internal application for. All
> the users are at one site—all 30. However, the client wants us to do
> personas anyway so that the executives have a better understanding of what
> the customer service reps are going through in their day-to-day jobs. This
> is to help them understand the value of redesigning the application. An
> extra couple of days to get senior management to buy in? Sounds like a good
> tradeoff.
>
> Oh, and btw, we tried to tell them we didn't think we needed them as all the
> users are right there, but once he indicated why he wanted them, we obliged.
>
>
> I'm sure I'm completely wrong on some semantic level of course :-) But, this
> has been my experience and judging by various comments on the thread I'm not
> the only one.
>
> Once again, that just goes to show that we need more education on how to
> create and properly use personas. Used properly, they are one of our most
> useful tools. But like any other tool, used incorrectly, or not at all,
> well, we all know what happens then. Bad data in bad data out.
>
>
>
> 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
> ----------------------------------
> In theory, theory and practice are the same.
> In practice, they are not.
>

27 Nov 2007 - 10:01am
Todd Warfel
2003

On Nov 27, 2007, at 9:42 AM, Jeff White wrote:

> But I disagree with Alan, Jared and Todd **if** they are proposing
> that personas are always useful and should always be done. That just
> is not realistic, at least for the environment I work in.

Funny, that's what the folks at ATT told us when we did the redesign
of their ecommerce site a few years back—there's no time for user
research. So, we did it anyway. We went down to a couple of local
mobile phone shops and talked to customers and sales people. It took a
couple of hours and we gathered some really great data from actual
users that informed the design.

There's always time in every environment. You just have to take it.
The more you do personas, the better you get at them and the more
efficient you become. And btw, they don't always have to be a long
drawn out process. Like any other deliverable, you create them based
on the resources you have, accepting their fidelity accordingly.

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
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

27 Nov 2007 - 10:08am
Todd Warfel
2003

On Nov 27, 2007, at 9:58 AM, Jeff White wrote:

> So is good old fashioned face to face communication and relationship
> building with engineers, stakeholders, execs, etc. Just playing
> Devils advocate. I know that's not always possible.

That's a trade off. The amount of time spent chasing after these
stakeholders can often amount to extra days as well—at least in our
environment getting senior execs can take weeks at times. So, in fact
personas can save that time. It's a trade off. BTW, I'm a firm
believer in speaking directly with customers/users whenever possible.

> "Once again, that just goes to show that we need more education on
> how to create and properly use personas. Used properly, they are one
> of our most useful tools. But like any other tool, used incorrectly,
> or not at all, well, we all know what happens then. Bad data in bad
> data out."
>
> Please don't stick me over in the corner with the persona dunce hat
> on. I've created personas the right way in the past (and I commented
> on my disappointment that folks out there are documenting their
> subjective opinions and calling them personas earlier in this
> thread) and have used them in the all the ways you and Jared suggest.

I'm not putting you in any corner w/a dunce cap on. I'm saying "we" as
in we the industry as a whole.

> I think they are very good tools, but not always, that's where I
> disagree with you guys. The original topic of this thread is "when
> are personas not useful?". Based on my experience, there are times
> when they are not the best tool for the job. The same results
> continued to be mentioned in this thread can be achieved by other
> means. Sometimes those other means make more sense on a particular
> project than a persona. There is more than one way to skin a cat.

Agreed. A tool is just that—a tool.

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
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

27 Nov 2007 - 10:25am
Pierre Roberge
2005

I think this discussion would progress faster if we were to define what
level of details you need to have a personas. Does a name and one goal
constitute a persona? In my mind yes, a persona is a collection of info
I have about the user population. The level of detail and the amount of
information I put in my personas depend on the time I have. I can
create a very simple persona in a few minutes or a full-fledged persona
set if a few weeks in.

So in my mind, time is not really an issue for deciding whether to
create personas or not. The tool is scalable.

Pierre Roberge
User Experience Designer - Business Analyst
etfs

27 Nov 2007 - 11:18am
brianh
2010

> -----Original Message-----
> Once again, that just goes to show that we need more education on how
> to create and properly use personas. Used properly, they are one of
> our most useful tools. But like any other tool, used incorrectly, or
> not at all, well, we all know what happens then. Bad data in bad data
> out.

Please forgive me if this should be a new thread...

So what resources do folks on this list recommend for acquiring the
proper education on how to create and properly use personas?

Thanks,

Brian J. Hoffman
Interface Designer
Minitab Inc.
Quality Plaza
1829 Pine Hall Road
State College, PA 16801-3008
USA/CAN/MEX: +1 800 448-3555 Ext.#514
Tel: +1 814-238-3280 Ext.#514
Fax: +1 814-238-4383
Web site: www.minitab.com

27 Nov 2007 - 11:54am
Jared M. Spool
2003

On Nov 27, 2007, at 9:42 AM, Jeff White wrote:

> If a persona is a process, not a deliverable, then maybe we should
> call it that. If it's a process, how's it any different from
> conducting interviews, observation, ethnography, etc?

To keep our terminology straight at UIE, we've labeled the process of
creating personas as "persona creation". (We're not very
imaginative.) The usual deliverables we call a "persona description"
and a "persona reference card". The individual character is what we
call the "persona". So, a persona project would have one persona
creation process to produce 3 to 7 personas, each with a persona
description.

The persona creation process includes a research stage, whereby a
field study is the typical research instrument. (There is debate as
to whether field studies are always ethnographic research or if
ethnographic research is a variant of a field study. I don't think we
want to split that hair at this point.)

However, the persona creation process, in our definition, includes
three other stages: data analysis, persona and scenario deliverable
creation, and project integration.

> But I disagree with Alan, Jared and Todd
> **if** they are proposing that personas are always useful and should
> always be done.

I've never said they are always useful and should always be done.
They are a tool in the toolbox. Like any tool, they have their
contexts where they are valuable. There are contexts where their
value will not be worth the resource investment required.

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

27 Nov 2007 - 1:06pm
Robert Hoekman, Jr.
2005

> Bullocks. Personas don't take that much time to develop once you have
> the data. And since you're going to collect data anyway, or you should
> be, then what's an extra day or two to develop some personsa?

You assumed here that they were, in fact, going to "collect the data
anyway". But that's the time-consuming part. That's the part a lot of
companies/project teams simply don't have the time and/or money to perform.

-r-

27 Nov 2007 - 1:23pm
Todd Warfel
2003

Yes, I'm expecting that the design decisions have some data to back
them up, even if it's a quick and dirty gorilla method.

On Nov 27, 2007, at 1:06 PM, Robert Hoekman, Jr. wrote:

>
> Bullocks. Personas don't take that much time to develop once you have
> the data. And since you're going to collect data anyway, or you should
> be, then what's an extra day or two to develop some personsa?
>
> You assumed here that they were, in fact, going to "collect the data
> anyway". But that's the time-consuming part. That's the part a lot
> of companies/project teams simply don't have the time and/or money
> to perform.
>
> -r-

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
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

27 Nov 2007 - 1:36pm
Robert Hoekman, Jr.
2005

> Yes, I'm expecting that the design decisions have some data to back them
> up, even if it's a quick and dirty gorilla method.
>

But why? Not all design work is rooted in user research. Sure, there may be
data of some kind to back up and inform design decisions, but this
information doesn't have to come from people - it can come from activity
research, for example.

People in other disciplines design successful products all the time without
studying specific audiences and without creating personas.

Good design can also simply be the result of a good designer putting a good
idea to work in a way that communicates and translates well. User research
is not the ultimate solution for designers and never has been.

(Forgive me if I'm assuming incorrectly that you think user research is
always the way to go.)

-r-

27 Nov 2007 - 1:45pm
Todd Warfel
2003

Necessity is the mother of invention. I would argue that experience is
in fact a method of research. When designing a product for yourself,
or similar audience, then your own experiences are in fact research,
though not formal. In the case of the IxD field, often times we are
designing for others, which in that case, I would expect that we
should do some more formalized research.

Can good design be done w/o formal research? Well, yes of course, but
it's rare. There are far too many products out today that clearly had
little of any research applied to them. It doesn't take much to do a
little homework for your design.

On Nov 27, 2007, at 1:36 PM, Robert Hoekman, Jr. wrote:

> But why? Not all design work is rooted in user research. Sure, there
> may be data of some kind to back up and inform design decisions, but
> this information doesn't have to come from people - it can come from
> activity research, for example.

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
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

27 Nov 2007 - 2:02pm
Robert Hoekman, Jr.
2005

> Can good design be done w/o formal research? Well, yes of course, but it's
> rare.
>

Are you sure?

I mean, I agree that there are a huge number of lousy products/sites/etc out
there, but there are also boatloads of great products, and according to
Jared, only something like 5% of teams who use personas are doing them
right, and I'd guess that only a small percentage of design teams use them
at all.

Assuming this is a correct statement, I doubt that the only good products
out there are those designed by this measly 5% of the already small
percentage of persona-using designers. So where are the rest of the good
products coming from?

Good design happens. Process can help, research can help - heck, even
personas can help. But none are a requirement of good design. And since each
is used effectively so rarely, it's obvious that a ton of good design is
done without these tools.

So, how confident are you, really, that good design is rare unless backed up
by formal research?

(Sorry if I'm sounding needlessly antagonistic, but this subject really gets
under my skin, as you might already be aware.)

-r-

27 Nov 2007 - 2:24pm
White, Jeff
2007

Forgive me if I'm misinterpreting here...

I think Robert may be focusing on good design done w/o the use of
personas, which I completely agree is possible and very probable.

But that doesn't mean that *no* user centered research was conducted -
it just means they didn't use personas. Which I think is Todd's point
here...good design is much more probable when some sort of user
centered research (especially when designing for an audience other
than yourself) is conducted.

I'm a big proponent of UCD - I believe "good design" is much more
probable when UCD is utilized. That said, it doesn't guarantee good UX
and it doesn't mean you'll never have a good UX unless you do formal
research.

It would be very interesting to get a rough idea of how many "good"
products out there were developed strictly in a vaccuum by marketing,
designers or engineers - w/o the use of customer interviews,
observation, ethnography, usability testing, personas, card sorting,
task analysis etc.

Jeff

On Nov 27, 2007 2:02 PM, Robert Hoekman, Jr. <robert at rhjr.net> wrote:
>
>
> >
> >
> > Can good design be done w/o formal research? Well, yes of course, but it's
> rare.
>
> Are you sure?
>
> I mean, I agree that there are a huge number of lousy products/sites/etc out
> there, but there are also boatloads of great products, and according to
> Jared, only something like 5% of teams who use personas are doing them
> right, and I'd guess that only a small percentage of design teams use them
> at all.
>
> Assuming this is a correct statement, I doubt that the only good products
> out there are those designed by this measly 5% of the already small
> percentage of persona-using designers. So where are the rest of the good
> products coming from?
>
> Good design happens. Process can help, research can help - heck, even
> personas can help. But none are a requirement of good design. And since each
> is used effectively so rarely, it's obvious that a ton of good design is
> done without these tools.
>
> So, how confident are you, really, that good design is rare unless backed up
> by formal research?
>
> (Sorry if I'm sounding needlessly antagonistic, but this subject really gets
> under my skin, as you might already be aware.)
>
> -r-

27 Nov 2007 - 2:33pm
Todd Warfel
2003

Yes, this is my point. That good design done w/o any type of research
is rare. To think that it happens simply by chance is IMHO
shortsighted and naive. Furthermore, why take the risk? Why wouldn't
you inform your design by some research?

Speaking for myself and Messagefirst, every time we've done some
research, typically based on ethnographic methods, our designs have
turned out that much more informed, innovative, and intuitive. We have
done some good designs based simply on pre-existing knowledge, but
they're not nearly as good as those that are informed through
research. I hardly think this is an anomaly.

On Nov 27, 2007, at 2:24 PM, Jeff White wrote:

> But that doesn't mean that *no* user centered research was conducted
> - it just means they didn't use personas. Which I think is Todd's
> point here...good design is much more probable when some sort of
> user centered research (especially when designing for an audience
> other than yourself) is conducted.

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
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

27 Nov 2007 - 2:40pm
Mark Schraad
2006

Sooo... at the risk of grossly oversimplifying...

a designer can:

1 be the target user/audience/market

2 already know the target user/audience/market (hopefully from real and successful experience)

3 research the target user/audience/market and hopefully find a tool (persona) to document and communicate findings

4 or just 'feel lucky'

Mark

On Tuesday, November 27, 2007, at 02:34PM, "Todd Zaki Warfel" <lists at toddwarfel.com> wrote:
>Yes, this is my point. That good design done w/o any type of research
>is rare. To think that it happens simply by chance is IMHO
>shortsighted and naive. Furthermore, why take the risk? Why wouldn't
>you inform your design by some research?
>
>Speaking for myself and Messagefirst, every time we've done some
>research, typically based on ethnographic methods, our designs have
>turned out that much more informed, innovative, and intuitive. We have
>done some good designs based simply on pre-existing knowledge, but
>they're not nearly as good as those that are informed through
>research. I hardly think this is an anomaly.
>
>On Nov 27, 2007, at 2:24 PM, Jeff White wrote:
>
>> But that doesn't mean that *no* user centered research was conducted
>> - it just means they didn't use personas. Which I think is Todd's
>> point here...good design is much more probable when some sort of
>> user centered research (especially when designing for an audience
>> other than yourself) is conducted.

27 Nov 2007 - 2:43pm
Mark Schraad
2006

I would take this a step further. Every time I/we do research we find out something important that we did not know, or something to contradict our assumptions. We often tell clients that research is worthwhile even if it only confirms their understanding of the user, but it rarely does only that.

Mark

On Tuesday, November 27, 2007, at 02:34PM, "Todd Zaki Warfel" <lists at toddwarfel.com> wrote:

>Speaking for myself and Messagefirst, every time we've done some
>research, typically based on ethnographic methods, our designs have
>turned out that much more informed, innovative, and intuitive.

27 Nov 2007 - 2:54pm
Robert Hoekman, Jr.
2005

> good design is much more probable when some sort of user
> centered research (especially when designing for an audience other
> than yourself) is conducted.

I agree with the rest of what you said, but again, why *user* centered, as
opposed to activity-centered or something else?

-r-

27 Nov 2007 - 3:15pm
Katie Albers
2005

At 12:54 PM -0700 11/27/07, Robert Hoekman, Jr. wrote:
> > good design is much more probable when some sort of user
>> centered research (especially when designing for an audience other
>> than yourself) is conducted.
>
>
>I agree with the rest of what you said, but again, why *user* centered, as
>opposed to activity-centered or something else?
>
>-r-
>________________________________________________________________

Speaking for myself, here...because different people pursue the same
activity in different ways. This generally tends to correlate to the
"type" of user (not gonna get into the whole persona debate that
directly...unh unh...not now).

To use a really easy example: I write a check. I record the check in
my register (because I'm such a good little girl). I have recorded a
debit...if you asked me. But in my mind it's just keeping track of a
check.

I hand my bookkeeper the duplicates of all the checks I've written
since last time. She takes each check and records the amount and the
category and the date and all that other stuff and...she has now
recorded a credit. But in her mind, she's just keeping track of
expenditures.

So, labelling may change for each user. Task categorization,
likewise. And so on...

Katie
--

------------------
Katie Albers
User Experience Consulting & Project Management
katie at firstthought.com

27 Nov 2007 - 3:23pm
Robert Hoekman, Jr.
2005

> Yes, this is my point. That good design done w/o any type of research is
> rare.
>

I assume you're talking specifically about interaction design. Am I right?

To think that it happens simply by chance is IMHO shortsighted and naive.
> Furthermore, why take the risk? Why wouldn't you inform your design by some
> research?
>

I'll assume you meant no offense by this.

Let's look at an example. I recently visited the WTC site and spent a couple
of of hours reflecting, taking pictures, etc. Since leaving there, I've had
quite a few conversations about the experience. And I've noticed that all
these conversations have had one thing in common (sorry - can't tell you
what it is without sharing my idea and I'm not ready to do that yet).

I wasn't doing research, just having conversations. But this series of
occurrences sparked an idea that I'm now turning into an application that
can be applied in a myriad of contexts. (Please don't run off and steal what
you might guess is the idea.)

Did this happen by chance? Depends on your definition. I didn't intend it,
didn't think it out, didn't pursue it, but since having the initial idea,
it's gelled into something that will be really wonderful. I know exactly how
the application should work and what it should do based on the simple
"accidental" idea that triggered it.

I suppose you could argue that these conversations were "research", but they
really weren't. They didn't lead me to figuring out how the site should
work, they just led to the idea.

In this example, I'm not designing something that solves a client's need,
I'm designing a "place" for people to go for a variety of personal reasons
to participate in something interesting. To do this, I don't need to perform
any research.

I realize not all products are created this way - I do client work as well.
My point is simply that not all good design is the result of research.
Sometimes it's inspired, experimental, etc.

"Design", to me, means a lot of things. In many cases, it means putting
together something very functional. In many other cases, it means inventing
an experience for reasons other than productivity. Sometimes it's about
solving problems. Sometimes it's not about problems at all, instead focusing
on personal connections, participation, emotion, etc., for reasons other
than "I need to get something done".

There may be a difference in the kind of design I'm talking about what
you're talking about. What I refer to here may be more of an "interactive
art" type thing rather than "interaction design". But who knows. Some
definitions of IxD say it's the bringing together of people through
technology, and that's certainly what this app will do. Still, I'd normally
associate this type of work with someone like, say, Josh Davis, who isn't
generally considered an IxD.

It always comes back to semantics. :)

-r-

27 Nov 2007 - 5:10pm
White, Jeff
2007

Sounds like you have something interesting in the works Robert. Here's
where I stand, and maybe it is semantics we're tripping over...

You can come up with an idea or product concept from anywhere - no UCD
needed for sure. But UCD is an excellent idea when it comes time to
designing the nuts and bolts of how the site works, how people will
interact with it, what specific features it has, etc.

Jeff

On Nov 27, 2007 3:23 PM, Robert Hoekman, Jr. <robert at rhjr.net> wrote:
>
>
> >
> > Yes, this is my point. That good design done w/o any type of research is
> rare.
>
> I assume you're talking specifically about interaction design. Am I right?
>
> >
> > To think that it happens simply by chance is IMHO shortsighted and naive.
> Furthermore, why take the risk? Why wouldn't you inform your design by some
> research?
>
> I'll assume you meant no offense by this.
>
> Let's look at an example. I recently visited the WTC site and spent a couple
> of of hours reflecting, taking pictures, etc. Since leaving there, I've had
> quite a few conversations about the experience. And I've noticed that all
> these conversations have had one thing in common (sorry - can't tell you
> what it is without sharing my idea and I'm not ready to do that yet).
>
> I wasn't doing research, just having conversations. But this series of
> occurrences sparked an idea that I'm now turning into an application that
> can be applied in a myriad of contexts. (Please don't run off and steal what
> you might guess is the idea.)
>
> Did this happen by chance? Depends on your definition. I didn't intend it,
> didn't think it out, didn't pursue it, but since having the initial idea,
> it's gelled into something that will be really wonderful. I know exactly how
> the application should work and what it should do based on the simple
> "accidental" idea that triggered it.
>
> I suppose you could argue that these conversations were "research", but they
> really weren't. They didn't lead me to figuring out how the site should
> work, they just led to the idea.
>
> In this example, I'm not designing something that solves a client's need,
> I'm designing a "place" for people to go for a variety of personal reasons
> to participate in something interesting. To do this, I don't need to perform
> any research.
>
> I realize not all products are created this way - I do client work as well.
> My point is simply that not all good design is the result of research.
> Sometimes it's inspired, experimental, etc.
>
> "Design", to me, means a lot of things. In many cases, it means putting
> together something very functional. In many other cases, it means inventing
> an experience for reasons other than productivity. Sometimes it's about
> solving problems. Sometimes it's not about problems at all, instead focusing
> on personal connections, participation, emotion, etc., for reasons other
> than "I need to get something done".
>
> There may be a difference in the kind of design I'm talking about what
> you're talking about. What I refer to here may be more of an "interactive
> art" type thing rather than "interaction design". But who knows. Some
> definitions of IxD say it's the bringing together of people through
> technology, and that's certainly what this app will do. Still, I'd normally
> associate this type of work with someone like, say, Josh Davis, who isn't
> generally considered an IxD.
>
> It always comes back to semantics. :)
>
> -r-
>

27 Nov 2007 - 5:20pm
Mark Schraad
2006

Dude - you were sooo doing research. ;-)

On Tuesday, November 27, 2007, at 03:24PM, "Robert Hoekman, Jr." <robert at rhjr.net> wrote:

>Let's look at an example. I recently visited the WTC site and spent a couple
>of of hours reflecting, taking pictures, etc. Since leaving there, I've had
>quite a few conversations about the experience. And I've noticed that all
>these conversations have had one thing in common (sorry - can't tell you
>what it is without sharing my idea and I'm not ready to do that yet).
>
>I wasn't doing research, just having conversations.

27 Nov 2007 - 5:28pm
Robert Hoekman, Jr.
2005

Or ACD. :)

As a profession, we need more choices. Rather, we need to *recognize*
the choices that are already out there whether they fit into a UCD
mold or not, and at least be willing to believe there is more than one
way to skin the proverbial cat.

-r-

Sent from my iPhone.

On Nov 27, 2007, at 3:10 PM, "Jeff White" <jwhite31 at gmail.com> wrote:

> Sounds like you have something interesting in the works Robert. Here's
> where I stand, and maybe it is semantics we're tripping over...
>
> You can come up with an idea or product concept from anywhere - no UCD
> needed for sure. But UCD is an excellent idea when it comes time to
> designing the nuts and bolts of how the site works, how people will
> interact with it, what specific features it has, etc.
>
> Jeff
>
> On Nov 27, 2007 3:23 PM, Robert Hoekman, Jr. <robert at rhjr.net> wrote:
>>
>>
>>>
>>> Yes, this is my point. That good design done w/o any type of
>>> research is
>> rare.
>>
>> I assume you're talking specifically about interaction design. Am I
>> right?
>>
>>>
>>> To think that it happens simply by chance is IMHO shortsighted and
>>> naive.
>> Furthermore, why take the risk? Why wouldn't you inform your design
>> by some
>> research?
>>
>> I'll assume you meant no offense by this.
>>
>> Let's look at an example. I recently visited the WTC site and spent
>> a couple
>> of of hours reflecting, taking pictures, etc. Since leaving there,
>> I've had
>> quite a few conversations about the experience. And I've noticed
>> that all
>> these conversations have had one thing in common (sorry - can't
>> tell you
>> what it is without sharing my idea and I'm not ready to do that yet).
>>
>> I wasn't doing research, just having conversations. But this series
>> of
>> occurrences sparked an idea that I'm now turning into an
>> application that
>> can be applied in a myriad of contexts. (Please don't run off and
>> steal what
>> you might guess is the idea.)
>>
>> Did this happen by chance? Depends on your definition. I didn't
>> intend it,
>> didn't think it out, didn't pursue it, but since having the initial
>> idea,
>> it's gelled into something that will be really wonderful. I know
>> exactly how
>> the application should work and what it should do based on the simple
>> "accidental" idea that triggered it.
>>
>> I suppose you could argue that these conversations were "research",
>> but they
>> really weren't. They didn't lead me to figuring out how the site
>> should
>> work, they just led to the idea.
>>
>> In this example, I'm not designing something that solves a client's
>> need,
>> I'm designing a "place" for people to go for a variety of personal
>> reasons
>> to participate in something interesting. To do this, I don't need
>> to perform
>> any research.
>>
>> I realize not all products are created this way - I do client work
>> as well.
>> My point is simply that not all good design is the result of
>> research.
>> Sometimes it's inspired, experimental, etc.
>>
>> "Design", to me, means a lot of things. In many cases, it means
>> putting
>> together something very functional. In many other cases, it means
>> inventing
>> an experience for reasons other than productivity. Sometimes it's
>> about
>> solving problems. Sometimes it's not about problems at all, instead
>> focusing
>> on personal connections, participation, emotion, etc., for reasons
>> other
>> than "I need to get something done".
>>
>> There may be a difference in the kind of design I'm talking about
>> what
>> you're talking about. What I refer to here may be more of an
>> "interactive
>> art" type thing rather than "interaction design". But who knows. Some
>> definitions of IxD say it's the bringing together of people through
>> technology, and that's certainly what this app will do. Still, I'd
>> normally
>> associate this type of work with someone like, say, Josh Davis, who
>> isn't
>> generally considered an IxD.
>>
>> It always comes back to semantics. :)
>>
>> -r-
>>

27 Nov 2007 - 5:50pm
White, Jeff
2007

"Dude - you were sooo doing research. ;-)"

Like, totally :-)

I feel like we do have choices Robert. There's UCD, under that
umbrella are tons of tools, techniques etc at your disposal - no one
is saying there is one way to conduct UCD. There's also usage centered
design. There are lots of other research techniques, design
methodologies as well which I won't bother to list.

Or you can come up with ideas and design them based on your expertise
as a designer and never ever do customer research. If your idea fails
because you spent all your capital or resources developing a feature
that no one uses or sees or understands anyway, that would be a shame.
Bad UX can cripple the best product or service concept. UCD is a
proven way to deliver high quality UX.

What is it you feel is missing?

Jeff

On Nov 27, 2007 5:28 PM, Robert Hoekman, Jr. <robert at rhjr.net> wrote:
> Or ACD. :)
>
> As a profession, we need more choices. Rather, we need to *recognize*
> the choices that are already out there whether they fit into a UCD
> mold or not, and at least be willing to believe there is more than one
> way to skin the proverbial cat.
>
> -r-
>
> Sent from my iPhone.
>
>
> On Nov 27, 2007, at 3:10 PM, "Jeff White" <jwhite31 at gmail.com> wrote:
>
> > Sounds like you have something interesting in the works Robert. Here's
> > where I stand, and maybe it is semantics we're tripping over...
> >
> > You can come up with an idea or product concept from anywhere - no UCD
> > needed for sure. But UCD is an excellent idea when it comes time to
> > designing the nuts and bolts of how the site works, how people will
> > interact with it, what specific features it has, etc.
> >
> > Jeff
> >
> > On Nov 27, 2007 3:23 PM, Robert Hoekman, Jr. <robert at rhjr.net> wrote:
> >>
> >>
> >>>
> >>> Yes, this is my point. That good design done w/o any type of
> >>> research is
> >> rare.
> >>
> >> I assume you're talking specifically about interaction design. Am I
> >> right?
> >>
> >>>
> >>> To think that it happens simply by chance is IMHO shortsighted and
> >>> naive.
> >> Furthermore, why take the risk? Why wouldn't you inform your design
> >> by some
> >> research?
> >>
> >> I'll assume you meant no offense by this.
> >>
> >> Let's look at an example. I recently visited the WTC site and spent
> >> a couple
> >> of of hours reflecting, taking pictures, etc. Since leaving there,
> >> I've had
> >> quite a few conversations about the experience. And I've noticed
> >> that all
> >> these conversations have had one thing in common (sorry - can't
> >> tell you
> >> what it is without sharing my idea and I'm not ready to do that yet).
> >>
> >> I wasn't doing research, just having conversations. But this series
> >> of
> >> occurrences sparked an idea that I'm now turning into an
> >> application that
> >> can be applied in a myriad of contexts. (Please don't run off and
> >> steal what
> >> you might guess is the idea.)
> >>
> >> Did this happen by chance? Depends on your definition. I didn't
> >> intend it,
> >> didn't think it out, didn't pursue it, but since having the initial
> >> idea,
> >> it's gelled into something that will be really wonderful. I know
> >> exactly how
> >> the application should work and what it should do based on the simple
> >> "accidental" idea that triggered it.
> >>
> >> I suppose you could argue that these conversations were "research",
> >> but they
> >> really weren't. They didn't lead me to figuring out how the site
> >> should
> >> work, they just led to the idea.
> >>
> >> In this example, I'm not designing something that solves a client's
> >> need,
> >> I'm designing a "place" for people to go for a variety of personal
> >> reasons
> >> to participate in something interesting. To do this, I don't need
> >> to perform
> >> any research.
> >>
> >> I realize not all products are created this way - I do client work
> >> as well.
> >> My point is simply that not all good design is the result of
> >> research.
> >> Sometimes it's inspired, experimental, etc.
> >>
> >> "Design", to me, means a lot of things. In many cases, it means
> >> putting
> >> together something very functional. In many other cases, it means
> >> inventing
> >> an experience for reasons other than productivity. Sometimes it's
> >> about
> >> solving problems. Sometimes it's not about problems at all, instead
> >> focusing
> >> on personal connections, participation, emotion, etc., for reasons
> >> other
> >> than "I need to get something done".
> >>
> >> There may be a difference in the kind of design I'm talking about
> >> what
> >> you're talking about. What I refer to here may be more of an
> >> "interactive
> >> art" type thing rather than "interaction design". But who knows. Some
> >> definitions of IxD say it's the bringing together of people through
> >> technology, and that's certainly what this app will do. Still, I'd
> >> normally
> >> associate this type of work with someone like, say, Josh Davis, who
> >> isn't
> >> generally considered an IxD.
> >>
> >> It always comes back to semantics. :)
> >>
> >> -r-
> >>
>

27 Nov 2007 - 5:53pm
Jared M. Spool
2003

On Nov 27, 2007, at 5:28 PM, Robert Hoekman, Jr. wrote:

> Or ACD. :)
>
> As a profession, we need more choices. Rather, we need to *recognize*
> the choices that are already out there whether they fit into a UCD
> mold or not, and at least be willing to believe there is more than one
> way to skin the proverbial cat.

I still don't buy there's anything to this activity-based design
stuff. (Of course, you'll never find me referring to anything as user-
centered design, either.)

Good design is about understanding who you're designing for and what
they are trying to do. Whether you focus on differences in the
individual or differences in their goals/objectives/tasks/activities,
is going to depend on the nature of the design project and what
you're trying to accomplish.

In the end, it's all about having information to make informed design
decision, no matter what stupid label you apply 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

27 Nov 2007 - 6:04pm
Adlin, Tamara
2004

I still think this discussion is missing a super-critical point.
Personas are not just about design. Personas are about focus. It's
great if a company has time and money to do full, data-driven
personas. That takes time and planning and a lot of work (see
ginormous book I wrote with Pruitt). All the stuff in there is based
on almost a hundred practitioners' experiences. And guess what? most
of the time i do *no* data collection as you guys would define it.
NONE. that's right, none. Why? because most companies are so out of
whack when it comes to good design and simply talking to each other
that the most powerful thing they can do is smooth the communication
between the execs, marketing, design, and dev.

All of these people have tons of 'data' in their heads. of course
it's warped and full of wrong assumptions. But given no time, and a
good idea for a product (i know, i know, how do you know it's a good
idea, but c'mon. they all have ideas. we're there to help them take
action on the ideas in smart, well-designed ways), the best possible
solution, with the most startling results, is to create ad-hoc personas.

Again, why? because the process (not the final product of the
'persona documents' or whatever--but the *process*) gets everyone
aligned. I think that the only assumptions that can hurt a product
(if you are going to build a product based on assumptions, which,
face it, most companies do...and many of them are successful...i
agree with Robert on this) are the assumptions you don't know about.

If you can get the execs and stakeholders in a room and force them to
get their assumptions out on the table, several things happen:
1. they realize they are not on the coveted 'same page'
2. they realize that they have not thought about user goals
3. they realize that goals tend to 'straddle' other ways of
categorizing users, and thinking about goals is actually easier than
what they've been doing so far
4. they 'suddenly' realize they've been thinking about their product
in the 'wrong way' (inevitable)
5. they are able to agree on a basic set of ad-hoc personas based on
goals--very quickly, i might add.
6. they are able, when FORCED, to prioritize those personas based on
business objectives (it's all about business at this point.)

and, hey presto, suddenly they have seen the light. if we have time
for data collection for validation, great. if not, several delightful
things still end up happening:
1. the execs clarify (often after changing!) their business
objectives in terms of target user groups
2. the rest of the company suddenly has a snowball's chance of
understanding what the heck the execs want them to do.
3. the design and dev can get started knowing that, if the execs
change their minds, they can use the ad hoc personas to understand
what's going on (hey, you guys prioritized Suzie, right? well these
new ideas are all for Marvin, right? So does that mean you've changed
your mind about how important Suzie is?)
4. they're willing to do real data stuff next time.

So i see this all totally differently. To me, when i work with
companies, much to my surprise, the personas are a business strategy
tool, a means of prioritizing focus across the org, and a shared
language. Mazlov's pyramid--if you don't have these things, I think
your design is pretty much doomed, no matter what other tools you
use. And, btw, this is why I don't think it *ever* works to build
personas as a consultant and throw them over the wall into a client
org--yes, even if there is a major champion in the client org.

Let the flames commence.

--Tamara

design twice, build once Tamara Adlin adlin, inc.
tamara at adlininc.com 206.779.1776

27 Nov 2007 - 6:55pm
Todd Warfel
2003

On Nov 27, 2007, at 2:54 PM, Robert Hoekman, Jr. wrote:

>
> good design is much more probable when some sort of user centered
> research (especially when designing for an audience other than
> yourself) is conducted.
>
> I agree with the rest of what you said, but again, why *user*
> centered, as opposed to activity-centered or something else?
>
> -r-

I'm not really that concerned about the term that's used. Truth be
told, when we're designing at Messagefirst, we do goal oriented data
driven design. Every design decision we make is based on a business
goal, customer/user goal, and/or a piece of research data that focuses
on their behavior/activity. So, technically we do goal-oriented data
driven design, not user or activity centered design.

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
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

27 Nov 2007 - 7:01pm
Todd Warfel
2003

On Nov 27, 2007, at 3:23 PM, Robert Hoekman, Jr. wrote:

> I suppose you could argue that these conversations were "research",
> but they really weren't. They didn't lead me to figuring out how the
> site should work, they just led to the idea.

And it is. Just because you didn't intend to go there doing research
for a possible product, doesn't mean that's not what ended up
happening. Research is a discovery process. There are countless
accidental products that happened (e.g. PostIt Notes, Equal), but
those still happened in the process of trial, error, and discovery for
something else. Was a PostIt Note the original intent? Nope, but
someone created a not-very-sticky-glue that was "a failure" for their
original intent, but became useful for something else.

Accidents do happen, yes. And we can be "accidentally inspired" by
casual conversation. But you still discovered something that gave you
an idea for this new product/place/thing.

Research/discovery isn't always intentional.

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
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

27 Nov 2007 - 7:59pm
Robert Hoekman, Jr.
2005

> I feel like we do have choices Robert. There's UCD, under that
> umbrella are tons of tools, techniques etc at your disposal - no one
> is saying there is one way to conduct UCD.

Lots of people on this list have said similar things, but then many continue
beating the persona stick to death as thought it's the only sound solution.
It just gets so exhausting.

And yes, one could say that I'm only stressing myself out by arguing about
it all the time, but most of the time, I think it's a battle worth fighting.
UCD is simply unrealistic in a huge number of situations and we need to be
able to help the rest of the designers out there do effective work even when
they can't practice UCD the way we talk about it.

There's also usage centered
> design.

>From what I know, usage centered design isn't all that different than ACD,
so it's interesting that your bring that up. Has anyone here practiced usage
centered design? How does that process look? Does it involve personas? What
are the deliverables?

Or you can come up with ideas and design them based on your expertise
> as a designer and never ever do customer research. If your idea fails
> because you spent all your capital or resources developing a feature
> that no one uses or sees or understands anyway, that would be a shame.
> Bad UX can cripple the best product or service concept. UCD is a
> proven way to deliver high quality UX.

Proven only in certain situations, as practiced by certain people. It's not
fool-proof by any means.

What is it you feel is missing?

It's not that it's missing anything, it's that it *adds* a whole lot of
stuff that most teams just don't have time to deal with and is largely
unnecessary in many situations.

UCD - personas/scenarios in particular - work really well for consulting
firms and companies with money to burn. But personally, I have yet to work
with or for a company that has had the time, resources, or money to deal
with it. They want it now, and they want it great. At the root of what I
advocate is this simple fact.

All I want to do is find a method that helps people in those situations
instead of continuing to shove UCD and personas down everyone's throats when
it clearly cannot work in a huge percentage of projects.

-r-

Syndicate content Get the feed