All users have got specific requirements based on their goals, capabilities, and contexts. To satisfy all of the users might seem logical to design your system to be as broad as possible in its functionality to make people use it.
However, To satisfy everyone is a myth and there aren’t exist user who represents everyone or the average user. If you design a product that tries to please all of the users, the product might be created with pieces of stuff that are not relevant to any of the users and increase users’ cognitive load and navigational overhead.
So it’s better you start by trying to satisfy the needs of just one. And actually, Your product might be a design for the specific type of individuals who have got specific needs. That’s why Personas are created. Furthermore, Developing personas will help us clearly define who is and who isn’t our target user for the product and make many of the design decisions.
So How can we build Personas?
Personas are built based on primary research like a contextual interview that observes the people’s behaviors in the place where they actually use the product. After interpreting the observations of user behaviors in the primary research, You might need to go on the affinity diagrams for organizing the tons of users’ data. And then you will be able to identify some of the users whose mental models are similar such as their characteristics, demographics, pain points, needs, and environments. The grouped users we identified can represent persona depending on the number of groups. The point is the personas we derive are based on the data from all of the real user research.
For setting each of persona, They need to be called by name and got a profile so that your team can refer to a specific user and emphasize with the user. Also, the persona’s key objective such as a quotation that captures their needs is indispensable because it’s an essence of what the user is about. A short narration of each persona with their backstories can also evoke empathy to them by your team member, and listing the key goals that begin with verbs expresses the user’s perspective. The additional thing that is good to describe on personas is whether they are primary or secondary personas. A primary persona is made by the decision whether it is the mainstream that satisfies other users as well if his/her problem is solved. So, in sum, You will be able to find that personas are a container and a tool that are synthesized all of the research data you’ve collected.
Then what’s the benefit of building personas and their pitfalls?
Benefits for creating personas for your team members are
- Personas make explicit assumption about who the users are you are designing for. Your team members can openly share the clear target and they can be aware of who the users are. So there’s no ambiguity anymore in your team.
- Personas help your team to make better design decisions by limiting choices. It’s obvious that you can make a better decision having constraints rather than trying to do everything.
- Personas combine both heart & head influence approach. It reinforces your team members to emphasize with the users with the real datas.
Next, the pitfalls you should be cautious and need to avoid when developing personas are
- Make sure there is variety between your personas. Especially their goals and motivations needs to be different from each other so that you are able to distinguish the different type of goals of different users.
- Avoid making too many personas. Using so many personas causes getting lost in your way in design decisions.
- Avoid making the personas formatted. They should feel as being very genuine and realistic.
After building Personas, I greatly recommend checking the personas with 7 steps, PERSONA!
P
primary research — Is the persona based on contextual interviews with real users?
E
Empathy — Do the personas evoke empathy by including name, a photograph, and a product-relevant narrative?
R
Realistic — Does the persona appear realistic to people who deal with users day-to-day?
S
Singular — Is each persona unique, having little in common with other personas?
O
Objective — Do the personas include product-relevant high-level goals (ie. explicit goals) and include a quotation stating the key goal?
N
Number — Do the number of personas is small enough so that your team members can remember their names and characteristics?
A
Applicable — Can the development team use the persona as a practical tool to make design decisions?
Lastly and shortly, I would like to repeatedly recommend you to create a persona with the data of field visit research. The first step of the research is to decide on your focus question to ensure you involve the right participants. Next, identify the participants by observing if the questions you prepared are adequate to ask. Then you will go out and do the field visits (i.e. visit participants). While in the field, you should interpret your observations with participants to check your interpretation is correct. Then you create an affinity diagram to find clusters of behaviors and finally you create a persona description.
