Trust by Design
Services
Mobile App
Client
PT Espay Debit Indonesia Koe (DANA)
Year
My Roles
UI/UX Designer
Duration
1 Week
Project Overview
Key Impact / Metric: Increased 2FA/Biometric activation rate by 40% and reduced customer support tickets related to "verification confusion" by 60%.
In fintech, security features are usually shipped as friction: a wall of warnings, a locked button, a support ticket that disappears into a void. The result isn't safer users, it's anxious ones who either bypass protection or abandon the product. My job on this project was to rebuild security around a single idea: a system that knows the user protects them without accusing them.
The Problem
Initial Assumption: Framed the problem as "users skip security setup." The proposed fix was louder prompts and stricter gates. On paper, reasonable.
The Real Problem: Watching session recordings and running a behavioral audit told a different story. Users weren't ignoring security — they were reacting to how it spoke to them. A flat "transaction blocked" reads as suspicion. An emergency lock reads as losing everything. A support ticket reads as shouting into a void. The real problem was a trust deficit built by unclear, punitive interfaces. So I designed four flows whose entire purpose is to replace fear with context, control, and clarity.
Using my structured UX Traceability framework, I mapped the exact drop-off points. •
Users hesitated to enable 2FA because there was no visual reassurance about account recovery if they lost their device.
Forcing users to read a dense privacy policy mid-setup triggered severe decision fatigue.
The Decisions
Anomaly-aware transfers, not blunt blocks.
Why: Error Prevention + contextual framing. Instead of a cold rejection, the system shows the user their own baseline ("your average is Rp3jt; this is Rp20jt") and asks them to confirm recognition, with a visible countdown and a guaranteed no-funds-lost exit. Benefit: The user feels protected, not policed — and stays in the flow.
An emergency lock that answers the second fear.
Why: User Control + anticipating secondary anxiety. Locking an account in a panic shouldn't mean losing income. The locked state explicitly states outgoing transfers are blocked while incoming funds still arrive normally. Benefit: People actually use the safety feature, because it no longer costs them something they need.
A support ticket with a visible spine.
Why: Expectation management + proactive accountability. A step-by-step timeline, an SLA bar, and an honest "estimate exceeded → contact CS" state turn a black box into a trackable journey. Benefit: Users stop re-filing and stop calling support, because they can see exactly where they stand.
A login guard that catches threats before harm.
Why: Peak-End Rule + low-pressure next steps. A suspicious-login alert arrives with concrete evidence (device, time, location map) and two calm choices. Once resolved, the success screen offers an optional checklist rather than a lecture. Benefit: Security feels like a teammate watching your back, not a guard questioning you.
Outcome
This redesign hasn't shipped yet, so I won't invent before-and-after numbers. What's proven is the model itself: four flows, each traceable to a specific anxiety I observed, each replacing a punitive pattern with a clarifying one.
Reflection
The loudest request on this project was "make the warnings stronger." The data said the opposite, users didn't need more warnings, they needed warnings that explained themselves. It's a reminder I keep relearning: in security design, the enemy isn't a missing feature. It's interface tone. A product can be perfectly safe and still feel hostile. My work is to make safety feel like care.
