
Where research, systems thinking, and visual design come together.
KRL is one of Southeast Asia's busiest rail networks — yet its app offered almost nothing beyond a basic schedule. This thesis asked: what would it look like if the app was designed around the journey, not the system?
TYPE
Undergraduate Thesis
MY ROLE
Solo researcher & designer
METHODS
Interview · Survey · Observation
TOOLS
Figma
Published — FINAL THESIS
Perancangan Ulang UI/UX Aplikasi KRL Access - Bachelor Thesis
THE PROBLEM
The app was designed around the system's logic — not the commuter's journey.
The most critical information — departure time — wasn't visible when you opened the app. The layout was cluttered but incomplete. And beyond a basic schedule and train tracker, the app offered almost nothing else.
Hidden info
Departure time buried 3–4 taps deep
Cluttered layout
Busy interface, no clear hierarchy
Untapped potential
Schedule & tracker only — nothing more
RESEARCH
PT. KAI IT dept
Technical constraints & system capabilities
UI/UX designers
Expert validation on interaction patterns
Commuter interviews & survey
Users, ex-users, and non-users
Station observation
Real behavior at multiple KRL stations
Who I designed for
The Daily Regular
Same route every day. Knows the schedule by memory — but completely lost the moment there's a disruption. The app gives them nothing when things go wrong.
Needs: real-time alerts · visible departure time
The Occasional Traveler
Uses KRL for unfamiliar routes. The app feels hostile — too much information, no guidance. Multi-transfer journeys are especially confusing.
Needs: route planning · transfer guidance
KEY INSIGHTS
Departure time was the first question — always
Every interview pointed to the same thing: "Is my train there yet? When does it leave?" The app required 3–4 taps to answer this.
Disruptions spread by word of mouth
When service was interrupted, commuters found out from each other or Twitter — not the official app. A failure of trust, not just UX.
Multi-transfer journeys were unsupported
Connecting between lines required mental planning or third-party apps. Each leg was a separate search — no end-to-end view existed.
Non-users all said the same thing
"Too complicated." "I can't find what I need." The app was pushing away the people it existed to serve.
KEY DESIGN DECISIONS
Lead with departure time, always
The home screen surfaces the next upcoming train immediately on launch — no searching. One number. Immediately visible. This single change addressed the most consistent pain point across all research.
Build for disruptions, not just schedules
The redesign added active function: alert commuters when something changes. Disruption notifications, delay warnings, and line status — designed as core components, not buried settings.
Expand what the app can do
New features grounded in research gaps: integrated QR ticketing, end-to-end route planning, service news, and a whistleblower channel — all things commuters were handling through other channels because the app wasn't helping.
Simpler layout, more capability
A busier app doesn't have to feel busier. Cleaner hierarchy and consistent type scale made the interface calmer — even while doing more. The goal: an app that does the thinking for the commuter.
BEFORE REDESIGN
FINAL DESIGN
REFLECTION
The hardest design problems here weren't visual — they were structural. Deciding what information deserved to exist at all, and what was just noise.
Designing for a system with millions of daily users taught me that scale turns small friction into large human cost. Every extra tap to find a departure time, multiplied across a million commuters, is a million unnecessary moments of stress.
If I continued this project, I'd go deeper on disruption states — getting people the right information at the worst moment, when the train isn't coming and they need to decide fast, is where the design could make the biggest real-world difference.







