- Platform for Economic Inclusion
- Preference Editing Tools Design
- Fluid Infusion
- Design Handbook
- Social Justice Repair Kit
- BIG IDeA
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 which solves a real problem and that people love.
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.
Check out the Other Resources section for more perspectives and processes on the persona creation process.
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:
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.
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).
Jarod Spool at User Interface Engineering (UIE.com) recommends using a Two by Two Comparison for this:
Here's an example of the kinds of distinctions we identified between faculty we met with for the Content Management Research Project:
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".
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.
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.
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.