The goal is to develop a precise description of your user(s) and what he wishes to accomplish.  A good persona will enable you to build a product that solves a real problem and that people love.

• What motivates the users?
• Why are they really using the system?
• What are they really trying to accomplish?

Persona Elements

• 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)

There are a variety of persona formats along with the information they contain.  This list describes a basic set of information to include in your persona.  See Persona Format for more examples of data to include in your persona.

Creation Guidelines

• 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)

• Not means to an end - be careful to capture the end goals rather than goals that are a means to an end.  A good test to decide if you have identified an end goal is to continually ask the question "why is this important?".  If there is an answer, you have not identified the root goal yet.  Some examples of "fake" goals are:  save memory, save keystrokes, speed up data entry, be easy to learn, use cool technology or features.  They may want to speed up data entry because they want to get out of the office on time and get home to their family.  Or they may want to use cool technology because they want to be seen as the cool gadget guy on the cutting edge.

• Avoid a real person - create an archetype which allows you to describe a group of people with common goals, attitudes, contexts, etc.  creating a persona based on just one person will focus on individual idiosyncrasies which will not lead to a widely usable system.  See Persona Pattern Exercise below for more on this.
• Be precise and 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 get confused by multiple browser windows or tabs.  You should not assume that because they do one thing well on the computer that translates to everything that can be done on computer.
• User persona not a buyer or manager (of users) persona - it is tempting to design for the person making the buying decision but they are usually not the person (people) that will be ultimately using the application.  Managers don't always understand the details of how work really gets done which is critical to a good persona.  Make sure to talk to the people that will be using the product, not just their manager.
• Personas are contextual - they should be specific to your particular problem space and application or service.  This is a scoping issue and is a difficult balance to find.  In today's world the lines are blurred between work and life and most people do multiple jobs which all affect each other.   It is important to stay within you particular problem space as much as possible to enable focus.
• Expect 3 - 12 personas for an average size project - this is an average and the number really depends on your project specifics.  Cooper, et al discuss the right number of personas in detail in the About Face books.

A Creation Process

Check out the Other Resources section for more perspectives and processes on the persona creation process.

Begin with Investigation

Ideally you want to visit potential users where they do their work.  On the Fluid project we tend toward Contextual Inquiries since they give us an opportunity to ask interview style questions and watch users actually do their work.  You can find information about a variety of other user research methods in the Design Handbook or on the web.

No time for user research, see the Provisional Persona side note.

If you can, meet with everyone on the project:

• Users
• Sponsors
• Managers
• Trainers
• Others that depend on the product's results/data/etc. (but may not use the product directly)

to get a broad perspective of the the project goals & needs.  You may decide to create personas for people other than end users (see Persona Categories) to represent important perspectives or must haves needed to make the project successful (even if they aren't useful for the end users).  We will focus on end users personas here.

We created a User Matrix for a recent research project to help us identify the variety of types of end users we wanted to talk to.

See User Research sections of the Design Handbook for more detailed information on gathering data about users.

Identifying Personas - Synthesizing the Raw Data

Now that you have all this rich, raw data from your investigation, what do you do with it?  Raw notes are hard to digest and it is nearly impossible to jump right from raw notes to persona creation.   Begin to digest your notes in phases. 

Note that it can be very beneficial to do these exercises in the pair that did the research (assuming you had a research team).

1. Summarize your notes

• 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?

2. Identify important/interesting distinctions between users

Jarod Spool at User Interface Engineering (UIE.com) recommends using a Two by Two Comparison for this:

• Read 2 randomly chosen summaries
• List attributes that make interviewees similar and different
• Replace one of the summaries with another randomly chosen one
• Repeat until all summaries are read

Here's an example of the kinds of distinctions we identified between faculty we met with for the Content Management Research Project:

3. Choose endpoints

Next, you need to identify the end points for each distinction to create scales allowing you to compare your participants.  The scale should be based on the lowest and highest level of the people you talked you since this is what we are interested in.  So if you interviewed 20 very technical people, the bottom of your scale for technical expertise would not be novice like you see in the scale below.  Instead you need to come up with a low endpoint that describes how the least technical person is different from the most. 

This is another example from the Fluid Content Management Research Project.   It is one of the persona scales we created for the Instructional Support Staff we met with.  You'll notice that for some, scales didn't make sense so we use buckets, as in the first scale "attitude towards technology".

 

4. Put each research participant on each of the scales

Once your scales are set up, place each participant you talked to on the scale.  In the above example we used initials.  You could also use numbers or any other mechanism for depersonalizing them.  And of course, shorter more easily fits on the scale.

See examples above and below and the rest of the models created for the content management research.

5. Identify common Patterns: these are your initial personas!

The next step is to look for patterns of people that tend to fall together on the scales.  You are identifiying participants who will become part of the same personas because their goals, needs and behaviors are similar enough.  They don't need to be exactly alike just similar enough that their needs for your product can be represented by one persona.  You'll likely have some hypothesis about this going in if the same people were involved in all the user meetings.

Here we used different colored pens to help us see the circles.  It's a little tricky to see our circles but you can get the idea.   PC and WW feel together often as did MB and SV.

 

6. Write your Personas

Start minimally.  Since you'll have many more personas to begin with than will end moving forward with you on your project, keep the initial iteration draft-y and simple. We tend to use bullet points in the beginning with just enough detail to help us talk through choosing your primary and secondary personas.  Goals and some description of activities that will touch your product are probably enough.  Once you've chosen the personas to focus your design on, you'll want to flesh them out.  See the Fluid Personas and the Persona Format for examples of what your personas might look like.

Note that for the Fluid personas, we fleshed out all of our initial personas including auxiliaries.  There are 2 reasons for this.  The first is that since we are building reusable components on Fluid the problem space often changes and so may the primary and secondary personas.  The 2nd is we also wanted to represent the diversity of user archetypes we find on Higher Education campuses for reasons outside design.