If you are involved in User-Centered Design (UCD) work, you need to know about personas. Personas are a means of summarizing an audience segment targeted by a product development effort as a fictional character. For example, if a team intends to launch a product for a specific group, the first step would be studying the group in detail, and the next step would be summarizing the data about the group in the form of a persona. Doing this helps teams determine product requirements, charts design direction and increases the odds of success.
In the UCD process, personas provide the following benefits:
- They simplify vast amounts of information. Research teams typically collect large amounts of qualitative and quantitative information at the early stages of a project. Personas are a way to convert all the facts into manageable chunks that are easier for teams to think about and use. Having too much information can have a debilitating effect. If the information is not presented in a format that is easy to use, teams will ignore the data altogether.
- They streamline the design process. Personas align efforts by making sure the entire team is thinking about the user group in the same way and that everyone is trying to solve the same problem. Design and development efforts get derailed and drag on because team members have different ideas about the user group’s characteristics and the problems they need to solve with the technology and design. Ensuring everyone is on the same page about these issues reduces time to market by aligning efforts and minimizing disagreements. For example, any time there is a disagreement about which features to include or how it should be designed, teams can ask themselves: Does this help the persona accomplish a goal in a real scenario? Does the design of the feature make it easy to realize the goal? If the answer is no, drop the feature and move on.
- They get buy-in from stakeholders and teams. But only if done well! Well done personas get buy-in from stakeholders, particularly when designing software for the enterprise because the information is consistent with prior thoughts and beliefs. In addition, great personas cause stakeholders to think about the situation in a novel way. When creating personas for stakeholders in the enterprise, teams will know the personas are done well if someone close to the worker group being studied says, “oh that sounds like so-and-so”. In fact, in one of our projects for a client, our personas were so realistic that the stakeholder thought they were actual employees. Another indicator that a persona is well done is if it becomes the focus of client workshops and ideation sessions. A sign this has occurred is if people continue to refer to the persona by name throughout the workshop. Another sign is if after brainstorming solutions, designers and stakeholders take a moment to reflect by asking, “Would the persona [insert persona’s name], find this useful? Would it make his job easier?”
Drawbacks to using personas can include the following:
- They are difficult to make. There are many ways that personas can go wrong. Data can be improperly summarized–overemphasizing unimportant information–or sometimes not emphasizing important information. The persona’s name can be too fictional. Cliche or cartoonish names like, “Dutiful Deborah” should be avoided. In addition, the picture can be non-representative or look too much like a stock photo. Pictures should always be as representative of the user group as possible. Unless the user group is a group of models, avoid using photos of paid models.
- Scientific communities typically do not value personas. Highly scientific communities would rather see the data about user groups summarized as percentages and graphs, rather than fictional characters’ goals and challenges.
- Personas are not a stand-alone artifact. To maximize their effectiveness, they should at least be supplemented with task analyses, scenarios and experience maps.
So, how are personas created?
Below are broad steps and tips for creating personas.
- Collect and analyze data
- Write the persona
- Pick a photo and name
Collect and analyze the data
The first step in creating a persona is knowing which market segment or worker group to study. In the enterprise market, a persona can be defined as the worker group, or groups, whose work will be affected by the product or system being developed. Once you know the worker group to study, the next step is to identify the business objectives. That is, what is the technology supposed to do for the worker group? What impact is the technology supposed to have on the business? How will it be determined whether the objectives have been met? The answer to these questions may impact what data collection methods you use. There are many methods used by researchers including: Contextual inquiries, interviews, surveys, diary studies, usability testing and data mining. Once the data is collected, it needs to be analyzed. When analyzing and collating this information, it is important to look for common patterns and trends within and between worker groups. This is particularly important because personas should describe groups as a whole, without too much emphasis on edge cases. Think of them as averaging all the information about individuals in a group to identify a common description, much like averaging a collection of numbers to describe the set.
Write The Persona
Once the information is collected and analyzed, it’s time to write the persona. Writing personas are more of an art than a science. Personas should be written with the business objectives in mind and highlight users’ challenges and needs to be overcome by leveraging their goals, behaviors, preferences and cutting-edge technology. Examined with task analyses, scenarios and experience maps, they should arm teams with the materials needed to brainstorm effective and innovative solutions for meeting the business objectives. A good format to follow is to start by highlighting the persona’s goals, preferences and desires. Next, highlight frustrations, challenges or pain points that are obstructing them from realizing their goals. Lastly, conclude this by enumerating clear needs. The needs should be written such that the reader finds it natural to begin brainstorming solutions to meet the needs right after reading the persona. This typically causes great discussion during workshops.
Pick a photo and name
Picking a photo and name may sound simple, but it can be the most challenging part. Even if all data collection, analysis and reporting are done correctly, the persona’s name and photo can prevent stakeholders and teams from taking the persona seriously. Now is not the time to use cliche names or show stock photos of models. Think carefully when selecting a name. It should sound like people from the user group. The photo should also look like an individual from the group. Make sure the user group is being represented accurately with the persona’s age, gender and attire. Violating these rules will subvert well executed research.
Personas have many benefits. If done correctly, the benefits outweigh their disadvantages. They can inspire teams and stakeholders to think of creative solutions, focus design efforts towards a common end, and make vast and complex information easier to think about and act on. If using a persona to summarize a user group, augmenting them with scenarios, task analyses, and experience maps will make ideation sessions and the products that come from them very successful, increasing the likelihood of meeting specific business objectives.