Persona: Mr. Sukimin
A brief story
Mr. Sukimin was a product owner who needed us to deliver an application. He straight flatted out product requirements, loud and clear. We structured our backlogs and started our first sprint. Simple app, simple tasks. By the end of the sprint, our first deliverable is ready to be tested by end-users. We were confident in our work, as the requirements couldn't get any simpler.
It aged like milk. Mr. Sukimin came back to us with a really long list. It wasn’t much of a functionality issues, but rather things like too small of a font, their password is too hard to remember (too secure of a password: lower and upper case, numbers, and symbols are required), and even things like language styles that wasn’t ‘understandable’ (We used slang words like Kuy, Cekidot, etc).
That’s right. We had NO idea our user was going to be seniors. It was a workout reminder app, and the requirements stated to make reminder notification as down to earth and friendly as possible. Yup, we assumed it was for teens! We ended up having to use half a sprint worth of time to fix these issues.
Ask your users out on a date (no, really).
You really need to know your user as best as you can. Ask them on a date if you’re really entitled. And while you’re at it, ask them about their hobbies and their goals; their satisfaction and their frustration; their deterrence and their motivation (You could ask for their social media too if you’re really that curious). The main motivation here is that we do not want to develop a product, without really getting to know its users.
Persona Grata
Mr. Sukimin and we fail to realize that there is usually more than one potential user type for any given product. And as a matter of fact, every user indeed has their own motivations, frustrations, and expectations as to why they decide to use the product.
Creating a persona is basically mapping out all possible types of users (from real-world data) into a series of fictional characters, each with their own traits that differentiate them from the others. There should be no need to map a character that is closely similar to another character, even though they may differ in their real-life traits.
TBCare for PPTI
Our PPL project requirements require us to develop a mobile application and a web application. The mobile app is intended to be used by PPTI Officers (Kader), to log out new TBC investigation cases, and to monitor those cases. The web app is to be used by PPTI Admins, to confirm whether investigation cases are positive, to recapitulate cases, and to monitor officers activities.
Thanks to our Product Owner, we have come to two very specific personas for TBCare, since the product intention is also very specific: to ease the work process of logging TBC Cases and their monitoring cases, in contrast to their conventional (pen and paper) logging ways.
We couldn't stress it enough that these fictional characters helped us develop fictional ideas into reality (Cheesy, but true). Hopefully, after this article, we can all agree that knowledge of our user is the top priority for our foundation of software development.
Written as an assignment for my software engineering project individual review.
