Question on brainstorming personas

20 Nov 2009 - 2:25pm
4 years ago
11 replies
1587 reads
Wendy Fischer
2004

Guys,

I have a question on the methodology for personas -

I'm doing a project right now that we are trying to fastrack and get off the ground by doing some collaborative brainstorming with the product marketing folks. We haven't done any user research, have no budget for such research, we have no product requirements, etc. I'm supposed to have concept wireframes by mid december. The users are global and across a wide spectrum of socio/economoc strata and geographic locations.

So question, I'm following the following process for brainstorming around the interface:

1) Brainstorm Issues/problems we are trying to solve
2) Brainstorm user characteristics and then turn those characteristics into a couple of personas
3) From the personas, brainstorms goals, and user tasks.
4) Flow out the user tasks.
5) Start turning the tasks into a high level structure and either quickly brainstorm on a paper some drawing around either a vertical slice of the UI or a top level horizontal slice.
6) After the fact, go out and find users who fit the characteristics of the personas and either create new personas, or validate the pretend personas.

The whole idea is to get the team to think about who the users are, think about what the user's goals and tasks are, and create a personas that can then drive the rapid paper prototype process.

When I've done brainstorming where we are quickly doing design and have non-design stakeholders participating, I have used this technique several times with good results. I learned it over 10 years from designers who embraced the Inmates Are Running the Asylum Book by Alan Cooper. So some other designers in the brainstorming session did not like the technique, particularly around the personas, because they felt we were creating stereotypes. In addition, the designers felt that we should brainstorm the user goals and tasks first and have those drive how we create personas, not the other way around, i.e. Personas drive user goals, tasks. I've always done it the above way, and never had a problem with somebody question the methodology. I think that one of the issues is that we were stretching our knowledge a bit as we have users in emerging market countries, that we might not necessarily be as familiar with as say a country in the developing world, like
the US or the UK.

Obviously I'll admit I could update some of my methodology and learning- but I'm wondering, does anybody else follow this process? What literature is there out there that can validate this, other than the Inmates are Running the Asylum? What are good articles/books that outline a good process for generating personas, goals, tasks, and then interface designs in collaborative brainstorming sessions? Ginny Redish's User and Task Analysis come to mind, and The Bridge Method by Tom Dayton... Any ideas?

-Wendy Boucher-Fischer

Comments

20 Nov 2009 - 3:29pm
Fred Beecher
2006

Okay, this is going to sound snarky, but I'm very serious. Does your company
have time to release a product that doesn't meet user needs, fails in the
marketplace, and then needs to be re-thought and re-built? Because from the
situation you describe, it sounds like your management is setting this
product up for failure. Big time.

More helpful feedback below.

On Fri, Nov 20, 2009 at 1:25 PM, erpdesigner <erpdesigner at yahoo.com> wrote:

>
> 1) Brainstorm Issues/problems we are trying to solve
>

That's a very good idea.

> 2) Brainstorm user characteristics and then turn those characteristics into
> a couple of personas
>

That's a less good idea... what I think would be more effective here would
be to interview the business stakeholders about who (they think) their
customers are, or at least who they are targeting. You indicated that you're
working with product marketing folks here, so this shouldn't be too
difficult.

Note that you are *not* creating personas here... at best you're creating
customer profiles. Personas evolve out of observation. These profiles that
you'd be developing here would be most appropriate for driving research
participant recruiting... you want to do research with people who meet this
profile in order to see what personas emerge within the groups you're
interested in.

There is a huge caveat here though... it's entirely possible that the
business has no clue who their customers actually are or who they want to be
their customers. For example, I'm working on a project right now where we
were originally targeting two of five audiences. We made three 15 minute
phone calls to people we knew in the main target audience and we learned
that they are not, in fact, customers. We learned that an audience we were
specifically told to ignore by the client is in fact a major factor in
making purchasing decisions. And we also learned of a completely NEW
audience.

Can your company afford 45 minutes of research time? : )

> 3) From the personas, brainstorms goals, and user tasks.
>

I would actually add two steps here... first, you're presumably working with
some sort of content... some sort of noun. Video, reviews, datasheets,
whatever. I would spend some time brainstorming about what VERBS could be
done to that content... what are the possibilities that are out there?

Then spend some time thinking (NOT brainstorming!) about the sorts of
situations in which people that match your target profiles would want to
manipulate/interact with your nouns.

Then from there, I might take those profiles and contexts and think (NOT
brainstorm!) about which verbs people that meet those profiles might want to
perform based on the contexts in which they may occur

> 4) Flow out the user tasks.
>

Sure... but again, you'll never know if you don't observe, and that's a huge
risk of re-work after development, release, & failure.

> 5) Start turning the tasks into a high level structure and either quickly
> brainstorm on a paper some drawing around either a vertical slice of the UI
> or a top level horizontal slice.
>

Some super lo-fi paper prototyping will be your friend here. From what you
described, you know basically nothing... unsure about the users, no
requirements, nothing. That's the sort of situation that lo-fi prototyping
can be really useful in. It will help you determine whether you have
basically the right features and if the flows are right at a macro level.
It'll help you formulate an accurate overall structure. And it's real easy
to change once you learn stuff and iterate through multiple concepts. But
again, that's research, and you say your company isn't interested... man,
your management sure loves risk! : )

> 6) After the fact, go out and find users who fit the characteristics of the
> personas and either create new personas, or validate the pretend personas.
>

If you're planning to do this at this stage, why not do it at the beginning?
Yes, you say you need wireframes by mid-December... presumably that means
that people need to develop off of them. Why not make it early January and
then your wireframes will be a lot more accurate than if they're based on
"pretend" personas? If developers code off of inaccurate wireframes (no
fault of yours!) and you find that your personas, tasks, etc. are all pretty
wrong, then they'll have to go back & re-do what they just did and you'll be
at the same point in the schedule as you would if you'd done the research up
front.

> The whole idea is to get the team to think about who the users are, think
> about what the user's goals and tasks are, and create a personas that can
> then drive the rapid paper prototype process.
>

That's great and all, but it's frought with risk. Doing this is essentially
basing the whole structure of a design off of half-informed opinions. As
anyone on this list can attest to, that approach leads down a very dark
path. If you're planning to validate made-up personas with the target
audience anyway, you might as well do it first and save yourself a lot of
pain and heartache later on.

I think the best approach at this point is to seriously lobby your
management on this point: Research now or fail later and rebuild. Point out
the impact that this would have on customer loyalty. If you bought a big
software package that sucked, would you buy again from that company even if
they said they fixed it?

I really really hope you're able to turn them around. : )

F.

------------------------------------------------------------------------------------------
Fred Beecher
Sr. User Experience Consultant
Evantage Consulting
O: 612.230.3838 // M: 612.810.6745
IM: fbeecher at gmail.com (google/msn) // fredevc (aim/yahoo)
T: http://twitter.com/fred_beecher

20 Nov 2009 - 3:37pm
Mike Myles
2009

Rather than making up personas that you may validate later, I think
you'd do better to use User Roles - from the Usage Centered Design
approach by Constantine & Lockwood.

There is an in depth pdf on the subject here:
http://www.foruse.com/articles/rolespersonas.pdf

Good luck!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=47562

20 Nov 2009 - 4:04pm
bminihan
2007

Oh, my favorite kind of project =]

One way to reduce the amount of brainpower to follow your methodology for a
global, every-man system would be to reduce the size of your first-run
audience.

That is, if you don't yet know what the goals, tasks and workflows are, why
assume the first launch will hit 7 billion people the first day?

Why not make the assumption now that the initial audience will be:
US-centric, easily reached folks who are already interested in the concept,
if not financially interested in the viability of the project.

That's who your first month's audience will be, anyway.

>From there, establish some basic caveats to prevent painting yourself out of
a global audience (localized, lacking obscure cultural references, etc).

Make the 2nd run your global audience, and if the 1st was successful enough,
you'll get the funding to research the folks you're looking for.

Executives/Marketing Folks/Wonks often want to fast track projects and cut
out all the paperwork required to really define it properly. Yet when you
state (very realistically) that no just-launched app has every achieved its
visionary audience the first month, they call you crazy.

Bryan

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
erpdesigner
Sent: Friday, November 20, 2009 2:26 PM
To: discuss at ixda.org
Subject: [IxDA Discuss] Question on brainstorming personas

Guys,

I have a question on the methodology for personas -

I'm doing a project right now that we are trying to fastrack and get off the
ground by doing some collaborative brainstorming with the product marketing
folks. We haven't done any user research, have no budget for such research,
we have no product requirements, etc. I'm supposed to have concept
wireframes by mid december. The users are global and across a wide spectrum
of socio/economoc strata and geographic locations.

So question, I'm following the following process for brainstorming around
the interface:

1) Brainstorm Issues/problems we are trying to solve
2) Brainstorm user characteristics and then turn those characteristics into
a couple of personas
3) From the personas, brainstorms goals, and user tasks.
4) Flow out the user tasks.
5) Start turning the tasks into a high level structure and either quickly
brainstorm on a paper some drawing around either a vertical slice of the UI
or a top level horizontal slice.
6) After the fact, go out and find users who fit the characteristics of the
personas and either create new personas, or validate the pretend personas.

The whole idea is to get the team to think about who the users are, think
about what the user's goals and tasks are, and create a personas that can
then drive the rapid paper prototype process.

When I've done brainstorming where we are quickly doing design and have
non-design stakeholders participating, I have used this technique several
times with good results. I learned it over 10 years from designers who
embraced the Inmates Are Running the Asylum Book by Alan Cooper. So some
other designers in the brainstorming session did not like the technique,
particularly around the personas, because they felt we were creating
stereotypes. In addition, the designers felt that we should brainstorm the
user goals and tasks first and have those drive how we create personas, not
the other way around, i.e. Personas drive user goals, tasks. I've always
done it the above way, and never had a problem with somebody question the
methodology. I think that one of the issues is that we were stretching our
knowledge a bit as we have users in emerging market countries, that we might
not necessarily be as familiar with as say a country in the developing
world, like
the US or the UK.

Obviously I'll admit I could update some of my methodology and learning- but
I'm wondering, does anybody else follow this process? What literature is
there out there that can validate this, other than the Inmates are Running
the Asylum? What are good articles/books that outline a good process for
generating personas, goals, tasks, and then interface designs in
collaborative brainstorming sessions? Ginny Redish's User and Task Analysis
come to mind, and The Bridge Method by Tom Dayton... Any ideas?

-Wendy Boucher-Fischer
________________________________________________________________
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

20 Nov 2009 - 6:00pm
Wendy Fischer
2004

Just to clarify, this is more of a concept piece, not an actual product. We are trying to roadmap features and integration points for the next 18 months.

________________________________
From: Bryan Minihan <bjminihan at gmail.com>
To: erpdesigner <erpdesigner at yahoo.com>; discuss at ixda.org
Sent: Fri, November 20, 2009 1:04:59 PM
Subject: RE: [IxDA Discuss] Question on brainstorming personas

Oh, my favorite kind of project =]

One way to reduce the amount of brainpower to follow your methodology for a
global, every-man system would be to reduce the size of your first-run
audience.

That is, if you don't yet know what the goals, tasks and workflows are, why
assume the first launch will hit 7 billion people the first day?

Why not make the assumption now that the initial audience will be:
US-centric, easily reached folks who are already interested in the concept,
if not financially interested in the viability of the project.

That's who your first month's audience will be, anyway.

>From there, establish some basic caveats to prevent painting yourself out of
a global audience (localized, lacking obscure cultural references, etc).

Make the 2nd run your global audience, and if the 1st was successful enough,
you'll get the funding to research the folks you're looking for.

Executives/Marketing Folks/Wonks often want to fast track projects and cut
out all the paperwork required to really define it properly. Yet when you
state (very realistically) that no just-launched app has every achieved its
visionary audience the first month, they call you crazy.

Bryan

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
erpdesigner
Sent: Friday, November 20, 2009 2:26 PM
To: discuss at ixda.org
Subject: [IxDA Discuss] Question on brainstorming personas

Guys,

I have a question on the methodology for personas -

I'm doing a project right now that we are trying to fastrack and get off the
ground by doing some collaborative brainstorming with the product marketing
folks. We haven't done any user research, have no budget for such research,
we have no product requirements, etc. I'm supposed to have concept
wireframes by mid december. The users are global and across a wide spectrum
of socio/economoc strata and geographic locations.

So question, I'm following the following process for brainstorming around
the interface:

1) Brainstorm Issues/problems we are trying to solve
2) Brainstorm user characteristics and then turn those characteristics into
a couple of personas
3) From the personas, brainstorms goals, and user tasks.
4) Flow out the user tasks.
5) Start turning the tasks into a high level structure and either quickly
brainstorm on a paper some drawing around either a vertical slice of the UI
or a top level horizontal slice.
6) After the fact, go out and find users who fit the characteristics of the
personas and either create new personas, or validate the pretend personas.

The whole idea is to get the team to think about who the users are, think
about what the user's goals and tasks are, and create a personas that can
then drive the rapid paper prototype process.

When I've done brainstorming where we are quickly doing design and have
non-design stakeholders participating, I have used this technique several
times with good results. I learned it over 10 years from designers who
embraced the Inmates Are Running the Asylum Book by Alan Cooper. So some
other designers in the brainstorming session did not like the technique,
particularly around the personas, because they felt we were creating
stereotypes. In addition, the designers felt that we should brainstorm the
user goals and tasks first and have those drive how we create personas, not
the other way around, i.e. Personas drive user goals, tasks. I've always
done it the above way, and never had a problem with somebody question the
methodology. I think that one of the issues is that we were stretching our
knowledge a bit as we have users in emerging market countries, that we might
not necessarily be as familiar with as say a country in the developing
world, like
the US or the UK.

Obviously I'll admit I could update some of my methodology and learning- but
I'm wondering, does anybody else follow this process? What literature is
there out there that can validate this, other than the Inmates are Running
the Asylum? What are good articles/books that outline a good process for
generating personas, goals, tasks, and then interface designs in
collaborative brainstorming sessions? Ginny Redish's User and Task Analysis
come to mind, and The Bridge Method by Tom Dayton... Any ideas?

-Wendy Boucher-Fischer
________________________________________________________________
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

20 Nov 2009 - 6:40pm
Isabel Santafé
2009

Personas are supposed to come out of your data and not the other way
around.
You observe users in their context, you conduct some interviews if
need it, your talk to all the stakeholders, and then you are in a
position to really understand your user goals and needs and build and
archetype that you can call persona. There are not short cuts here,
user centered design is about user centered problems. How can you
brainstorm issues and problems without user research?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=47562

21 Nov 2009 - 12:21pm
Paul Bryan
2008

Understanding what real people will do when presented with your design
requires data. If you don't have budget for research, I suggest
taking a weekend to go to a place where people do whatever activity
you are designing for, observe them for a few hours, and jot down
attributes and behaviors that you feel are germane to the overall
context and experience. How do charcteristics like age, affluence,
preparedness, experience in the topic, flexibility, hurry, etc.
impact what they do?

The list you create from this activity is a starter set of attributes
and behaviors that you can bring into your exercise that might carry
more weight than making it all up. It doesn't cost you anything
other than a weekend.

Our approach to persona creation involves the step I described above,
but a few more as well. It's described in some high level bullet
points in this article:
http://www.virtualfloorspace.com/2009/09/user-archetypes-vs-personas/

If you want a ready-made persona to participate in your design
activities, feel free to use this one:
http://www.virtualfloorspace.com/2009/09/using-personas-to-guide-web-design/

Paul Bryan
Usography (http://www.usography.com)
Blog: Virtual Floorspace (http://www.virtualfloorspace.com)
Linked In: http://www.linkedin.com/in/uxexperts

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=47562

22 Nov 2009 - 12:57pm
Rachel Powers
2007

From my experience, your process is backwards. Before you map out flows and create personas, I recommend observing users first. The goal is to create a design that meets users goals and needs. Observe users in their context. The design process should help you to discover what the core problems are that need to be solved. I highly recommend reading the IDEO HCD Toolkit. Although it is geared for non-profits, the process works well.

http://www.ideo.com/work/item/human-centered-design-toolkit/

24 Nov 2009 - 11:58am
Fred Beecher
2006

On Fri, Nov 20, 2009 at 5:00 PM, erpdesigner <erpdesigner at yahoo.com> wrote:

> Just to clarify, this is more of a concept piece, not an actual product. We
> are trying to roadmap features and integration points for the next 18
> months.
>
>
Ah, that was not totally clear when I responded to your original post. This
makes me feel a lot better. : )

Still though, I'm unconvinced of the value of brainstorming personas even
early on in the process. If you're working with a group of other UX
designers, you should all be empathic enough to be able to put yourselves in
the shoes of people who might need to use the system you'd be working on.
I'm sure you have at least some idea who they could be... bankers? students?
tv fans? etc.

In the situation you described, the only thing I'd bother brainstorming at
the beginning is the nouns and the verbs... what sort of stuff will people
be working with? what sort of things will they need to do with it. Use that
empathy to winnow out the obviously useless stuff & then jump into paper
prototyping. Walking thru super lo-fi prototypes like that with other UX
designers pretending to be the audience will quickly show you whether you've
missed something essential & whether what you do have is useful.

That's been my experience anyway.

F.

------------------------------------------------------------------------------------------
Fred Beecher
Sr. User Experience Consultant
Evantage Consulting
O: 612.230.3838 // M: 612.810.6745
IM: fbeecher at gmail.com (google/msn) // fredevc (aim/yahoo)
T: http://twitter.com/fred_beecher

24 Nov 2009 - 2:13pm
jabbett
2008

Paul is right on.

In the middle of a big project this year, our client came to us with another
piece of software they were working on, but were having a hard time get off
the ground. They asked us to "do interaction design" to it, but there was
no budget or time for research.

What did we do? We did research anyhow. We took our own time to have coffee
with half a dozen people and talk to them about the problem space. It
quickly became clear, despite the informality and the relatively small
sample size, that the product concept was destined for failure. We reported
back to the client, they axed the product, and spent their resources in more
productive ways.

A victory for our team, and only possible because we talked to people.

Think of it this way: you are a painter, and your paint is user research.
Fancy brushes, canvases, or gallery space are useless without the paint.

-Jon

On Sat, Nov 21, 2009 at 4:21 AM, Paul Bryan <paul at usography.com> wrote:

> Understanding what real people will do when presented with your design
> requires data. If you don't have budget for research, I suggest
> taking a weekend to go to a place where people do whatever activity
> you are designing for, observe them for a few hours, and jot down
> attributes and behaviors that you feel are germane to the overall
> context and experience. How do charcteristics like age, affluence,
> preparedness, experience in the topic, flexibility, hurry, etc.
> impact what they do?
>
> The list you create from this activity is a starter set of attributes
> and behaviors that you can bring into your exercise that might carry
> more weight than making it all up. It doesn't cost you anything
> other than a weekend.
>

24 Nov 2009 - 9:18pm
tonyzeoli
2008

I'm getting ready to go through this very process with an investor who is
wondering whether the all-Flash experience he's been investing in will be
adopted by users once it's rolled out. They keep on building, never release
beta, and have spent a lot of time and money making assumptions with no data
to support. It's a huge all-Flash product. No idea why these guys bet on
Flash for the entire UI, but I'll soon find out.

I have a 5-day assessment schedule planned. The first morning will be spent
analyzing the product (I've already seen some screen and read the b-plan).
In the afternoon, I will meet with the four main stakeholders individually
and poses a set of prepared questions regarding the project, their
involvement in it, the assumptions made, technology implementation and more.

On day two, I'm preparing a small usability study with a few individuals
walking through a prototype and reviewing screen grabs. The budget is tight,
so I am planning on keeping it to 5 or so max, from the early adopter
through the person who was unlikely to use the technology, but may do so if
it's simple to use.

On day three and four it's market research--reaching out to other experts,
designers, programmers, etc...to get their take on where the market it
heading, what they've been working on and what they're thinking about.

Days 5 through 10 will be spent incorporating all this data into a
structured document with some recommendations as the best path to move
forward.

I'm not a buzzword guy, so please forgive the lack of catchy phrases and
terminology thrown around here on the list.

Best,

Tony Zeoli

On 11/24/09 2:13 PM, "Jonathan Abbett" <jonathan at abbett.org> wrote:

> Paul is right on.
>
> In the middle of a big project this year, our client came to us with another
> piece of software they were working on, but were having a hard time get off
> the ground. They asked us to "do interaction design" to it, but there was
> no budget or time for research.
>
> What did we do? We did research anyhow. We took our own time to have coffee
> with half a dozen people and talk to them about the problem space. It
> quickly became clear, despite the informality and the relatively small
> sample size, that the product concept was destined for failure. We reported
> back to the client, they axed the product, and spent their resources in more
> productive ways.
>
> A victory for our team, and only possible because we talked to people.
>
> Think of it this way: you are a painter, and your paint is user research.
> Fancy brushes, canvases, or gallery space are useless without the paint.
>
> -Jon
>
>
>
> On Sat, Nov 21, 2009 at 4:21 AM, Paul Bryan <paul at usography.com> wrote:
>
>> Understanding what real people will do when presented with your design
>> requires data. If you don't have budget for research, I suggest
>> taking a weekend to go to a place where people do whatever activity
>> you are designing for, observe them for a few hours, and jot down
>> attributes and behaviors that you feel are germane to the overall
>> context and experience. How do charcteristics like age, affluence,
>> preparedness, experience in the topic, flexibility, hurry, etc.
>> impact what they do?
>>
>> The list you create from this activity is a starter set of attributes
>> and behaviors that you can bring into your exercise that might carry
>> more weight than making it all up. It doesn't cost you anything
>> other than a weekend.
>>
> ________________________________________________________________
> 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

8 Dec 2009 - 1:16pm
Hugo Tremblay
2008

Chiming in late on the subject, not sure this will still be helpful.
Anyway, I just stumbled upon this and thought I'd reference it here
:
"Assumption Personas Help Overcome Hurdles To Using Research-Based
Design Personas"
http://www.forrester.com/Research/Document/Excerpt/0,7211,53874,00.html

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=47562

Syndicate content Get the feed