Document Builder’s Persona
Introduction
When you are developing software professionally, chances are that software is intended for certain types of users. Perhaps you are creating RPG games for people who like to roleplay in games, maybe you are creating a music editing software for sound editors. But before you go straight into coding the software, have you ever thought to think “What exactly does the users needs? What should I consider so they will be convinced to use my software?”.
Well, my friends, let me introduce you to Persona.
What is Persona?
Persona is essentially a personification or generalisation of your users. It represents your users and provides concise information about what your users need from your software. That information is used to design our software so it can truly match users needs and expectation. After all, what use is a fancy software if users are not satisfied with it?
Our Document Builder’s Persona
Document Builder is a software intended to help the administration of the Faculty of Law Universitas Indonesia to sort and process letter requests. We did not create the persona ourselves but given by our partner and product owner. There are four distinct personas (Admin, Superadmin, Mahasiswa, and Guest), and these are visuals representation of those personas, created by my teammate, Asti.
Is It Truly Important?
Is it? I am just a software engineer who churns out code out of the UI/UX designer design. However, when I looked at the mockup which I use as the basis to code the software, I can see that Persona influence the mockup a lot. For example, the button design in our mockup is, in my opinion, beginner-friendly. The buttons are represented with unambiguous icons, denoting their uses. This, I feel, is influenced by one of Admin’s pain points, which is difficulty in understanding new systems. Thus, due to that, the UI/UX designer focuses more on user-friendliness over fancy UI.
Another good thing from Persona is they can be used as a supporting argument when the client is asking new feature outside the requirements. Persona defines what our users needs, and so can be used as a justification to reject features that are unnecessary for the user, thus reducing the project complexity and buying more time for developers to focus on features that the users truly need.
Conversely, it also can be used to justify the client when they ask for a new feature or improvement. And this truly happens. On our first sprint review, the client asks that we change our app colour scheme. But should we accept that? Let’s have a look at our personas.
Turns out, one of our personas have a pain point that will be alleviated if we accept this. Our Admin Persona, Bu Manohara, explicitly state that needs a lot of time to understand a new system, and a simple user-friendliness improvement such as colour scheme adjustment will help her tremendously in understanding our system. Thus, with that as a consideration, we accept the client suggestion.
Another improvement that we could do to address Bu Manohara pain points is adding text to buttons instead of an icon only. Bu Manohara clearly states that she has a hard time interpreting modern icon looks on our app. Thus adding a helper text beside the icon will helps her when using our app. We also consider that a lot of the user (professors in particular, who are usually old and thus not as proficient with technology as young folks are) will be helped if we use text with an icon instead of an icon only.
So, the conclusion? If you ask me if it is useful, I still cannot tell. My knowledge of UI/UX is simply isn’t enough to make that conclusion. However, if you ask me if it is important, then yes. Its influence is felt through the software development process, and it is one of the deciding factors on how our software result will be.
