The Invisible Problem We Keep Building
Last week I was testing a payment button. The click registered instantly—0.8 milliseconds according to Chrome DevTools—but users reported it felt broken. Slow. Unresponsive. They weren't lying. They were perceiving something real that the metrics couldn't catch.
This is the trust-latency gap, and it's been haunting my projects for years. There's what actually happens in the system, and then there's what the human brain decides happened, and they're not the same thing. I'm not sure we talk about this enough in our standups, to be honest—we're obsessed with performance numbers while users are forming judgments in the dark.
The problem compounds. A user perceives delay. They don't trust the action completed. They click again. Now there's actual duplication. The system slows. Everyone loses.
- Your API responds in 300ms but feels like 3 seconds because there's no feedback
- Visual feedback exists but arrives too late, creating cognitive whiplash—does my input matter or did I miss the window?
- We measure latency from server to server, not from finger to brain
- Spotify proved in 2014 that perceived speed beats actual speed. They added fake loading states and people loved it
- Most of us still haven't internalized this
Perception Isn't a Design Layer, It's the Foundation
I spent three months redesigning a dashboard for a fintech client in Medellín. The data loaded fast. The charts rendered in under 400ms. Performance audits were green. Users hated it. Turns out there was nothing telling them anything was happening while the page initialized. The absence of signal felt like failure.
We added a skeleton loader. Not because it was faster—it wasn't—but because it gave the brain something to process. Suddenly the same product felt responsive. I'm still not entirely comfortable with this deception, if I'm being truthful. Are we designing for humans or for our own ego about optimization?
The gap between behold and belief is measured in microinteractions. A subtle scale-in. A color change. Haptic feedback. These aren't decorative. They're translation layers between what the machine did and what the user can trust actually happened.
Haptics: When Touch Becomes Language
This is where I get excited and also completely uncertain about the direction we're heading. Haptic feedback—vibrations, resistance, texture simulation—is finally moving beyond phones buzzing at notifications.
Apple's Taptic Engine changed what was possible. Precise. Intentional. You can feel the difference between a notification and a declined payment. But here's what worries me: haptics requires hardware standardization that doesn't exist yet across platforms. Desktop users get nothing. Web has almost no haptic API support outside specialized browsers. We're building language in a medium that won't be universal for years.
- Haptic friction could replace the need for visual loading states entirely
- Most of the web still can't do it
- You could design a button press that actually feels like resistance, like weight, like consequence
- But you'd be excluding 60% of your users from that experience
I'm designing products for a moment that hasn't arrived yet, and I'm not sure if that's visionary or irresponsible.
Building the Bridge
What I'm experimenting with now is layering these perceptions. Haptic feedback where available. Micro-animations as fallback. Skeleton screens. Audio cues in contexts where they work. Each layer carries information differently. Each one helps the brain say: yes, something is actually happening here.
The trust-latency gap won't close with speed alone. It closes with honesty. If something takes 800ms, don't hide it—explain it. Let the user feel it happening. Give them something to hold onto.
The hardest part isn't the code. It's resisting the pressure to obsess over metrics that don't capture what humans actually experience. Latency isn't a number. It's a feeling. And right now, we're still building interfaces for the dashboard, not for the hands touching them.
