What is Persona and why should you care?

Introduction to Persona

Muhammad Irfan Junaidi
5 min readApr 11, 2022
Persona Illustration (Source)

When developing an application, it is quite often that you’ve heard of a user persona. A user persona is used as a tool in designing software. A persona helps create software as a persona describes how the user of your software will likely be. In this article, I will talk about what personas are and how my team creates one.

What is a user a persona?

According to the creator of user persona, Alan Cooper, it is a “hypothetical archetypes of the actual users. Although they are imaginary, they are defined with significant rigor and precision.” Interaction Design defined a user persona as a fictional character that you create to represent the user that will use your application. A persona usually consists of the fictional character’s background, goals, motivation, and frustrations.

Why do we need persona?

As mentioned before, a user persona helps us in creating software. The user determines whether the software is good or not. To know the user is to understand what they need from our software. Here are some benefits of building a persona for your project:

  1. Builds empathy
    Empathy is the ability to understand what other people feel and see things from their point of view. Personas help software designers understand their users. It helps them to see the perspective of the users. Knowing the perspective of the user helps us understand what the users need and what they expect from the software.
  2. Serve as a guideline for your project
    It is quite common for designers to fall back on the design they like. Having a persona reminds us of who the users of our software will be and such designs should consider the users. At the beginning of the project, the persona is used to help in designing the looks and interaction of your software. Reaching the end of the project, the persona you make can also be considered when doing User Acceptance Testing.

What counts as a good persona?

Since a persona is used as the guideline of your project, making a bad one may lead to chaos on your project as well. Here are the characteristics of a good persona:

  1. Even though a persona is fictional, it should not be made carelessly. It should be well observed and researched from real data.
  2. Personas should represent the user’s behavior, not their roles
  3. A persona focuses on how they interact with the software now, not how they interact with that software later.
  4. A persona is focused on the goals and behavior when the user use that software

How do you create a persona?

There is a variety of ways to make a user persona. Here are the general steps in making a user persona for your project.

  1. Do some research on your user candidate
    The first step of making a persona is to collect information about the users to understand their mindsets, behaviors, and motivations. Accurate personas are based on actual research data, and more information collected will lead to a more realistic persona.
  2. Identify the user’s behavior
    We identify the user’s behavior to ease the process of grouping users based on the similarities of those behaviors. From that information, we can then create a fictional character that represents that group.
  3. Create the personas
    When creating a persona, it is important to avoid adding too many personal details as having just one or two personalities is good enough. Creating too many personas should also be avoided. The purpose of a persona is to give a brief idea of the users so that the developers are able to work on a design based on that persona. That’s why having 2–3 different personas should be just enough.
  4. Discover scenarios of interaction
    Persona alone isn’t good enough to describe a user candidate. Only when that persona is coupled with a scenario does it becomes valuable. Having a scenario helps the designers understand the main user flow of the software.
  5. Review them with your team
    When working as a team, communication is important. After you finished making the personas, share them among your teammates. This way, the whole team will be able to better understand what kind of people will they make this software to.

User Persona on my team’s project

On our project, there will be two roles of user, Juru and Admin. Jurus are people who want to offer a variety of services, while Admin manages the Jurus that are registered to our site. We created two personas that represent what kind of users will use our software.

First Persona, Representing the Software Admin

The first persona is Zich Moore who is an admin for our software, which keep track of the users of our software. On the picture above you can see Moore’s personal information, goals, frustrations, and motivations as an admin.

Second Persona, Representing a Freelance

The second persona is Elena Schariac who is a candidate user (Juru) for our software. Similar to the first persona, you can see Schariac’s personal information, goals, frustrations, and motivations but as a Juru.

How user persona help my team’s project

Having to have learned about personas from Interaction Design Course, we already know how and what to do when making persona. The persona we crated was used for the initial software design such as wireframe and mockup.

As we start to develop the software, we ask ourselves whether a certain feature is needed based on the personas that we’ve made. Other than that, the personas also helped us to straighten up our priorities. Since we have two types of users, we have to make two kinds of perspectives to the software. At the beginning of the development, we focused much more on the admin side of the software since the features are related to authentication and Juru management, hence the prioritization.

Near the end of each sprint, we also conduct a User Acceptance Test (UAT). On a UAT, we need to describe how the user interacts with the software being developed. Designing the UAT becomes much easier because of the personas we’ve made at the beginning of our project.

--

--