Patton user modeling

Personas,
Profiles,
Actors, &
Roles
Modeling users to target
successful product design
Jeff Patton
jpatton@acm.org
AgileProductDesign.com

Today we’ll cover these three areas
Understand:
 The user model’s place in a software
development process
 How to build simple relevant user models
 How to leverage a user model to make design
decisions
I hope to demystify what often seems a
confusing subject in software design
and development
© 2006-2007 Jeff Patton, All rights reserved,
2

3
Let’s look closer at
people and why they
user software

Norman’s simple model for a human
in pursuit of a goal
goal evaluation
is my goal met or problem
resolved?
4
problem or
goal
How I’d like to feel, or
what I’d like to achieve
take some
action
action evaluation
did that action deliver that results I
expected?
the world
information and tools

Distilling this down to goals, tasks, and tools
goal evaluation
is my goal met or problem
resolved?
5
problem or
goal
How I’d like to feel, or
what I’d like to achieve
the world
information and tools
take some
action
action evaluation
did that action deliver that results I
expected?
goal
task
tool

Software contains features that support a
number of tasks and a number of goals
goals
tasks
fetaotoulrses
6
software

Software products support a variety of users
and their goals.
goals
tasks
features
7
software

In organizations where users are paid to use the
software, user goals are driven by business goals
goals
tasks
features
8
software
All these goals
mean lots of tasks,
and lots of potential
features in our
software

Having a good list of users
helps us understand functional scope
How many different types of users will use this
software?
What goals will they be in pursuit of?
What tasks will they need to perform?
Which of those tasks will the software we design
support?
9

Look closer at the people engaged in using your tool –
what about them has relevance to the tool’s design?
What do your users know about using computers? -
assuming we’re building software
What do they know about the goal they’re
attempting reach? Have they done this before?
How often do they do this?
When and where are they when they’ll use the
software you design?
If they use other software like this – what
expectations might they have about your software?
Questions like these help us understand
characteristics our software should have to best
serve these users
10

11
How do we go about
describing users in the
most relevant way?

The humble “actor” gives a common name for
a user type
In use case modeling, actors are
people who interact with out system.
They’re often described using job titles
or a common name for the type of
user.
12
 accounts payable clerk
 manager
 cashier
 customer

The “role” names a relationship between a
user type and a process or a software tool
A user role general refers to a user’s
responsibility when using a piece of
software or participating in a business
process.
13
 AP voucher enterer
 administrator
 on-line payment checker

this conference
attendee, faculty
14
Both actors and roles name
a relationship with some entity
That relationship may be
between a person and:
 Their organization
 A business process
 A Software tool
 Any other entity
me
my family
PowerPoint
father, husband
my employer
employee,
consultant
tutorial creator

15
Both actors and roles name
a relationship with some entity
An individual may change their role as
their goal or responsibility changes.
Changing roles is like changing hats
For our purposes, that entity is the software
we intend to design
me – a user
PowerPoint
tutorial creator
tutorial presenter
low-fi UI prototyper

Roles decompose into finer grain roles
16
Consider the conference we’re attending
Conference attendee
 Tutorial attendee
 90-minute talk attendee
 Lunch consumer
 Break food consumer
 Wireless internet user
 Hotel guest
Each conference attendee role can be
decomposed to a role that more precisely describes
my goal or responsibility relationship with the
conference

enough talk:
Let’s practice thinking about roles
Software Development (SD) has come to you and
asked you to build them a better conference website.
This website will support potential attendees of
conferences such as SD Best Practices East, West, and
Dr. Dobb’s Architecture & Design World. It will need to
support the needs of potential attendees, speakers,
and SD employees who manage the conference.
In a small group – 3-4 people, brainstorm a list of
candidate roles for the system
Try using the form “thing-doer” such as “website
browser” or “presentation proposer”
Remember the primary rules of brainstorming:
 No discussion – just ideas
 Quantity matters more than quality
 Keep it fun – suggest silly roles
Timebox this to 5 minutes – the team with the most
roles wins
attendee
speaker
SD staff
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 17

Prioritizing user types is important
For the software tool we intend to build, which user types are
the most relevant to the design?
This depends on the business case.
Why is the software product being built?
What business objectives do we hope to achieve?
Which of these user types is it most critical that we support to
achieve our objectives.
Refer to these users types at primary, or focal
For a typical system, expect 2 or 3 focal users
18

Choose focal users – the users that best
advance SDs business objectives
With your group, choose 2 or 3 focal roles for the SD’s
new website.
“We need to add features to the website to
begin to build community all year round.
When people come to the conference, they
make valuable connections with each
other, we want them to build those
connections… to plan on coming next year
and continue to grow relationships.
The conferences drive SD.”
--Tammy

Profile users to identify relevant characteristics
about them
To help us understand the characteristics of our users that might have
bearing on our design, construct a profile containing information
about the type of user relevant to the software being created.
1. # of users that occupy this user type
2. General responsibilities or activities
3. Computer skills
4. Domain expertise
5. Goals: how does this software tool help this user
20
reach their goals?
6. Pain Points: what nagging problems can this
software help solve?
7. Usage Contexts: where will this software be used?
8. Software Ecosystem: what other software tools
does this user type rely on?
9. Collaborators: who does this user work with to
help reach their goals?
10. Frequency of Use: how often is this type of user
likely to use this software?

Creating profiles from assumptions and facts
Quickly creating profiles from assumptions allows us to find out
what we do and don’t know about our users.
There’s danger in basing critical decisions on software
functionality on assumptions. But, before allocating time to
research, the assumption based profile will help you estimate
how much research you’ll need.
Interaction designer that create personas from assumptions
refer them as and assumption-based persona, or a persona
hypothesis
21

Profile your users using assumptions
Choose one of your focal roles. As a group, for that role, discuss the
following characteristics and record them for your focal role.
1. # of users that occupy this user type
2. General responsibilities or activities
3. Computer skills
4. Domain expertise
5. Goals: how does this software tool help this user reach their goals?
6. Pain Points: what nagging problems can this software help solve?
7. Usage Contexts: where will this software be used?
8. Software Ecosystem: what other software tools does this user type rely
on?
9. Collaborators: who does this user work with to help reach their goals?
10. Frequency of Use: how often is this type of user likely to use this
software?
10 minutes

Backfill profiles with facts
Given assumption based profiles, you can identify
the areas where your information is sparse or
incomplete. You can use research to backfill your
profiles with facts in critical areas.
 Interviewing users from target user groups
 Observing users
 Questionnaires
 Existing published demographics
 Existing published research
 Customer service records and representatives
 Sales and marketing
 Usability testing
 Focus groups
23

Interview someone nearby
Interview technique: ask your interview subject to
recall a specific event and describe to the best of
their recollection how that event took place.
Ask them to describe their experience reviewing the
conference website before deciding to attend.
 Where were they?
 How long did it take?
 What computer equipment or software was used?
 What did they most enjoy about the experience?
 What was most annoying about the experience?

Distill your user model to communicate information
most relevant to the design of the software
Of the assumptions and facts gathered, what are
most relevant to the design of this software?
What could you remove to more concisely
communicate to:
 analysts
 UI designers
 developers
 business stakeholders
25

Personas make user data more tangible
Profiles contain general characteristics
about your groups of users.
A persona in an archetypal user that is
derived from specific profile data to
create a representative user.
A persona is more tangible, less
ambiguous, easier to envision, easier
to empathize with.
Personas with irrelevant or
stereotypical information in them will
damage user understanding and
empathy.
26
Jutta
Frequent Conference Speaker
“I really appreciate efficient
conference organizers – the ones
that value my time.”
Jutta has an over-stuffed conference
schedule speaking at over a dozen
conferences a year internationally.
She travels to US conferences from
Germany where she lives. She has
one published book and is working on
her second. Speaking at conferences
allows her to share her ideas with
others, promote her work, and network
with colleagues to share information
and experience.
Over the years Jutta has learned the
idiosyncrasies of various conference
presenters. - some are more efficient
than others. She appreciate those
that are early with reminders for due
dates and forthcoming with information
she needs to put together
submissions. She’s on some
conference website every month – but

Characteristics of a good persona
Name
A role or job title
Quotes in the personas language
Relevant demographics
Descriptions that reveals goals, motivations, pain points
Descriptions that describe primary activities this user type will
engage in.
27

Build a simple persona from your profile data
Include:
 Name
 A role or job title
 Quotes in the personas language
 Relevant demographics
 Descriptions that reveals goals,
motivations, pain points
 Descriptions that describe primary
activities this user type will engage in.
your details here

29
You’ve built several
types of user models…
congratulate yourself.

30
How do we make this
user model relevant?

Feature opportunities describe the good ideas the
good ideas that result from thinking about your users
As you discuss, speak with, and observe your users,
you’ll get great ideas for product features – features
that will really help your users.
Include these feature opportunities in your profile or
persona
31

Design imperatives describe good characteristics the
software should have based on the user type
Inside your user profile are clues about the type of
user interface and user interface characteristics
needed by your user.
Document these as design imperatives.
Think about:
 ease of learning
 retention of learning
 efficiency of interaction
 reliability of interaction
 user satisfaction
 user convenience
 necessity for proficiency
 importance of accuracy
32

Discuss and record feature opportunities and
design imperatives
What feature opportunities are
particularly valuable to this user
type?
What characteristics must the
design have to be suitable for
this user type? (design
imperatives)
 user satisfaction
 user convenience
 necessity for proficiency
 importance of accuracy
 ease of learning
 retention of learning
 efficiency of interaction
 reliability of interaction
* Source Constantine & Lockwood Ltd.

34
User modeling distilled
1. Identify actors or roles - take your pick, or mix as you see fit
2. Prioritize based on relevance to the product’s business
case
3. Profile to identify details relevant to design
4. Personify to better communicate user types
5. Identify feature opportunities
6. Identify design imperatives
7. Communicate your user model with their relevant feature
opportunities and design imperatives – this communicates
the relevance of your user model

35
Why aren’t user models
commonly built?

Self-referential design is the behavior we all
revert to
36
User models help us understand why
our users aren’t us.
Much of software is built by
organizations where employees are
the target users. In situations where
individuals within the company are
example users, it’s tempting to avoid
user modeling
This is “for-us-by-us” software

User models are often not leveraged
Leverage your user models
 Prioritize them to help with adding or removing functionality from
scope
 Identify user test subjects
 Identify alpha/beta testers
 Compare them with your eventual actual users to identify bad
assumptions and new user constituencies
 Post them in the area your team works to help team members
empathize with target users and make better tactical design
decisions
37

User models create a common design target
Avoid arguments about what the
users want or could best use by
pointing to the user model.
Target the user model
38

39
We design and build
software to create value
for the business that
pays for it.

40
Value doesn’t usually
come from the delivery
of the software, but from
the use of the software.

41
Understanding users is
critical to getting value
out of our software.

42
Modeling users is a
simple first step to
clearly communicating
our design target to
everyone involved in
software design and
development.

Personas,
Profiles, Actors,
& Roles
Modeling users to target
successful product design
Jeff Patton
jpatton@acm.org
AgileProductDesign.com

Patton user modeling

More Related Content

What's hot (11)

Viewers also liked (20)

Similar to Patton user modeling (20)

Patton user modeling