BSI — PIN Confirmation Security.
Every digit on BSI's PIN confirmation screen lit up teal the moment it was pressed — standard tap-feedback, used everywhere in the app. On this one screen, it also meant the PIN was readable off the colors alone. I proposed removing it entirely.
I joined BSI — Bank Syariah Indonesia, formed from the merger of three state-owned Islamic banks and now one of the largest Islamic banks in Southeast Asia — right after that merger, taking over a component library that had drifted out of sync with the new brand. Most of the work was systems-level — rebuilding shared components, running usability tests on core banking flows. This case study is about one screen that came out of that work: PIN Confirmation, the last step of every transaction in the app.
The pattern
BSI's number pad used the app's standard tap-feedback: press a digit, it fills solid teal; release, it goes back to white. Consistent with every other button in the app — which is exactly why nobody had questioned it on this screen.
The risk
On a PIN confirmation screen, that color change maps one-to-one to the digit being entered. Anyone glancing at the phone — over a shoulder, or on a photo taken after the fact — could read the PIN off the flashing buttons without ever reading a number.
Resting vs. pressed. That teal fill was the entire problem — it told you which number had just been tapped.
A pattern that looked right everywhere else
Noticed it during routine design QA on the confirmation flow — the same tap-feedback used app-wide, applied without a second thought to a screen where it wasn't just cosmetic.
Testing the concern before pitching a fix
Ran A/B testing on the PIN screen with internal BSI users before proposing anything. The shoulder-surfing worry came up unprompted, in their own words — public places, PIN entry, someone standing close.
Bringing data to my lead, not just an instinct
Took the test results to my lead along with a proposal: strip color feedback off the number pad entirely, and move all visible state to the dot row above it.
The number pad now stays completely neutral, pressed or not — no fill, no color, nothing that changes with which digit was tapped. All the feedback moved to the six dots above it: they fill in one at a time as the PIN is entered, and that's the only thing on screen that changes state.
Before settling on moving all feedback to the dot row, I sketched two other directions. Randomizing the number pad layout on each entry would have defeated shoulder-surfing on its own, but it breaks the muscle memory people build for a screen they use several times a day — trading one risk for a worse everyday cost. Haptic-only feedback, dropping visual confirmation entirely, felt safer on paper but left no visible cue that a tap had registered — exactly the kind of ambiguity you don't want on a PIN screen. Keeping the dots as the only visible state change closed the leak without asking anyone to unlearn how they already used the pad.
Same screen, mid-entry, from the shipped app. The dots move. The keypad doesn't — by design.
I don't have a dashboard number for this one — it's not the kind of fix that moves a chart. What it did was close a side-channel that had no reason to exist on a transaction PIN screen, using feedback from the same users it was protecting.
The most dangerous feedback is the kind that feels right. That teal flash matched every other button in the app — consistent, expected, and exactly why nobody had questioned it. Security work isn't always about adding a warning; sometimes it's noticing which pattern doesn't belong on this one screen. What I'd do differently: I fixed the instance but didn't push to turn it into a system-wide guideline before I left — flag every screen where a “consistent” pattern might carry unintended meaning elsewhere in the app, so the next designer doesn't have to notice it by accident the way I did.
More case studies.
See the rest of the portfolio — design systems, dashboards, and everything in between.