← Research

Seven times the same click

When repetition in the data isn't confusion — it's a request the product has no surface for

Beltmar·Sep 10, 2026·3 min read
Share

We watched a user click the same button seven times in 90 seconds. Our first instinct — and the instinct of every analytics tool that flagged it — was that something was broken.

It wasn't.

Here's the sequence, anonymized but real. A mid-market SaaS product, the kind with a solid dashboard and a settings page that does what it promises. The user — let's call them K — logged in on a Tuesday afternoon, navigated to a report view, and clicked the export button. Then clicked it again. Then five more times, each click spaced about 11 to 14 seconds apart. No rage-clicking. No rapid-fire frustration. Eleven seconds is long enough to look at a result, decide it isn't what you wanted, and try again.

The export worked every time. Seven identical CSVs landed in K's downloads folder. In the event log, this looked like a bug report waiting to happen, or maybe a user who didn't understand the feature. The product team's automated triage flagged it as "repeated action — possible UX confusion" and moved on.

We didn't move on. We pulled the surrounding context. K had visited the report view six times in the previous week, each time adjusting a single filter — date range — before exporting. On this Tuesday, K adjusted the filter, exported, adjusted again, exported again, seven iterations. The filter reset after each export. K was rebuilding the same report across seven consecutive date windows, one export at a time, because the product had no way to batch-export or select multiple date ranges.

The repetition wasn't confusion. It was a workaround so practiced it had its own rhythm. Eleven seconds: just enough time to change one dropdown, click export, and wait for confirmation. K had done this before. K had a system.

This is the kind of sequence that disappears inside a funnel chart or a session-duration average. Seven clicks on the same button aggregates into "high engagement with the export feature." Looks healthy. Feels like retention. But the story, read at the level of the individual journey, is a person compensating for a missing capability. That's not engagement. That's patience wearing a groove into your product.

What interests us isn't the feature gap itself — every product has them. It's that the signal was legible the whole time, sitting in the event stream, and the tooling read it as noise. Repeated actions get bucketed as errors or as enthusiasm. Almost never as requests. But a request is exactly what a workaround is: the user telling you, through behavior, what they wish your interface could do. They're just telling you in a language your dashboards don't parse.

The timing matters more than the count. Seven clicks in 2 seconds is frustration. Seven clicks in 90 seconds, each preceded by a filter change, is choreography. Same event name. Completely different meaning. If your instrumentation only records the what without the cadence, you're reading sheet music without the time signature.

We brought this to the product team. They added a multi-range export within a few weeks. K used it on day one. Export frequency dropped from seven events per session to one. In the dashboard, it looked like a decline in engagement. In the journey, it looked like relief.

There's a counter-argument worth naming: not every repeated action is a hidden request. Sometimes people genuinely don't see the confirmation toast. Sometimes the button is actually broken on one browser. Reading intention into behavior is risky, and we've gotten it wrong. The difference, when we've gotten it right, has always been in the surrounding sequence — what the user did between the repeated actions. If the answer is "nothing," it's probably frustration. If the answer is "a small, consistent adjustment," someone is building something your product didn't expect.

Most event logs are full of these quiet choreographies. They just need someone willing to read at the tempo the user was moving.

More from Beltmar