What is a Persona?
A persona is an archetypal representation of a group of users. They are used in software design to focus the project on users rather than the system. Introduced by Alan Cooper in his book, "The Inmates are Running the Asylum", personas became a popular way to focus a team on the people who would actually be using the product. The concept of a persona is beautiful in its simplicity, which is part of why it works so well in so many different contexts. The idea is that many users will share goals, motivations, tasks, backgrounds and methods and that they can be grouped accordingly. While using this method has many benefits, there are also some drawbacks to consider as well as some mistakes to be sure to avoid.
Pitfall #1: Varied Target Audience
Designing a project for a large target audience can make creating personas extremely difficult because of the amount of information there is to synthesize. Generating personas based on every single user group that may user your product is tedious and often impossible. An example of this scenario is a website with an international audience.
Solutions:
Take a look at your product and divide it up into segments. Choose the most important sections and create personas for them first and then see if you can interpolate from there. If the project is unable to be broken up or the division does not reduce the target audience, then what may be missing is a change of thinking. While international customers are varied, their motivations and goals are more important than their demographic. What does your product do? Try and classify broader categories based on why users are using your product and not their demographics.
Pitfall #2: Too Many or Too Few?
Finding the perfect number of personas can be tricky. Having too many can make the work more confusing, contrary to the goal of clarifying user perspectives to the team. On the other hand, having too few personas means that the user population is being unfairly slotted into specific categories and some user groups may be missed entirely.
Solutions:
If you have too many personas look at all the user groups that you've identified and see if you can amalgamate any of them. Generally you should try not to have more than five personas for a given project, with three being the most common. If you don't have enough, you may need to do more research. Review what you are looking for very carefully. Are you asking the right questions? Are your questions open-ended enough to produce an appropriate variety of questions while still allowing you to identify trends?
Pitfall #3: Assumptions and Stereotypes
Experts and stakeholders tend to have developed assumptions about the target audience that may not be verified. Everyone has an opinion of what they think users will want, but writing personas without verifying claims is dangerous. Personas that are not real are not useful because they do not accurately represent the user group. Also be mindful of filling in the gaps of research with stereotypes. You may discover many motivations that lead you to classify a group, but be careful when adding details that are not directly supported by your data. Fake personas produce fake results.
Solutions:
The only real way to completely avoid this problem is to do your research. Make sure that all the details you add to your personas are validated through quantifiable means. If you are on a tighter research budget you may want to consider focusing your research on the qualities that you are going to use to determine your persona groupings. Filler details that are not used to create categories can be taken from smaller samplings. For example, a group of people wanting software that allows them to perform certain tasks is more likely to be important than the extra details. Of course, you still need to be careful when determining what, if any, information is actually filler.
Pitfall #4: Overwhelming Information
A well balanced and well written persona lends insights into the mindset of users. A long persona with an overwhelming amount of detail, however, can detract from the overall picture. Too much detail can create conflict rather than unity amongst a group as each individual dissects the same ideas differently. Furthermore, some may have difficulty determining what information is relevant for which discussions because of the sheer amount of information available. Increasing the amount your team has to read also increases the chances that they will not read it thoroughly or even at all.
Solutions:
Keep your personas to a maximum of one page in length and choose your layout carefully. Consider using bullets and headers for some portions of the information and paragraphs and sentences for others. Adding an image can also spruce up a persona and keep the information more concise. When actually writing your persona examine each sentence and idea carefully. Ask yourself what that fact tells you about the persona and whether or not that matches the research you saw. Think of how that information would be useful. If you can't think of good answers, remove it.
Pitfall #5: Discomfort with Personas
Some individuals find creating and discussing imaginary “people” to be uncomfortable. They may find it awkward to try to create an individual based on many people or might not be comfortable with descriptive narrative. Individuals whose first language is not English may find personas confusing and difficult to understand and work with.
Solutions:
Remove personal references from your personas to make them more conceptual. Use titles such as “Sales Manager” or “Sports Enthusiast” to describe your personas instead of naming them. Shorten personas and use directed, clear language. You can also change your formatting of the information to include charts or bulleted lists more than sentences and paragraphs. Some situations may also benefit from removing images so as to dissociate with stereotypes.
Pitfall #6: Lack of Focus
It is very easy to slip away from the true focus of your persona and into user design specifics. By allowing specific design implementations to be included in a persona, you remove all other options and discourage creative thinking in a team. Allowing people to have their own ideas of how to best serve a persona is part of designing the best product.
Solutions:
Check for sentences that describe software specifics and remove them. Instead of writing “Jane appreciates being able to hover over a misspelled word and have it corrected” rephrase the sentence to capture the challenge instead of the implementation: “Jane is not confident in her spelling and needs help correcting her papers.”
Pitfall #7: Expenses and Time
Writing accurate and useful personas requires some time and expense. Researching personas can involve large amounts of people and large amounts of data analysis. Experts may need to be hired to do certain jobs. The more accuracy you want, the more it will cost and the longer it will take.
Solutions:
Make a plan for exactly what you are trying to achieve and within what budget. Brainstorm methods of attaining what you are looking for and evaluate each method on 3 categories: Effectiveness at gathering the required information, Efficiency with which it can be performed and Feasibility of costs required. While there is no way to entirely solve the problem of expense and time, there are certainly ways to minimize it.
Pitfall #8: Statistical Personas
Some personas are poorly written using statistics exclusively as the base. Creating a persona based on statistical or demographic data instead of qualitative information is of very little use in designing a project. The most important information within a persona are the thought patterns and motivations that defines a user group. Sometimes motives line up with demographics, but many times they do not.
Solutions:
Consider research methods that give you more detailed and in-depth analysis such as interviews, site visits or questionnaires. Understand what it is you are trying to learn when you are planning your research so that you get usable results. Think very carefully about how you intend to use the results of your research before doing it. Don't be afraid to include a little demographic information as filler for a richer persona, but be mindful not to create stereotypical characters.
Pitfall #9: Elastic Personas
An elastic persona is more like an imaginary friend than a persona. They are typically poorly defined and every member on the team may have a different idea of who they are trying to design for. In this situation personas can easily become validators. Be careful that your team does not begin to invent reasons for sympathetic personas to be accommodating or supportive of their decisions instead of using the personas to drive discussion of solutions.
Solutions:
There are generally two problems that lead to elastic personas: poor definition and lack of participation. The first, poor definition, means that you have included too little information in your description and most of the details used by designers were “inferred”. Make sure that your language is clear. Check for other interpretations by asking others to read it and asking them to describe the persona. The second problem, lack of participation, comes in a variety of ways. It may be that some people don't read or help create personas, or that people do not reference them frequently enough or make them central parts of their design discussions. You can encourage use of personas by making them the focus of meetings and setting an example by using them to generate ideas. Arrange to have copies distributed to each team member and consider posting copies in locations where the team meets frequently. If you have members on your team that are not as experienced with personas, you may want to consider running a workshop that covers the basics of using personas. Include some fun, ice-breaker exercises based on personas to get everyone excited to start using them more regularly.
Pitfall #10: Getting Proof
Even with research, proving that a persona is accurate is difficult because of the nature of the research. Using quantitative methods will give you a good picture of what users are doing, but not why, a crucial question when creating personas. When using qualitative methods, distilling that information into hard proof can be challenging. Some people require hard proof to use personas, however, which is hard to come by if you are limited strictly to numbers.
Solutions:
Look for frequency of information. If 50% of those surveyed said that they used your software for one reason and 50% said they used it for a different reason, that is hard proof that a division based on these two groups might be feasible. You may also want to consider using gradient scales which can be analyzed numerically.
References
A Look At Some Common Usability Elements by Aalap Doshi
Approaches to Creating Personas by Steve Mulder
Conceptual Design by Saul Greenberg
Designing and Specifying Content Requirements by Victor Gonzalez
Evaluations of Attitudes Towards Thinking and Learning by Andrew Laghos
Personas Compared to Target Market Research by Linda Morton
Personas: How Many is too Many? by Charles Sue-Wah-Sing
Personas and User Roles by Larry Constantine
The Inmates are Running the Asylum by Alan Cooper
'Thick Personas' - Using Ethnographic Methods for Persona Development by An Jacobs, Katrien Dreeson and Jo Pierson
No comments:
Post a Comment