Personas
This section contains course syllabus regarding personas. The following should be read and understood in order to create a persona.
-
A Persona is a fictional but realistic human being using some
device, application or service to be created (“the target”).
-
The persona is prototypical for a real group of users, their
goals/desires, capabilities/limitations, and activities/usage
profiles.
-
The persona technique has been created in 1995 by A. Cooper as a tool to
ensure usability of applications/devices by addressing the needs of concrete
users rather than just offering unstructured sets of functionalities.
-
Find more information here.
-
Browse around www.cooper.com and look for “Stratus Air” and “Persona”.
-
A. Cooper: The inmates are running the asylum. SAMS, 1999.
-
J. Pruitt, T. Adlin: The Essential Persona Lifecycle. Morgan‐Kauffman, 2005.
Application conditions for Personas
-
Personas are useful at many stages.
-
While exploring the solution space and eliciting requirements, using
personas allows us to compare/contrast alternative usage scenarios to
inform the ongoing design in terms of features, interactions, and the visual
appearance of a target system.
-
After completing a design process, Personas may be used to communicate
(intermediate) results of a design process to customers or sponsors.
-
During the implementation, Personas transport knowledge about future
users to the developers.
-
Personas require relatively little initial effort, and is generally a
powerful and generic communication tool.
-
However Personas are inherently subjective and it may be
difficult to assess their quality (e.g. level of detail, when to stop).
Persona Structure
-
A persona set contains 3‐10 personas depending on the number
of user groups, not necessarily on system size.
-
Each persona should be described on approximately 1 printed
page with the following items.
-
Heading.
-
The heading should set the context (case study, author, possibly a title).
-
Why is this persona relevant, what class of users does it represent
-
Outline
-
Name, Picture
-
Age, Gender, Job/Position
-
Capabilities and restrictions, objectives and goals, skills, attitudes (as far as relevant)
-
Story
-
A short story of this person interacting with the target system in a particular way.
-
If relevant, interactions with other people or systems may be included.
-
The story may contain a few additional fictional personal details to make the persona more
realistic, and to make it easier for readers to identify with the persona.
How To Create Personas
-
Design a set of drafts first using creativity techniques
-
only a few details, use e.g. Brainstorming, 6‐3‐5, or Mindmapping
-
Then do a first version for each of them.
-
If used to communicate market analysis, personas are typically synthesized
from interviews conducted with users.
-
If used as an explorative device, personas are mainly based on the
imagination and creativity of the developers. Creative writing techniques are
useful here.
-
Merge/split personas as appropriate, go back to start if necessary
-
Improve and elaborate personas
-
Quality assurance
-
Do a peer review using the CCCP criteria.
-
Improvise a role play based on a persona, in particular if it involves
interactions with other people and/or systems.
Persona Quality Criteria: CCCP
-
Concrete
-
Be very concrete and realistic in your persona description (real names,
places, dates, people). Eliminate generalizations or abstract descriptions.
-
Be detailed in your description, but add only (!) detail that will either make
your persona.
-
Adding some detail to make the persona more colorful is fine, if it helps
clients relate to the persona. However, the details should be representative
and not distract from the usage description.
-
So, do not use pictures or names that have a connotation, e.g. famous persons, characters
from the literature, yourself, your colleagues, or your customers. Do not use exotic, rare, or
seemingly funny names and places.
-
Correct
-
Ensure that there are no spelling mistakes or colloquialisms.
-
Ensure a consistent style across the whole set of personas (e.g. either all
British or all American English).
-
Ensure that each persona and also the whole set satisfy the CCCP criteria.
-
Complete
-
If used as a requirements elicitation device, the set of personas should
represent all major groups of system users.
-
Ensure that each Persona contains all required parts.
-
The story of each persona should be self contained and carry on until there is a natural
ending of the usage process (not necessarily the whole business process).
-
All usages should be contained in some persona story.
-
A substantial persona will contain approx. 1 printed page
-
Precise
-
Be precise and to the point. Eliminate slack, unnecessary detail, and
fuzziness.
-
don’t waste precious time. Your clients are busy people and they hate to wait or waste
time.
-
Write about all relevant personas, but no more.
-
If there are too many user groups, try to merge some of them. If that is not possible, focus
on the most relevant.
-
Do not write about stakeholders but users.
-
Try to reduce the overlap between the persona stories.
-
Ideally, each pair of personas is disjoint, but some overlap is typically unavoidable.
Mistakes to avoid
-
Don’t omit elements unless you have a good reason.
-
Don’t choose weird pictures, places, or names.
-
Don’t choose real people as your personas, or characters from
literature.
-
Don’t make fun of your persona.
-
Don’t let somebody check your persona without removing simple
mistakes first (spelling, format, style, correctness).