Redesigning KAI Access — a UX case study

Debora Paskarina

Published in

UX Playground

6 min readJan 5, 2022

Goals

KAI Access is an official application issued by PT Kereta Api Indonesia (Persero). This app is aimed not only for train ticket-selling but also to offer convenience and service for their customers (Source: KAI). KAI Access currently offers a few services such as Ticket Cancellation, Rescheduling Tickets, Purchasing Local Train Tickets, and e-Boarding Passes.

⚠️ Disclaimer: Official PT Kereta Api Indonesia (KAI) does not do this. This is just a concept that I came up with on my way on the train provided by PT KAI. None of the contents, fonts, or colours belongs to me. I used them purely for learning purposes.

My Proposal

Instead of overhauling the existing KAI app, I will add subtle and useful features such as:

UX Workflow

1 — Empathize

The steps in the Empathize Phase went as follows:

🧸 Customer Feedback: (also a little bit of background story)

On December 23, I was on my way from my current location (Malang, ID) to the capital of the Republic of Indonesia (Jakarta, ID). Post-arriving, my friend chatted me up and it brought me to the idea of redesigning the KAI Access app. It went like this:

✂️Heuristic Analysis

I started my research with Heuristic Evaluation. I picked which one of the pages' elements in KAI Access violates the 10 Usability Heuristics in User Interface Design. In this section, we only focus to evaluate KAI Access’ interface.

The analysis of KAI Access’ heuristic violations can be seen below:

🔒 User Interview: Scope

Following the Heuristic Analysis, as it is a personal project, I had set boundaries/range of scope to design a simple solution.

🕵🏼‍♂️ Potential Users Interview

I selected young people as users who travel frequently and often use train ticket booking. I chose this category of people to understand the pain points and their day to day challenges.

The step of conducting user interview went as followed:

I conducted an initial field search.
I sent the survey questionnaire.

💬 Key Quotes directly from the users:

“KAI has an application for local ticketing?”
“What is the difference between the Executive Class and Business Class?”
“We can purchase local ticket through KAI?” *is flabbergasted*
“I like the Economy Class in trips with train because it’s much better than it used to be”
“I don’t know the difference between Executive and Business Class, only that there’s a difference in the price.”

2— Define

The steps in the Define Phase went as follows:

📊 Competitive Analysis

KAI Access’ Preposition and Comparison to Its Competitors

As determined above, we can short-list the competitors and we find out that Traveloka and PegiPegi are the closest competitors.

👦 Persona Building

Merry and Luficer (the personas) portray a large portion of ticket-booking app users. Mainly they’d like to use applications that can be efficient and not time-wasting.

🗺 Empathy Map

Following the personas, I mapped out what it’s like to be in Merry’s shoes for a while.

3 — Ideate

🛠 User Flow

In the Ideation phase, I made a Task Flow to differentiate between current and proposed user flow.

⚙️ Wireflow

And so the Wireflow goes like this:

4 — Prototype

Like any other products, applications too, are in need of preparation and testing. I ‘prepared’ the basics through the Low Fidelity Prototype and later on I ‘polished’ it and make it pretty through the High Fidelity Prorotype. Lastly, I needed to test the final product because customers are always first.

🎨 #1-Low Fidelity Prototype

🎨 #2-High Fidelity Prototype

👓 Prototype Testing

I asked a Manager of the Design Division in an EduTech Start-Up as my design critic. The feedbacks mainly consisted of how the information is grouped.

5 — Testing

💻 Usability Testing

Executing the Usability Testing needed a lot of preparations, such as recruiting testers, preparing for tasks’ scenarios, and the testing process itself.

I used tools such as maze.co and Google Form to conduct Usability Testing. During the Usability Testing, users were asked to think out loud so that they could voice what they are thinking and feeling. There were 10 testers participating in the test.

There are two metrics used in the test: Single Ease Question and System Usability Scale (SUS). SEQ was asked right after each task was executed, and the overall score of the SEQ is 6.7 out of 7.

📝 Surveys

Another thing that can give an insight into the user’s experience is the System Usability Scale (SUS). There were 10 item questionnaires sent to users for the before-after design with five response options for respondents, from Strongly disagree to Strongly agree. Based on research, a SUS score above a 68 would be considered above average and anything below 68 is below average (source) and the SUS score for the proposed idea is 72.