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.