Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 22 Next »

This Summary is Still In Progress

Documenting the persona creation process is still in progress. We'll continue to flesh this out and add details as time permits.

"No matter what we are designing, building, or helping to build, we want our products (including software, hardware, consumer goods, and services) to be useful, appreciated, and profitable. We want to help create products quickly and cost effectively, but with the right set of features and good quality. We want these products to hit the market and instantly inspire demand, desire, and loyalty. We want people to use our products repeatedly and happily, encountering just the right functions at the right times and finding that the products grow with them as they develop expertise. We want our efforts to result in products that delight people, and to delight people we have to have some idea of who these people are and what they want." - "The Persona Lifecycle" , John Pruitt & Tamara Adlin

Persona usually contain...

  • Goals
  • Attitudes (related to your context)
  • Behaviors & Tasks (in your context) 
  • Name
  • Photo
  • Tagline
  • Demographic Info (brief just to help "humanize" them)
  • Skill level
  • Environment
  • Scenarios (not all but perhaps the highest priority, most common or most telling about their needs)

Goals (not Tasks)

Goals are the reasons users perform tasks.  Tasks change as technology changes but the underlying goals remain stable. 

Users may have a variety of kinds of goals. Your project will drive the kinds of goals you want to capture. Some examples are:

  • Practical Goals (e.g. avoid meetings, be efficient)
  • Personal Goals (e.g. not feel stupid, get an adequate amount of work done, have fun)
  • Business Goals (e.g. increase student enrollment, get good professors, quality education)

Be careful to capture the end goals rather than goals that are a means to an end (e.g. save memory, save keystrokes, speed up data entry, be easy to learn, use cool technology or features).


Basic Principles for creating Personas

  • Avoid a real person - Create an archetype which allows you to describe a group of people with common goals, attitudes, contexts, etc.  See Persona Pattern Exercise below for more on this.
  • Be precise - more important than being accurate
    Unknown macro: {why? - add some description here}
  • Don't oversimplify - the details will matter. For instance, they may be a spend a lot of time texting friends and be a wiz at Facebook but gets confused by multiple browser windows or tabs
  • User persona not a buyer or manager (of users) persona
  • Personas are contextual and specific to the particular problem space and application or service.

Getting Started

Begins with Investigation

  • Site Visits
  • Interviews
    • Everyone on project: Sponsors, Managers, Workers, Users
    • Job Shadowing
    • Contextual Inquiries
    • Previous data & research
  • Create many initially...narrow them down...

Identifying Personas - Synthesizing the Raw Data

  • Who are these people?
    • Skills, abilities and interests
    • Business goals
    • Relevant personal goals
  • How do they relate to technology?
    • Highly skilled developer who sounds like a dolphin?
    • Technophobes who won't even look at a monitor?
    • Something in between? 

Diagrams and instructions to come.... ]

Provisional Personas

A provisional persona is a persona created using historical, anecdotal, or statistical knowledge about a certain type of user, but is not based directly on patterns seen in user research. Provisional personas can be a helpful tool for capturing the team's knowledge about users when talking to actual end users isn't possible. However, they should be used with caution as they may not be entirely accurate or representative of the user population. When creating personas, we recommend performing some type of research with actual end users whenever possible.

  • No labels