Stories

10 Tactics To Create Better Personas

Google+ Pinterest LinkedIn Tumblr

In Experience design we usually create personas for different characters that are going to be used in a new product. A persona is a representation of a user, usually created based on a user research. I’m discussing about 10 tactics that will help you to create better personas and avoid common pitfalls in this process.

  1. Identifying User’s Goals: In UX Processes, before you start to create your personas, you need to find and understand what is your user goals for your product. User goals consist of what your users want to do. An example of a simple user goal can be: “to have a cup of tea at work”.
  2. User’s Goals are not User Tasks: User goals and user tasks are two different things and sometimes are mistaken with each other in UX design. Tasks are steps that we take to reach to our goals. Goals are placed on a higher level. I will give you a simple example:

Scenario: Restaurants that are selling food online.

  • The task is to choose and buy the food easily.

Solution: Show all the available foods in the menu, the delivery time and easy payment procedures.

  • The goal is to have a great meal with your family.

Solution: In addition to the tasks above, restaurants usually provide sets of delivery for dessert and so on.

 

  1. A Persona is not the same with your technical requirements: Don’t mistaken the Persona with your technical requirements. Technical requirements are every details of the product development process. Persona is not a good place to ask questions such as what OS is being used or how much RAM they need to run the application.

 

  1. Security is not part of your personas: Persona is a good method to understand the functional behavior of the system but it is not a good method to find QoS (Quality of Service) requirements such as security. Threat modeling is a systematic method for determining the vulnerabilities of a system.

 

  1. Personas should reflect the target group for a design team: One of the main reasons that a design team needs to start on when creating the personas, is establishing the empathy and understanding the individuals that want to use the product they are designing for. It is important to note here that a Persona should be based off real people so it gives a subject for the designers to reflect different questions off. For example “How would Alan respond to this?”

 

  1. Don’t literally link your persona to your UI design: Sometimes a design team goes really far with the Persona to even link it with different UI components such as navigation.

 

  1. Personas should be simple and efficient: Personas should not include a lot of small details, it should be short but efficient. Below is a template of a persona document.

 

  1. Personas is only an output: In Indi Young’s book “Mental Models”, Personas is an output of People diaries and Field research. Diaries are a popular way to gather data in the user’s voice. Users can write about their frustrations and challenges they face with specific tasks.

 

  1. Find user end goals: After you finish the persona research and understand each user problems and their goals, put them side by side and see whether you find a common theme between them. They should have a majority of end goals which are shared together.

 

  1. Personas should be archetype not stereotype: Archetype means neutral versions of a user personality. Whilst stereotype is referred when you think of a characteristic of a group. In most cases, a stereotype is negative. In other words, a stereotype is not assuming each individual but a judgement on a group of people. Here is a simple example of this matter:

 

Archetypes:

  • Professional user
  • Mechanical Engineer
  • Educated

 

Stereotypes:

  • Asian
  • From the developing world
  • Women

 

Conclusion

Personas are really crucial and important in a design process as it makes the design team remember who will use their product later. Unfortunately, sometimes we do not have enough time and budget to create them. We are pushed to kick off a design based on assumptions, last experiences and stakeholders expectations.

 

Your email address will not be published. Required fields are marked *