Living in a tech-saturated world genuinely forces many digital product users to adapt to the most outdated technology. But is it just the users that have to adapt?
As the digital product is designed mainly to make human life more accessible, the product should adapt to the user, us, as humans. Speaking of user, some of us must be familiar with User-Centered Design. Invented in the late ’70s, this term has been game-changing in the early technological era. This term was also later inspiring Don Norman in doing his works, such as Norman’s The Design of Everyday Things (originally titled The Psychology of Everyday Things) and User-Centered System Design: New Perspectives on Human-Computer Interaction.
User-Centered design is mostly defined as an iterative process in which the product designer focuses on the users in each design process. There are many versions of UCD out there; here’s one commonly used version.
- Analysis: The designer defines the context of use in their product and specifies requirements to meet the desired goals.
- Design: Proposing design solutions from the gained insights and specifications during the analysis phase. It can be a rough concept or a complete design, and it will be done in stages.
- Evaluation: Gradually evaluate the product design from a rough concept design to a deliverable product.
- Implementation: Transform a design into a deliverable product.
To understand more about the users, the developer needs something to summarize how they were, their needs, and what they’ve been craving. And that is called persona. Even though persona is sometimes described as an individual person or a character that has been personified, it is actually created from collected data from multiple targeted users. Thus, the persona can help the developer to understand the user’s needs and solve them through their product.
But what makes it so important? As mentioned in the title, our product isn’t really ours, so it’s crucial to understand our users, and thanks to persona for making it way easier. Persona helps us answer questions like “How would Mr. X fulfill their needs with Feature A?” or “Does Ms. Y will be satisfied with feature B?”. So that when we build our product, we’ll hear more “Our user needs this” instead of “We should do this.”.
There are several perspectives on persona. But when it comes to software development, a Goal-directed persona is a commonly used view. Goal-directed persona mainly focuses on what the user wants to do with the product. This perspective helps the developer examine the workflow that the user prefers. This perspective of persona mainly has 3 crucial parts of having.
- Persona: This part defines who are the user. It includes their attitudes, motivations, pain points, and goals.
- Scenario: This part defines how the story of persona take place. It will describes how the persona would behave in a sequence of events.
- Goal: This part defines what the persona needs and how would the persona take action to fulfill their needs. So when the goal has been reached, the scenario is success,
The next question is, how do we define our persona?
In short, there are 5 crucial steps in defining persona. Here’s how :
- Know Your Users: The first phase of building a persona is collecting information about our users. This step aims to understand the user’s mindsets, motivations, and behavior. It can be done by doing survey, or in-depth interview.
- Identify the pattern: The next step is analyszing the finding from the previous step. This steps has to deliver a pattern of our user that will be soon summarized as a persona.
- Creating persona: This is the final step where a researcher has to assemble and prioritize the pattern to be built as a persona. This might sound easy, but it can be tricky since not all the patterns we find will be included in the persona. It’s best to avoid adding many personal details since it will make it less credible and harder to understand.
Building a persona might be a little time-consuming, especially when we have to develop a product in a tiny amount of time. But a proper User Persona would guide us, the developer, from the ideation process through the implementation process and help us deliver the right product to the users.
How do we, Team La Casa de PPL, build our persona?
Our project, Sistem Informasi Monitoring Review Jurnal, was previously had its MVP in the form of Google Sheets. In addition, this MVP was run by < 5 editors and/(or) admin to monitor the journal review.
From those pieces of information, we thus build a simple hypothesis that our persona needs this application to be simple and quite similar to its current MVP. To gain more insight about our users, we conduct a quick interview with one of the editors of Sistem Informasi Monitoring Review Jurnal, Mr. Mishbah. We gained more insight into how editors work on the previous MVP and who they are in general from the interview.
The next step is to identify the pattern from those insights. We are trying to find the similarity and connecting dots among the behavior, the pain, needs, and gain to be built as a whole persona. We also learn more from the previous MVP on the task they are doing and try to see if there is any problem they could possibly face.
And, here we are in the final phase to assemble the whole persona. We finally described the user in a fictional character named Lukman, a man in his early 40s who works daily as a lecturer and Admin JIKI. We are also mapping our persona’s task, need, and gain in the persona board below.