Before exploring the mistakes in creating personas, take a quick quiz: my friend John Pearson is a History Professor. Can you guess some of his qualities? Take a moment to think.
You may have formed some idea of John Pearson just based on this single fact. How is it possible? All you know is his name and profession. We carry mental models or prototypes of members of a group or category.
These ‘prototypes’ can have powerful, unconscious influence on us. That is why we can quickly form an opinion about someone based on limited information, as in this case about the History Professor. And then there are assumptions. Like prototypes, assumptions can have subtle influence on our perception of reality as well. Both prototypes and assumptions can mislead us while developing personas.
This is the one common mistake Agile teams make when developing personas. Instead of considering the process objectively, they get influence by mental models and assumptions.
As archetypal representations of a user or a class of users, personas play a role wider than helping interaction or goal-directed design. They provide a vision for the entire team, including the product owner. Only if they are created correctly! We have seen one common mistake in their construction. Here are some others:
Other common mistakes made while creating personas
1. Not realizing the reason for their creation
People work best when they know ‘why’ they are doing things. Personas are a away of well, personifying the users of the team’s output. The concept of Servant leadership is often evoked in the context of agile. It indicates that one is serving…whom? In the teams’ case, it is the group of users represented by the personas. Personas thus direct team’s work towards fulfillment of their vision and meaning of their work. Seen in this context, persons attain a different status. A much higher, larger, greater status.
2. Making personas flat instead of round
In literature, characters are divided into two categories – flat and round. Flat characters are simple, uncomplicated and two dimensional people. Round ones are complex, multi-dimensional and closer to real life. It is good to keep these two categories in mind while drawing up personas. As archetypes of people personas should reflect their complexity. A multi-faceted portrait brings them closer to real life and makes them easier for teams to identify with.
3. Confusing UML actors with personas
Personas are different from the “actors” used in UML. A UML actor can be any external user, including other systems and hardware. Personas on the other hand are ideal representations of people like you and me. Like us, they have goals, preferences, and drives.
4. Not identifying past user experiences
Like treasure dug out from the depths of the ocean, priceless information can be brought out from users’ past experiences. When did they have a happy experience with the system or product? What specifically delighted them, surprises them, tickled them, annoyed them?
5. Not using available information
Use existing company documents and intranet. Use information collected earlier. Use personas if they are already available. You may validate these against current realities. But don’t disregard the information totally. Using available information saves a lot of project time. Precious project time.
6. Not getting genjitsu
There are many ways to get information for a persona. One-to-one meetings, focus groups, workshops, brain storming, talking to customer support groups and research on net. Remember gemba and gembutsu. Go to the real place where users work (gemba) and see the real thing, how they actually work (gembutsu) and get first hand information, real life facts (genjitsu). You are likely to get better information than from secondary sources. If you stick to only one approach, you may get limited, incorrect or distorted information. To get comprehensive information, explore multiple channels.
7. Relying on experts to decide type and number of personas
The unique situation of your project and not an expert’s opinion should dictate the type and number of personas. Consider the project environment, the product and customer segments. Don’t depend on a generic persona template that is used for all products in all situations. Basic information like needs, pain points and usage patterns may be common to all personas. Beyond this, your purpose should lead you in their development.
8. Making personas the size of an encyclopedia
You can squeeze in behaviors, psychological indicators, background, and a host of others in a single page. The page may look great. But it will remain a colorful and unused artifact. Personas with too much information, narration and variables will not inspire teams.
9. Not actually using personas to guide team’s efforts
Finally, all the effort spent to creating personas will be wasted if teams do not actually use the resulting portraits to guide their progress. Display the personas where the team can see them, along with other information radiators. Refer to them in team meetings. Recall them during your offline discussions. This greatly facilitates focus. As I explained in my earlier post on psychology behind agile practices, such focus leads to greater productivity.
Prepared in the right way, personas delight the team continuously. Every time they make progress, they can look at the pictures and imagine how happy the users will be. It is as if the users come to life from the personas, pat the team members’ backs and say “that’s a wonderful job. Thank you.”