JAKLINGKO
Executing Pay as You Go for JakLingko
Concept execution — user journeys, wireframes, hi-fi screens, edge case documentation. Research conducted by the SixtyTwo research team.
ROLE
Experience Designer
TIMELINE
2022 · ~1–2 months
CLIENT
PT JakLingko Indonesia
VIA
SixtyTwo
STAGE
Concept Execution
WHAT I DID
What I did
1. Translated a one-line concept into a buildable system. Mapped the full Pay as You Go journey across wireframes and hi-fi — activation, scanning, transfers, and edge cases.
2. Designed around real commuter psychology. Built a hold mechanism that avoids the “deposit/debt” feeling, informed by concept testing with 12 respondents.
3. Documented what the UI can’t solve alone. Edge cases, open engineering questions, and wallet-dependent friction — giving the dev team a real starting point.
VISUAL
Three-concepts overview — Pay as You Go highlighted, Park & Ride and Non-Fare Services greyed, “My focus” annotation.
CONTEXT
Context
JakLingko is Jakarta’s public transport integration app — one platform meant to tie together MRT, KCI CommuterLine, TransJakarta, and LRT under a single Mobility-as-a-Service experience.
SixtyTwo was brought in to build a scalable product foundation and test three new feature concepts: Pay as You Go, Park & Ride, and Non-Fare Services.
I was assigned to execute Pay as You Go — scan in, ride, scan out, fare auto-deducted. It’s a simple idea on paper. But it’s also the one that tackles the core friction of how commuters actually pay. Translating it into a real product meant answering dozens of questions nobody had asked yet.
VISUAL
Engagement timeline + three concepts diagram — Discovery → Framing → Design Iterations, with PayG highlighted as my focus.
DESIGNING FOR
Who we were designing for
Before designing anything, I needed to understand who actually uses JakLingko — and why most people don’t.
The research team interviewed 12 Jakarta commuters and mapped them across four behavioral archetypes: Economic Explorers, Idealist Explorers, Conditional Goers, and Comfortist Passengers.
VISUAL
Archetype 2×2 matrix — Explorative ↔ Specific, Flexible ↔ Fixed.
Most active JakLingko users clustered as Economic Explorers — cost-motivated commuters drawn to the app because of its low maximum fare cap. They weren’t loyal users. They were there for a rational reason.
But that also revealed the ceiling. The other three archetypes hadn’t converted — not because they disliked public transport, but because the app hadn’t given them a clear enough reason to switch from physical cards.
The research pointed to a natural progression: deepen value for Economic Explorers first, then use that as a foundation to attract the others. Pay as You Go was the first move in that progression — remove the route lock, make payment familiar, and frame the payment model in a way that respects how Jakarta commuters think about money.
THE PROBLEMS
The problems
I needed to understand exactly what was broken before executing anything. Three problems mattered most.
1. The ticketing system was too rigid
JakLingko sold one-way tickets tied to a fixed route. On the happy path, this works. But the moment a user deviates — say, deciding to exit at a station they didn’t buy a ticket for — the QR code simply won’t scan. No fallback, no notification. The user is left stuck inside the station with no guidance from the app.
VISUAL
Existing unhappy path diagram — unassigned exit → scan fails → user stuck → start over.
2. Payment was unfamiliar and limited
JakLingko only supported FELLO and QRIS. FELLO is an unfamiliar wallet with a confusing top-up flow. Most commuters already use bank cards that work across every gate and mode — so the app’s payment options gave them no reason to switch.
VISUAL
Payment options — old (FELLO + QRIS) vs what commuters actually use (bank cards, OVO, GoPay, etc.).
3. No real benefit to using the app
From the interviews, users still chose physical cards as their main payment method. JakLingko was treated as a complementary tool — something they’d open out of curiosity, or when their card was lost. They didn’t feel any benefit from using it.
I don’t see the point of why should I use the app
INTERVIEW RESPONDENT
RESEARCH
What research told us about Pay as You Go
When the team tested the Pay as You Go concept, the reception was clear: 10 of 12 respondents were willing to shift — if the system was ready.
Occasional commuters prefer cards as their means of payment — perceived as all-in-one, the same card covers toll, parking, and more — and hesitate to shift to digital payment out of worry about technical issues that could disrupt their commute.
RESEARCH FINDING — REPORT SLIDE 16
VISUAL
Concept testing willingness spectrum — “will use for efficiency” → “will use with conditions” → “stuck with card.”
The conditions kept repeating: easy top-up, fewer steps, fast scanning, a system that just works. “If the system is ready” came up again and again.
But when the team asked about deposit and paylater mechanisms, the reception flipped completely.
VISUAL
Deposit/paylater rejection finding — research report slide 66.
Jakarta commuters have what the research called a sachet mentality (ketengan) — they top up small amounts daily and keep minimum balance, so a deposit feels like money taken away. Paylater triggered an even stronger reaction: a sense of debt, of mental miskin. One respondent put it directly — paylater makes you feel poor, the bill keeps coming, and admin fees make it worse.
Paylater makes you feel poor, the bill keeps coming, and admin fees make it worse.
RESEARCH RESPONDENT
This was the critical signal. Whatever payment mechanism I designed had to feel like the user is always in control of their money. No locked funds. No debt feeling.
WHAT I DESIGNED
What I designed
From the problems and the research, I mapped what Pay as You Go actually needed to solve, then built the full journey — activation, scan-in, riding, transfers, scan-out, and every edge case in between.
VISUAL
Full wireframe canvas — zoomed out, showing scope.
The Hold Mechanism — respecting how commuters think about money
The first big decision was the payment model. How do you charge someone who hasn’t finished their trip yet?
The answer: a temporary hold of Rp 15,000 at scan-in. The actual fare is deducted at scan-out, and the rest is returned. Same mechanics as ride-hailing — not a deposit, not paylater.
The framing matters as much as the number. The same Rp 15,000 feels completely different depending on whether you call it a “deposit” or a “temporary authorization.” The research made that distinction the whole game.
VISUAL
Hold mechanism explainer — Scan in (hold 15,000) → Riding → Scan out (fare deducted, remainder returned).
💡 What I learned
The hold mechanism isn’t a technical decision — it’s a framing decision. The same amount of money is involved whether you call it a deposit or a hold, but how you present it determines whether users accept it or reject it entirely.
Activation — earning the switch in one screen-set
A first-time user activates Pay as You Go once, links a balance source, and is walked through what tapping in and out will do. The goal was to make the first trip feel as low-stakes as tapping a physical card.
VISUAL
Activation flow — hi-fi screens.
💡 What I learned
First-run friction is where you lose the card-loyal user. The activation flow had to earn the switch in one screen-set, not over time.
Scan In & Out — as easy as a physical card
This solves the rigidity problem. No more one-way tickets — the QR now works at any station, any mode, any time.
The flow supports two modes: Show QR (the app generates a code for the station reader) and Open Scanner (the app camera reads the station’s QR), because different stations have different hardware.
VISUAL
Scan-in flow — hi-fi screens.
VISUAL
Three homepage states — standby / scan-in active / scan-out.
💡 What I learned
Homepage state management was one of the trickiest parts. A commuter might scan in and not open the app again for 40 minutes. When they come back, the app needs to immediately tell them where they are in their journey.
Tarif Integrasi — making transfer savings visible
Jakarta’s integrated fare gives a discount when you transfer between modes within a time window. I designed the trip summary to show exactly how much was saved.
VISUAL
Trip summary variations — single trip / integrated fare / with penalty.
VISUAL
Tarif Integrasi notification timeline.
💡 What I learned
The trip summary is one of the most important screens in the whole system. It’s the moment users actually see the value of Pay as You Go. If the savings aren’t clear, the benefit doesn’t land.
Trip Planning — now optional
In the old system, planning and ticketing were fused. You had to plan a route to buy a ticket, and you were locked into it.
The redesign separates them completely. Trip planning is now an informational tool, not a transactional requirement. You can scan in at any station regardless of whether you planned anything.
VISUAL
Old vs new trip planning model.
💡 What I learned
Decoupling planning from payment was probably the most structurally important decision. It changes the fundamental relationship — in the old system, planning was mandatory for payment. In Pay as You Go, payment is independent, and planning is just there if you want guidance.
Multiple Wallets
Instead of forcing users onto FELLO, the design lets them connect and switch between FELLO, OVO, and Mandiri Debit — whichever wallet they already trust.
VISUAL
Wallet options — hi-fi screens.
EDGE CASES
Edge cases
The happy path is straightforward. The edge cases are where product design actually happens.
Forgot to scan out — the system detects a double scan-in, shows a “Conditional scan-in” notice, and deducts a Rp 3,500 penalty for the unfinished trip before starting the new one. The trip summary shows both deductions clearly.
Low balance — if the balance drops below the Rp 15,000 minimum, the QR page blocks the trip with a tooltip and prompts a top-up.
Activation failed — a clear error state with a retry option, so there’s no ambiguity about what went wrong.
VISUAL
Conditional scan-in popup / Low balance state / Activation fail — hi-fi screens.
Some scenarios I couldn’t fully resolve in the UI alone, so I documented them as open questions for engineering:
What if the balance runs out while the user is already physically inside the station?
If Tarif Integrasi is already active, does the Rp 15,000 hold still apply on the second scan-in?
Different wallets have different top-up flows (FELLO in-app, OVO external) — how do we standardize this?
VISUAL
Open questions — Figma sticky notes.
These aren’t failures. They’re the natural boundary between product design and system architecture. Documenting them clearly was part of the deliverable.
OUTCOME
Outcome
When I started, Pay as You Go was a one-line concept. By handoff, it was a fully mapped product system across wireframes and hi-fi screens — activation, dual-mode scanning, homepage state management, Tarif Integrasi logic, multiple wallet support, and documented edge cases.
The work went through internal review and usability testing at SixtyTwo, and was presented to JakLingko stakeholders who approved the direction for development.
VISUAL
Full hi-fi Figma canvas — zoomed out.
A well-documented handoff with honest gaps is more useful than a polished deck that hides the hard parts.
LESSONS
Lessons learned
Translating a concept is a completely different job than proposing one. “Pay as You Go” is one sentence in a strategy deck. Executing it means answering questions nobody thought to ask — how the hold works, what happens when someone forgets to scan out, how different wallets affect top-up, what the homepage looks like mid-trip.
You can’t design a payment system without understanding how users think about money. The hold mechanism isn’t just a technical solution — it’s a framing decision that respects the sachet mentality and avoids the mental miskin feeling that would have killed adoption.
The edge cases are where the real work happens. Anyone can design a happy path. The value is in thinking through what happens when the user forgets, when the system fails, when the balance runs out mid-trip — and being honest about what’s solved and what still needs engineering.
CREDITS
ROLE
Experience Designer (concept execution, user journey mapping, wireframes, hi-fi screens, edge case documentation)
TEAM
SixtyTwo — research conducted by the research team; design execution by me
CLIENT
PT JakLingko Indonesia
TIMELINE
~1–2 months, 2022
Danu Izra Mahendra
Info