PPL 2020 — Document Builder: The Role of User Persona in Design Thinking
In the world of product development and software engineering, we’ve probably heard of the term “user persona” and “design thinking”. In this article, I’m going to talk about the definition of both of them, how they correlate, and how they are implemented in the development of Document Builder, our PPL project.
Design Thinking
Design thinking is a non-linear, iterative process which seeks to understand users, challenge assumptions, redefine problems and create innovative solutions to prototype and test — https://www.interaction-design.org/literature/topics/design-thinking
In the industry, design thinking is used as a method to brainstorm, develop, and test ideas. There are five stages of design thinking:
- Empathize → Research for users’ needs. This process allows us to have an empathetic understanding of our users. Throughout this process, we can have a deeper and human-centered perception of the problems we’re solving
- Define → State users’ needs and problems. After conducting user research and trying to understand the needs and problems of our users, we collect this information, observe, and synthesize them. This is the part where the user persona comes into the picture. More on this later.
- Ideate → Brainstorm and identify possible solutions. After going through the problem research and definition stages, we’re ready to sit down, think, and come up with possible solutions.
- Prototype → Start creating solutions. This is the stage where we start to create a cheaper and scaled-down version of the final product. Usually, the number of prototypes produced in this stage will be more than one.
- Test → Try the solutions out. In this phase, we conduct rigorous tests on the prototype that has been created in the previous stages. Most of the time, after doing the tests, new problems and issues will be identified and the previous stages will be reiterated with the newly defined problems.
Like how design thinking is defined, these five stages do not always run linearly and sequentially. Along the process, a stage might be repeated or reiterated or have it run along with other processes in parallel.
User Persona
Personas are fictional characters, which you create based upon your research in order to represent the different user types that might use your service, product, site, or brand in a similar way — https://www.interaction-design.org/literature/article/personas-why-and-how-you-should-use-them
Creating User Personas can help us as both the design and development team to identify and empathize with users’ needs and problems. The creation of a User Persona in the design thinking method falls into the second stage: Define. Even though it is deemed as “fictional characters”, a user persona is built using the information gathered during the user research done in the first stage of design thinking: Empathize.
User personas make the research data that are collected during the research process more humanized. Constructing a user persona helps us to ask the right questions for the products by defining the characteristics of the user we’re designing for. It helps us to come up with questions such as “How would Amy, an admin who is not very tech-savvy behave when feature X is rolled out?”
According to Lene Nielsen, there are four different types of personas:
- Goal-directed Personas → Focuses on answering the question “What does our user want to do with my product?”
- Role-based Personas → Focuses on the role of our user in their organization.
- Engaging Personas → Focuses on the ability of stories to produce involvement and insight. This type of personas can incorporate goal-directed and role-based personas through thorough and engaging descriptions.
- Fictional Personas → Persona that is not created from research data but rather from the experience of the UX team.
On our project, the user persona is defined prior to the process of creating the mockup. Here are the illustrations of user persona created by one of our team members, Asti:
The Personas created in our project are based on the goals that want to be achieved by each type of user. Therefore, our personas fall into the category of goal-oriented personas. By creating these personas, we define the problems faced by our users, what they need from the product, and the pain points that they have regarding the current processes. By building the product, we want to solve the problems of our users, help them achieve their goals, and ease their pain points.
Moving on to the next stages of design thinking
Creating User Personas really helps us in proceeding to the third stage of design thinking: Ideate.
From our user personas, there is a common goal that our users want to achieve: They want the process of applying and providing official letters and documents to be easier. Afterward, each role then has its own needs and goals to be fulfilled.
After understanding the common goal and the more specific goals, we move on to the ideation of how the product should be designed and developed. In the case of Document Builder, we start with the idea of: “What’s the easiest way for our users to manage their requests and fulfillment of official letters and documents?” So the solutions that come up are:
- Faculty administrator or secretariat can create and upload a document/letter template to the system
- Super admin (usually held by the role of an IT Staff) can manage the roles and access that each of the members of this system
- Faculty staffs and students can create their own letter by filling out the template that has been created by the administrators
- Faculty staffs and students can request for a template that has not yet created or been made available
From this set of solutions, we then began working on creating the mockup of the product. This is then the part where we proceed on the next stage: Prototype. After understanding the users through user persona, thinking, and coming up with a set of solutions, we started working on the prototype of our solutions.
Solving the goal of an admin of providing templates
Based on the user persona, an admin is also someone that has difficulty in understanding and adapting to the use of a new product. Considering this pain point, we try to make the system as user friendly as possible by using the Familiar Google’s material design.
Solving the goal of a super admin to be able to manage roles and access
Through understanding the needs of a super admin, we created a flexible and user-friendly way of managing users based on their level of access and their roles.
Solving the goal of students and staffs to easily create a document based on the given templates
From the user persona, we understand that one of the pain points of requesting an official letter/document is the need to physically go to the secretariat office, talks to the admin, and request a letter/document. In this prototype stage, we try to create a solution that makes it easy for anyone to create a document when a template is provided. We pay attention to the user-friendliness of the system by implementing Google’s material design. The experience of creating a document with the system will be very similar to the experience of filling out a Google Form.
Solving the goal of students and staffs to easily request for a template that is not yet available
Even though only admins that have the power of creating templates for students, we want to give the flexibility and power for other users to request for a non-existing template when they need it. Again, this kind of solution can be well thought of after we define what our user truly needs through this product.
Conclusions
Creating User Personas is the main activity in the “Define” stage of design thinking. We have seen through this post how the user persona can benefit the design and development teams in understanding the users and help solve their problems.
Feedback and second opinions are welcome, I hope it was useful!
