Do business objectives belong in personas?

26 Feb 2009 - 6:10pm
5 years ago
11 replies
779 reads
tdellaringa
2006

We're working on building some personas for some desktop software.
I've been going over Todd Warfel's template and Steve Mulder's
(The User is Always Right).

Steve includes Business Objectives, Todd does not. The argument is
that you want to include what you as an organization want to
accomplish.

I guess I would argue that a persona is not about my organization and
it's goals, it's about the person and their goals. And if I am
satisfying their goals, that's going to be good for my org and my
software.

Am I missing something as to why they should be included? Love to
hear your thoughts.

Comments

26 Feb 2009 - 6:33pm
Katie Albers
2005

This is something that I've run into before, and here are my thoughts
on it.

1) to include business objectives in a persona is to build in the
assumption that your customers care about your business. They do not.

2) The underlying reasoning -- to my mind -- to build a persona is to
provide a "purer" means for understanding what your customers want and
how they can be expected to behave. Including business assumptions
shoots that down immediately.

3) If you build in business objectives, you are saying that your
customers are the same as your stakeholders. If this is true, fine.
Otherwise, forget it.

4) Why bother having personas at all if all they're really going to
tell you is what you want to do? It seems a pointless exercise.

In 97% of all cases (and yes, I made that number up) your customers
will have exactly zero interest in your business objectives. The goal
of User Experience and Interaction Design is to develop methods
whereby the customer goals will coincide with the business goals as
naturally as possible, so that the customer doesn't get the sense that
their behavior has to suit your business needs or that they have to
"qualify" to give your business money.

The most valuable thing personas can do for you is to tell you that
you're approaching the wrong market or the wrong customer or using the
wrong method. If they can't deliver that information then they
necessarily make it possible for you to go merrily on your way
spending time, money and effort developing things that your
marketing division can market to people who don't want them. Building
in business objectives pre-supposes acceptance and compliance.

I think I've said that enough ways, now.

Katie

Katie Albers
Founder & Principal Consultant
FirstThought
User Experience Strategy & Project Management
310 356 7550
katie at firstthought.com

On Feb 26, 2009, at 3:10 PM, Tom wrote:

> We're working on building some personas for some desktop software.
> I've been going over Todd Warfel's template and Steve Mulder's
> (The User is Always Right).
>
> Steve includes Business Objectives, Todd does not. The argument is
> that you want to include what you as an organization want to
> accomplish.
>
> I guess I would argue that a persona is not about my organization and
> it's goals, it's about the person and their goals. And if I am
> satisfying their goals, that's going to be good for my org and my
> software.
>
> Am I missing something as to why they should be included? Love to
> hear your thoughts.
> ________________________________________________________________
> 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

26 Feb 2009 - 10:16pm
Jared M. Spool
2003

On Feb 26, 2009, at 3:10 PM, Tom wrote:

> Steve includes Business Objectives, Todd does not. The argument is
> that you want to include what you as an organization want to
> accomplish.
>
> I guess I would argue that a persona is not about my organization and
> it's goals, it's about the person and their goals. And if I am
> satisfying their goals, that's going to be good for my org and my
> software.
>
> Am I missing something as to why they should be included?

Hi Tom,

Excellent question. Here's my take:

First, I want to ask: are we talking about whether the business
objectives are in the persona or with the persona description document?

A common mistake that people make is they confuse the persona
description document with the actual persona. Personas exist as a
shared meme in the minds of the team members. The persona description
document is an artifact the team users to create and maintain that
meme. It's an important distinction, because the persona description
document is not the end goal -- it's the means to the end.

When we work with teams to create personas, we help them create the
description document. In our work, we recommend that every sentence in
the description document have a direct connection to a design outcome.
For example, if the document describes that the persona has two pit
bulls and drives Chevy Suburban, the team needs to have a rationale as
to how those facts will impact the design.

(In personas we worked on with the Home & Garden TV network, the dogs
influenced decisions about pet-friendly home improvement & landscaping
projects and the car influenced decisions about the size & quantities
of supplies transported.)

So, because the construction process for the persona descriptions
involves talking about design impact, the business impact becomes an
undercurrent. I think there's really no way to separate them out.

That said, the question then becomes: do you list explicit business
objectives along side the persona descriptions? I think the answer to
this has to do with how well the team is on the same page with the
business objectives.

Some teams we work with all inherently understand their business's
objectives clearly. No need to reiterate them here.

However, some teams have a diverse project portfolio or conflicting
business objectives. In this case, I think clearly stating the
business objectives behind the specific persona development makes a
lot of sense. It will help guide the conversation around the project,
ensuring better adoption of the personas going forward. It also helps,
when business objectives shift, to understand if the personas are
still meeting their original goals.

I don't think it make any sense to explicitly exclude business
objectives at any point in the design process. And reiterating them
frequently through the project, in various deliverables, can help
remind everyone what the goals are.

(I think it was Cameron Moll who had the idea of replacing "lorem
ipsum" in design comps with the business and project objectives. I
think that's brilliant.)

This doesn't mean that you make the persona description and the
scenario descriptions explicitly talk to the goals. The persona is
still going to be about the target user's goals and behaviors.
However, if the team members can't draw the lines between how
something is good for the user and good for the business, then there's
likely to be a conflict later in the design process. The connection
has to be there, whether explicit or implicit.

Hope that helps,

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

27 Feb 2009 - 4:06am
Joshue
2009

@Tom I guess I would argue that a persona is not about my organization and it's goals, it's about the person and their goals. And if I am satisfying their goals, that's going to be good for my org and my software.

I agree. I think putting organisational goals into your persona would pollute them to a large degree and render them less ecologically valid as a tool.

Cheers

Josh

27 Feb 2009 - 10:14am
tdellaringa
2006

On Thu, Feb 26, 2009 at 9:16 PM, Jared Spool <jspool at uie.com> wrote:

> Hi Tom,
>
> Excellent question. Here's my take:
>
> First, I want to ask: are we talking about whether the business objectives
> are in the persona or with the persona description document? [snip]

I was mainly speaking to the document, but your response definitely
addressed that. Thanks a lot, it's very helpful!

Tom

--
Marooned - A Space Opera in the Wrong Key!
http://www.maroonedcomic.com

27 Feb 2009 - 10:24am
Mark Schraad
2006

I usually work with specifically grouped information in separate docs.
Market research (competitive analysis etc), User needs and behaviors
(including personas), and Biz requirements (sometimes including technical
constraints, but sometimes its better as a fourth bucket). The reason I keep
these separate is that I like to NOT have ownership of these, but have them
provided buy subject experts, kept current and then I utilize them in the
design process.
Mark

On Thu, Feb 26, 2009 at 6:10 PM, Tom <pixelmech at gmail.com> wrote:

> We're working on building some personas for some desktop software.
> I've been going over Todd Warfel's template and Steve Mulder's
> (The User is Always Right).
>
> Steve includes Business Objectives, Todd does not. The argument is
> that you want to include what you as an organization want to
> accomplish.
>
> I guess I would argue that a persona is not about my organization and
> it's goals, it's about the person and their goals. And if I am
> satisfying their goals, that's going to be good for my org and my
> software.
>
> Am I missing something as to why they should be included? Love to
> hear your thoughts.
> ________________________________________________________________
> 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 Feb 2009 - 10:20pm
Jeremy Kriegel
2009

A successful project has to balance user goals and business goals.

I agree with Jared that it is important to be able to draw clear
connections between the two. Seeing where the goals align will point
to your easiest wins. When they are in conflict or merely skewed from
one another, there will be design challenges.

Solving only the user's problems = fail
Solving only business' problems = fail

-Jeremy Kriegel
www.methodsansmadness.com

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

2 Mar 2009 - 10:14am
tdellaringa
2006

Thanks everyone for the great answers. I have a follow up question.
The colleague that has put together the initial persona sketches has
included a couple of attributes that are specifically geared toward
selling the end product.

Specifically, for example, he created one called "Decision Maker"
that he explains the purpose as "Links to the selling process that
we use (if any). Likely candidates are: SPIN, Solution Selling, or
Strategic Selling. Agree regarding the goals. "

Here's how that is articulated on one of the personas:

"Can voice a %u201Cno%u201D and make the selling process more
difficult. Requires overcoming specific objections. Will share
experiences with the Marketing Director, and likely to be the person
to show the Marketing Director how to use the system or outcome from
the system. "

Again I'm thinking - this doesn't belong. It seems like that
information could be included in the personal profile section, if at
all? Basically we can say they are an influencer in decision making?

It seems to me a persona is not about selling, it's about designing
properly. And if we design properly, we won't have to concern
ourselves with how the sales force is going to sell it, because it
will satisfy our target user needs and they should want it.

I'm having a hard time articulating myself on this one, especially
with my colleague, and I feel like he may dig his heels in on this
one.

I'm really not sure how I would go about using what he wrote there
as part of the design process. It's good to know they may have a
certain effect on the decision making process, but again - if I've
understood his needs and met them with my product... I'm just
repeating myself now.

Thoughts?

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

2 Mar 2009 - 1:48pm
oliviacw
2008

On Mon, Mar 2, 2009 at 7:14 AM, Tom Dell'Aringa <pixelmech at gmail.com> wrote:
> It seems to me a persona is not about selling, it's about designing
> properly. And if we design properly, we won't have to concern
> ourselves with how the sales force is going to sell it, because it
> will satisfy our target user needs and they should want it.

We've successfully developed and used both design personas and
marketing personas. Design personas address user needs and goals
during an individual's use of the product, and are strictly focused on
design considerations.

On the other hand, marketing personas address the decision-making
environment in which the person will be considering product
acquisition or service selection. This includes information sources,
technical context, and so on. Like a design persona, it also
addresses user goals and needs, but with the perspective of "what is
the value proposition that will speak to this person?" Marketing
personas may also be developed around roles that may never be actual
product users, such as corporate purchasing agents or IT staff.

I find it best to separate the design and marketing personas.
Otherwise, you tend to load too much onto a single document, and
create confusion for persona users with different roles in the
company.

- Oliva

--
Olivia C. Williamson
User Experience Architect
White Horse Productions

ocwilliamson at gmail.com
650-305-5950

2 Mar 2009 - 1:48pm
oliviacw
2008

On Mon, Mar 2, 2009 at 7:14 AM, Tom Dell'Aringa <pixelmech at gmail.com> wrote:
> It seems to me a persona is not about selling, it's about designing
> properly. And if we design properly, we won't have to concern
> ourselves with how the sales force is going to sell it, because it
> will satisfy our target user needs and they should want it.

We've successfully developed and used both design personas and
marketing personas. Design personas address user needs and goals
during an individual's use of the product, and are strictly focused on
design considerations.

On the other hand, marketing personas address the decision-making
environment in which the person will be considering product
acquisition or service selection. This includes information sources,
technical context, and so on. Like a design persona, it also
addresses user goals and needs, but with the perspective of "what is
the value proposition that will speak to this person?" Marketing
personas may also be developed around roles that may never be actual
product users, such as corporate purchasing agents or IT staff.

I find it best to separate the design and marketing personas.
Otherwise, you tend to load too much onto a single document, and
create confusion for persona users with different roles in the
company.

- Oliva

--
Olivia C. Williamson
User Experience Architect
White Horse Productions

ocwilliamson at gmail.com
650-305-5950

2 Mar 2009 - 10:14pm
Jared M. Spool
2003

On Mar 2, 2009, at 7:14 AM, Tom Dell'Aringa wrote:

> "Can voice a 'no%' and make the selling process more
> difficult. Requires overcoming specific objections. Will share
> experiences with the Marketing Director, and likely to be the person
> to show the Marketing Director how to use the system or outcome from
> the system. "

Hi Tom,

Have you asked your colleague what he wants to use this persona for?
Can he give examples on how this might change the design?

Out of curiosity, are the personas your designing for general
functionality or are the purposed for specific functionality?

Have there been specific research to inform the personas? Has your
colleague collected data from actual individuals that show that the
attributes of the "decision maker"?

From what you've said, it sounds to me like he's describing a
Technical Buyer right out of Miller / Heinman's Strategic Selling.
This doesn't really sounds like a persona attribute as much as it is a
role description. I've found role descriptions to be less helpful in
informing design decisions.

As I mentioned before, I advice our clients to use a very specific
razor on every sentence in the persona description: can they describe
how that sentence will alter the outcome of the design from other
alternatives?

If there was a scenario that involved a free trial period or a
interactive demo, I could see this being the start of a useful
description. But it's probably lacking because it doesn't describe how
the persona might investigate objections or what they'll be looking
for in the process.

Getting beyond the role and into specific behaviors of the persona
(hopefully based on actual observed behaviors of potential technical
buyers in sales scenarios) will help tremendously iron this out.

If, on the other hand, this isn't from research and is fabricated from
a perception of what the sales process is like, it would be a red flag
to me that you and your colleague don't really have enough information
to do this justice. You can either decide to invest in the research,
you can decide to let the fabrication go through (and probably weight
it less than anything else in a pick-your-battles strategy), or you
can decide to suggest you remove it from the persona until you have
data.

Hope that helps,

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

3 Mar 2009 - 10:08am
tdellaringa
2006

On Mon, Mar 2, 2009 at 9:14 PM, Jared Spool <jspool at uie.com> wrote:

> Have you asked your colleague what he wants to use this persona for? Can he
> give examples on how this might change the design? [snip]

Ok, sparing the mundane details of interoffice juggling, it turns out that
the personas he is using are not the ones that I will have to use. I'll be
able to create my own, and I am planning on using user research to base them
on. (Getting that is another internal issue, but I'm hopeful).

So sorry for the detour, but I still learned some good things from
everyone's comments, so thank you.

I guess that brings me back to my original question about biz requirements
and I think the situation here dictates leaving them out.

Right now I'm going to base my personas on Steve Mulder's book, with a bit
of cross pollination from Todd Warfel's template. If there are any
suggestions on persona stuff I should look at before I begin, that would be
appreciated.

Thanks!

--
Marooned - A Space Opera in the Wrong Key!
http://www.maroonedcomic.com

Syndicate content Get the feed