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: [email protected] 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
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [email protected]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
