JAKLINGKO
Designing a Payment System for Jakarta’s Transit App
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
TEAM
SixtyTwo
STAGE
Concept Execution
ABOUT
About the project
In 2022, I worked with SixtyTwo, a design consultancy, on an engagement with PT JakLingko Indonesia. JakLingko is Jakarta’s Mobility-as-a-Service platform — integrating trip planning and payments across MRT, KCI CommuterLine, TransJakarta, and LRT through a single app.
SixtyTwo was brought in to build a scalable foundation for the product. My role was design execution: translating a pre-proposed “Pay as You Go” concept into user journeys, wireframes, hi-fi screens, and edge case documentation. The research that shaped these decisions was conducted by SixtyTwo’s research team — I worked from their findings.
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 n Ride and Non-fare services greyed, “My focus” annotation.
WHY PAY AS YOU GO
Why Pay as You Go
The existing JakLingko system was smart but rigid. A trip was bought as a one-way ticket against a fixed origin and destination, so the moment a commuter improvised — got off early, changed lines, extended the trip — the flow hit a dead end. Physical transport cards (Kartu Transportasi) worked everywhere but weren’t smart; the app was smart but too inflexible to trust.
VISUAL
Broken unhappy path — happy path vs. unassigned path in the existing system.
Payment made it worse. The app leaned on FELLO, an unfamiliar e-wallet, and QRIS, while commuters reached for bank cards by default.
Occasional commuters prefer cards as their means of payment. They don’t see the urge to explore alternatives beyond the most widely accepted method; card payment is perceived as all-in-one (the same card covers toll, parking, and more); and they hesitate to shift to digital payment out of worry about technical issues that could disrupt their commute.
RESEARCH FINDING — REPORT SLIDE 16
I just tap my card. Why would I open an app?
RESPONDENT (PARAPHRASED)
Pay as You Go was proposed to bridge this: feel like a physical card — tap in, ride, tap out, fare settles itself — but smarter, integrated across modes, and inside the app.
The hard part was money. Account Based Ticketing needs to reserve fare before the trip is priced. But research surfaced two behaviors that made a naïve deposit model dangerous:
Sachet mentality (ketengan). Commuters top up in small, daily amounts — the minimum to get through today, not a large reserve.
Mental miskin. A strong psychological discomfort with anything that feels like debt. Deposits and paylater framings read as “the app is holding my money” or “I owe money,” and got rejected outright in testing.
So the constraint that shaped everything: reserve enough fare to let someone ride freely, without it ever feeling like a deposit or a debt.
VISUAL
Problems-to-solutions mapping.
WHAT I DESIGNED
What I designed
1. The Hold Mechanism
Instead of a deposit, the system places a temporary hold on the maximum possible fare at scan-in, then releases the unused portion at scan-out and charges only the real distance travelled. The money never leaves the user’s balance as a “deposit” — it’s reserved and returned, framed as part of a single trip rather than a separate debt.
VISUAL
Hold mechanism explainer — reserve at scan-in → ride → release + charge actual at scan-out.
💡 What I learned
A payment mechanic isn’t only a technical problem — it’s a framing problem. The same flow described as a “deposit” gets rejected and described as a “hold during your trip” gets accepted. Respecting mental miskin was a design decision, not a copy decision.
2. Activation
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.
3. Scan In, Ride, Scan Out
The core loop. Tap in at the gate, ride any combination of modes, tap out at the end. The homepage adapts to mid-trip state so the user always knows they’re “in” a trip and what it’s costing.
VISUAL
Payment old-vs-new comparison.
💡 What I learned
The flexibility only matters if the user can see it working. The in-trip state on the homepage is what makes the open-ended ride feel safe rather than uncertain.
4. Tarif Integrasi (Integrated Fare)
Multimodal transfers within a window get the integrated-fare discount applied automatically, with a notification confirming the saving rather than making the user calculate it.
VISUAL
Tarif Integrasi notification timeline.
💡 What I learned
A discount the user has to compute is a discount they distrust. Surfacing the saving as a confirmation does the reassurance work for them.
5. Decoupled Trip Planning
Trip planning was separated from payment, so planning a route no longer locks the user into a fixed, pre-paid one-way ticket. You can plan, but the fare follows what you actually do.
VISUAL
Old-vs-new trip planning model.
💡 What I learned
The rigidity in the old system came from coupling the plan to the payment. Breaking that link was the single change that made every improvised journey valid.
VISUAL
Full Pay as You Go system overview.
EDGE CASES
Edge cases
The happy path is the easy part. Most of the real work was in what happens when it breaks.
Forgot to scan out. If a user never taps out, the system can’t price the trip. I designed a penalty/maximum-fare fallback and a recovery path, and documented the open question of how long the system waits before resolving the trip.
Low balance mid-journey. A user can run out of balance after tapping in. I designed warning states and a top-up path — but top-up behavior is wallet-dependent, and the friction differs by source. This is partly an engineering-owned problem, and I flagged it as such rather than pretending the UI solved it.
Multi-wallet top-up. Different linked wallets affect how and how fast a top-up clears, which affects whether a mid-trip top-up is even viable. Documented as an open constraint for the dev team.
VISUAL
Forgot-to-scan-out / unhappy path handling.
💡 What I learned
A well-documented handoff with honest gaps is more useful than a polished deck that hides the hard parts. The value of the edge-case work was naming what the UI couldn’t solve alone.
OUTCOME
Outcome
Delivered the full Pay as You Go journey: activation, scan-in/out, Tarif Integrasi, decoupled trip planning, and edge-case handling — across wireframes and hi-fi screens.
Documented edge cases and open engineering questions as a starting point for the development team.
The work went through internal review and usability testing at SixtyTwo.
Presented to JakLingko stakeholders, who approved the direction for development.
VISUAL
Full hi-fi Figma canvas — zoomed out.
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