Interfaces
The last mile of a cursor blink
Every product team argues about latency at the edges. Almost nobody argues about the frequency of a blinking cursor. They should.
The first time I noticed the cursor was in a stranger's café, waiting for my rice bowl to arrive. The person next to me was writing a message, and the small vertical line at the end of their sentence pulsed at what felt like the wrong tempo — slightly too fast, urgent in a way the person wasn't. I only became aware of it when it stopped, briefly, as if the machine had thought about something before returning to itself.
Cursor blink rates were standardised in the mid-1980s at roughly one hertz. This was an accommodation to CRT phosphor persistence and to the eye's flicker fusion threshold, not to human patience. Since then the number has drifted, sometimes intentionally: text editors race their cursors to feel modern; enterprise forms slow theirs to feel deliberate; children's software often has no cursor at all, because a small blinking mark is a small anxious mark.
There is a category of decisions in software that everyone treats as invisible. Cursor cadence is one of them. So is the default number of empty rows in a spreadsheet, the delay before a menu closes, the length of a click's ripple. These decisions are the connective tissue between a product's stated tone and its actual behaviour, and they are almost never argued about because they don't have a stakeholder. Nobody's promotion depends on the blink.
I once asked a designer I admire why her cursor felt different, and she looked at me as if I had noticed the colour of her socks. It turned out she had spent an afternoon, years earlier, matching the blink to the easing curve of every other motion in the product — the menus, the toasts, the little checkmarks. It was not in any spec. She had simply decided that if one thing moved, everything should move as though it belonged to the same body.
That word — body — is the one I keep returning to. A well-made interface has proprioception: a sense of where its own parts are and how they move together. When the cursor blinks in the same rhythm the rest of the product breathes in, you stop noticing it, which is the highest compliment a moving thing can earn. When it blinks out of time, you feel the seam even if you never look directly at it.
The result is that most software feels like it was written by many hands who never met. A calm typography paired with a jittery cursor. A patient tutorial that speaks in a rush. If you spend a while paying attention to these mismatches, you start to hear the software's underlying voice: not the marketing voice, not the copy voice, but the deeper rhythm of every small thing that moves without asking.
The economics of this are unforgiving, which is why it so rarely gets fixed. A cursor cadence has no conversion metric attached to it. You cannot A/B test your way to a soul; the effect is real but it is diffuse, spread across ten thousand tiny impressions that never resolve into a number a quarterly review would respect. So it falls to whoever happens to care, on whatever afternoon they can steal.
I have started to think of these people — the ones who fix the blink nobody asked them to fix — as the actual authors of the software I love. Not the founders, not the growth teams. The person who, at some point, sat with the idle screen and decided it was tapping its foot, and quietly slowed it down.
I don't have a prescription for cursor blink rates. I suspect the correct number is closer to 0.7 hertz than to 1.0, and that it should be tied — quietly — to the weight of the sentence being written. What I do have is a small habit: when I try a new product, I put my hands in my lap for thirty seconds and just watch it idle. If it feels like the machine is tapping its foot at me, I know something is off, even if I couldn't yet name it.