
What is a persona and why is it important?
Whenever we want to create a design for a product or service, it has become standard practice for us, with the data that we have obtained, to generate a description of the people that will most likely use it. What we have created is called a Persona. It is a realistic way for us to ‘humanize’ data and it helps us to better understand the users so that we can create a design that is catered to them specifically.
Personas are usually created at the start of the project, before any actual development occurs, but after we have collected information about the users. It usually consists of information about their goals (what they want to achieve with the help of the product), skills (what the user can do), frustrations (real life problems that the product will help solve) and their biodata. Do keep in mind that what you are creating is not an actual description of one real individual, but a representation of the user from data that you have collected, so a short description about a particular persona might contain an amalgamation of real descriptions of real individuals, or it could be a wholly new description based on your interpretation of the real descriptions that you’ve obtained (Woah, that’s a mouthful!).
How do you create a persona/personas?
The first thing that you should do before creating a persona is to perform a research on the potential users that will use the product that you make. If you’ve done a stakeholder interview, you should have a rough idea of that. After you’ve known your potential users, you should collect information on them. One of the most popular ways to collect information on your potential users is from user interviews. The goal of collecting data is to understand the user’s goals for using your app, the frustrations that your app can solve, and the skills that the users currently have so that you can tailor the user interface with the purpose of making it easy to understand for them.
From the data that you collected, try to find data that overlaps between each person. From those overlapping data, you can then group them up and use that to help create a persona. The number of personas that you will create is based on the information of the potential users, and the data that you have collected.
Again, do keep in mind that a persona should roughly consist of these elements, but some of the elements may be omitted as needed:
- Photo: This will help build the virtual identity of the persona, and will help you more easily recognize it.
- Name: Each persona should have a unique name which represents it. This will help you refer to it in discussions and will help make your clients perceive that the personas are really the representations of real users.
- Biodata: Biographical data such as the average age, where they generally live and what their positions are wherever they work.
- Short Description: Summary of the persona
- Goals: The purpose of using the product that you will make.
- Frustrations: Real life problems that you can tailor your product to solve.
- Skills: What the user can do generally at this time.
Below is an example of the persona that we have created for our class project.

In the above persona, you can see that we have concocted a name, an age, a job position, a short description of the user, goals, frustrations and skills (denoted as tech above). Included with the text is a picture that we took out of google images. It may look simple, but for the purposes of our project, this is enough.
I should mention that people that are unfamiliar with the concept of a persona will think that the above persona is a description of an actual person (at least our client thinks that it is). You should inform them that it is not an actual person and that it is a personification of data and a representation of the users that are likely to use whatever it is that you created the persona for (in our case it’s an application).
What do you do after you’ve created a persona/personas?
From this persona we can then chart a course with the end goal being the completion of the design of the product. From the goals that the persona above has, it is clear that we have to make an application that can help the persona create an exam schedule in a short period of time with the least effort possible. Therefore it is necessary that we make the program easy enough to navigate. But how easy should we make it?
Let’s look at the tech section of the persona, which represents the skills that a typical user will have. From that, we can see that it can use applications like Microsoft Word and web applications that we can assume are internally used in the workplace really well. Therefore, we can make an interface that is similar to those applications in design.
Now let’s look at the frustrations that a user of the application will typically have. From that we can know that creating a schedule without conflicts is difficult and revisions to exam schedules will increase the effort needed to create the schedules. You may have completely different solutions to these frustrations, but we decided that the generation of exam schedules must be done automatically to ensure that the schedule is always correct, and the user need not do anything other than setting a few parameters and pressing a few buttons.

Above is an example of the user interface of the app that we are creating. Since we have concluded above that we only want the user to set a few parameters and press a few buttons and we want to make it less time consuming, we made it so that the user only needs to perform six steps in order to generate a valid exam schedule, and the algorithm will take care of the rest. These steps are:
- Upload some files related to the generation of the schedule
- Click next
- Set up the range of dates when the exams will be held
- Increment / Decrement sessions per day as needed
- Choose in those ranges, the days when the exams will be held
- Click next
With this, generating a valid test schedule, assuming that the excel files have been prepped before, will take a maximum of around fifteen minutes.
What if we don’t use a persona?
By this time you may notice how we can easily think out how our application will be with the help of a Persona. Now let’s look at the disadvantages of not using a persona to help think out your designs.
The benefits of using a persona is that the application will be personalized according to the user’s frustrations, motivation and skills. Not using them could lead to the application not being personalized for those things. For small scale apps or apps that already have a predefined user interface, this may not be a problem. However, for large scale applications, this can lead to some detriments, such as (1) The app being not easy to use for the intended users, (2) The app not having the features that is actually needed and/or desired by any/all users (which can lead to a decrease in sales if the app that you are developing is a paid application) and lastly (3) a lack of a vision to help the design team focus on creating a design that works. This may, in turn, lead to increased development time due to the increased amount of revisions that is needed so that the app can actually be useful to the users, and usually UI revisions after a part of the software has been developed is harder to implement than UI revisions before any actual code is written.
That’s really why it has become standard practice for designers to create a persona before developing an actual design of the product. It shortens the time immensely and it eases the pain of development considerably. So, next time you want to create any product, create personas of your users first. Trust me, you’ll thank me for it