Due to Popular Demand, Marie Kondo is Back.
It’s Not Just About You,
it’s also about me, them, and everyone.
This article was written for the purpose of individual assignment for PPL CSUI 2021, and also to educate readers on UX Awareness and QA. Not only that, this article was written to reflect my experiences while doing the process of aforementioned topics.
Prelude
After three years of studying computer science, I started to realize something important.
Programming is not just about coding.
The majority of you who are currently studying an IT-related major or are well informed enough probably know this. The general population and unfortunate aspiring programmers are probably not, though. That’s okay, I will explain from the beginning.
Since IT major usually handles technologies, websites, and programs, people usually presume that IT major are these “so-called genius loners that nobody can interact with”. These gradually developed into what I call ‘Stereotypes’, such as IT people being a bunch of introverts, unsociable, can’t understand people, and many more, including weird ones such as IT people being rich, or weebs (seeing you, Meja Wibu Fasilkom).
Well, for those who are currently reading this article and do believe those stereotypes, I have to sadly burst your bubble and inform you that is wrong. An IT major doesn’t give you a free ticket to be antisocial towards everyone, that’s not how it works. When you code a program at work, your code needs to be understandable towards your teammates, so they can also do their part. Your program needs to be understandable towards your manager, so they can pitch and market the product well. Your program needs to be understandable towards your userbase, so they can use the program well and guarantee a positive experience on your product. To ensure this happens, of course, you need to understand people to make this happens. To apply this information to your program, we can do this in 2 ways; Do quality testing on your program, and ensure a great UX quality on your program.
Wait! Zakiy, aren’t these usually done by QA Engineer and UX Researcher? I don’t see how this tells me why we need to be social if we aren’t working as these roles.
Good observation! In a big team, these tasks are usually handled by those roles, however, small group settings might not have people who worked under these roles so developers might have to also do their job desk. Even if your team has one, it’s not bad to notice faults of your application by yourself before release. Chances are, if the problem you noticed is actually bad, sooner or later you’ll probably be forced to fix it in the upcoming patch anyway!
Quality Assurance
Imagine yourself as a teacher. You have just finished writing questions for your class final exams tomorrow. You read once again that all of the questions are correct and the rules written at the start of the paper are correct and need to be signed in order to take part in the exam. “This final exam will surely be perfect”!
Or so you thought.
Apparently, due to a mistake on your part, the final exams didn’t go as you planned. Due to missing ‘not’ on a point of rules, your supposed ‘closed all’ exams just turned into an ‘open all’ test! One small problem just turns your plan into the worst you can ever imagine and turn the final exams into a total mess. And you’re not Marie Kondo!
Now imagine this happening in your code. in. your. code.
Thankfully, this can be fixed by ensuring that your program has passed quality checking in the dev team. Sometimes, you already prevented this problem by yourself too! This can be done by writing tests of parts or functions in your program, tests on your systems (your server, for example!), stress tests on your database (such as requesting a huge amount of query at the same time to the database), manual tests (checked manually by human instead of code), and more (tests)! Since I already covered the importance of tests and the novelty of clean code (that are also part of quality assurance!), I will skip this part and head to the next step of quality assurance.
Another way for you to ensure quality assurance in your program is to do peer-review on your code. When you are merging your codes to the main branch, assign some of your teammates as Assignee and ask them to review your code before approving. Since you have been working on your code for so long, sometimes you aren’t able to notice and fix the problems your code might have. By having someone else reading your code, you will be able to see your program from a different perspective and fix these problems away!
In my current PPL project, I am used to assigning one of my friends to do a check on my codes before merging and vice versa. Sometimes, my friends found mistakes that I didn’t know or forget. When this happens, I fixed the problems that are mentioned, and ask for any other inputs before asking for approvals.
Remember though, don’t forget to do another recheck before merging after you gain your teammate's approval! Very rarely, other issues might occurs from something you both missed that aren’t actually from your code at all!
In the above’s example, I accidentally pressed merge after gaining approval from my friend when I realized that I’m actually merging to the master branch!
UX Awareness
Just because it wasn’t asked doesn’t mean you can skip it!
So, you managed to make an application for e-Commerce that passed quality assurance. The code passes all the requirements and testing given, but apparently, it seems that you didn’t consult much with your audience while designing your application. The product details in your application are irrelevant and didn’t include information your user base actually needs, the program is confusing and is different in usage compared to the average e-Commerce application without any onboarding, and the color and font choices are blinding. When your application is released, users flocks into your app only to be pushed away to other e-Commerce applications due to how awful your app’s UX is. Surely this is not your fault, right? You’ve been doing what is asked! Wait, the company is bankrupt?!
The above scenario might seem absurd to you, but it illustrates well the importance of including the user's perspective in the process of making your app. This is what is called a user-centered design, a design process of an application that puts an emphasis on user satisfaction in developing our program. Once you’re done with a prototype of your application (usually made under Figma, or any other visualization application) or an alpha version of your program, you’re supposed to test it towards your userbase and gain inputs for further improvements.
The process of establishing a user-centered design goes from the above’s six steps that repeat in a cycle until users are happy with the current product. Here’s a short explanation of the above steps:
Research: In this step, do researches on current problems to gain an understanding of your users. This can be done from surveys, interviews from the previous UCD cycle, or feedbacks and complaints.
Define: Analyze the data you’ve gained in the previous step and find a key point where problems from your userbase are connected. Usually, this can be done by creating a Value Proposition Canvas, where the canvas would then details important information such as the user's task, need, and pain.
Ideate: After finding out the problem, generate ideas to solve it. Under a team of researchers, these can be done under a variety of brainstorming plans. Pick one that suits your team the most and go!
Prototype: Build a presentation of your ideas. For my example, I built a high-fidelity prototype of my project in Figma and implement them later on in Android Studio.
Test: Test the prototype for the user to be graded. The gradings can be done under several systems, for example, System Usability Scale or SUS. To test the prototype, simply send them a connected Figma project to be asked later on or use integrated software to conduct usability testing such as maze.
Implement: After getting inputs, implement them on your program, repeat the process for the next iteration.
Even though UCD yields the best result for users, since our application was made only for a limited number of users and the fact that UCD has a huge cost in time and money that we didn’t have, we decided to do a Genius Design instead of UCD for our program.
UX Awareness in Genius Design
Genius Design is a design approach that only includes the smarts and experience of whoever is on the UX team with no outside input or research. The results could go well or awful depending on how well-experienced the researchers are in the UX team. Since Kholish and I are the only two in our team who have taken HCI courses last term, UI/UX design mostly relies on our input. Many factors are crucial to gauge how well you are in designing UI/UX of your application, one of them is empathy that I explained in my Persona article. In this article, I would like to introduce a similar parameter to empathy in creating a good UX, called awareness. To be called aware, we shouldn’t just code our intended job desk and call it a day, we also need to be well-informed of our programs, do some manual testing of our programs, and also understands our program. By being aware, we will be able to do a good judgment in deciding how our program should be designed, hence doing a great Genius Design. Below is an example in me as the group’s designer on giving and applying feedback in our group project after being aware of what our program does:
In the few hours before our project sprint review, I realized that our team forgot to code an alternative design to show on users when there’s no one to verify and the lack of alert dialogue in accepting or rejecting applicants. This isn’t on our initial design that has been approved by the client, but is an important aspect that needs to be fulfilled in order to impose Nielsen’s Heuristic Design in our application (especially error recognition and prevent errors!). Giving empty data and confirmation messages would also increase our User awareness of the program by giving them information what has happened to the user for them to reach this specific place in our program. Under the deadline, I hurried and code this screen through:
if (map['resellers'].length == 0) {
return Padding(
padding: const EdgeInsets.symmetric(
vertical: 120, horizontal: 20),
child:
Column(
children: [
Image.asset('assets/images/hooray.jpg'),
Padding(
padding: const EdgeInsets.symmetric(
vertical: 10, horizontal: 20),),
Text("Tidak Ada Hasil",
textAlign: TextAlign.center,
style: TextStyle(
fontSize: getProportionateScreenWidth(24),
fontWeight: FontWeight.bold,
color: bluePrimary,
)
),
Padding(
padding: const EdgeInsets.symmetric(
vertical: 10, horizontal: 20),),
Text("Tidak ada agen untuk diverifikasi. Ayo undang orang lain untuk menjadi agen Hepicircle!",
textAlign: TextAlign.center,
style: TextStyle(
fontSize: getProportionateScreenWidth(18),
fontWeight: FontWeight.bold,
color: greyPrimary,
)
)]
)
);
}
After coding our program, we presented our current application to stakeholders in our sprint review and mentioned that our design is not final and can be changed (due to us doing it in a hurry, the text and picture might not be what our client desired). In our case, our stakeholders offer to check on our application’s copywriting and suggests what to write on our app. We implemented the feedbacks and finally, the design process starts again on a different tasks.
Another example of Me implementing UX Awareness can be seen below:
In this picture, I decided to add a line of text to show how much data (the ‘PPL 5’ is described as one data) is displayed on the page. This way, users won’t have to scroll down and count manually how much data they get when they open the program or just finished filtering the data with our filter function!
Afterword
When we’re creating our program, always remember its purpose. The application’s not just for you, it’s also for me, him, her, and everyone else. Don’t forget to communicate with others to ensure that your program stays true on their job and solves everyone’s problem without making a new one!
After reading this article, I hope you learned about QA, UX Awareness, and their importance to create an ✨amazing✨ application that your user loves. See you in my next article!
References:
HCI course, University of Indonesia