- - 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:
- 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.