Instant responsiveness in user interfaces is annoying

[zero-sharp]

I hardly make posts on this forum and I don't see people talking about this. This is a personal gripe/rant with a lot of modern applications. Here are some examples of what I mean:

1. As I'm typing text into a search input, the interface wants to instantaneously pattern match my search and offer the best results. Sometimes this is helpful. In other situations, this can take my attention away by opening extraneous menus or interactive elements. To be honest, I just want to finish typing my search. Stop asking me for more input as I'm typing my input.

2. Certain websites are designed to open menus/interactive elements as the cursor hovers over particular web elements. For me, this is sometimes another distraction. Just because I moved my mouse, that doesn't mean I want to see yet another menu. The instant responsiveness can lead me to click in the wrong places due to unexpected interface components showing up. I can't tell you how many times I've chained several misclicks due to unexpected links/buttons (or lack thereof as described in 3 below).

3. Responsiveness creates expectations for feedback. Then, if some part of your application starts to lag (maybe it's the internet, maybe it's my computer), you lose the responsiveness and I get annoyed.

Am I just becoming a grumpy old guy?

[ksec]

It is not that "Instant responsiveness in user interfaces is annoying". It is that certain features should not have Instant responsiveness, while other features should.

Generally speaking I want instant response especially on native apps, but I agree with all the examples you gave especially when it has something to do with Internet. I actually want consistent rendering time across the site rather than fastest possible page view every time.

[hiAndrewQuinn]

Websites, websites, websites. Of course instant responsiveness is going to be annoying when you have a >30ms network call with P99 an order of magnitude above that in the mix. If you want real, deep breathing instant responsiveness, you gotta commit to the bit. Go local or go home and denounce, for everyone's own sanity.

I've recently been polishing up [1] for commercial release. It's a product that serves a real need for a niche community, and it's one that I built and use every day based on my own experiences for what I need as a member of that community, so I have even more reason than usual up get it right.

Truly instant responsiveness means putting the data as close and as hot to the end user as physically possible, to the point I wrote and tweaked my own trie implementation to get it just right. And even there with some of the new commercial features I'm starting to run up against ever so slightly noticeable input lag, and it really makes the whole experience feel clunkier than it should. Considering adding a 50ms denounce just to hide my shame...

[1]: https://github.com/hiandrewquinn/tsk

[provinescoch293]

You’re not grumpy—you’re reacting to “micro-aggression UX.” Instant-everything steals your locus of control and forces cognitive load you never asked for.

Easy fixes: • Search: add `?instant=0` or `debounce=300` to the URL (works on most Algolia & Elasticsearch front-ends). • Hover menus: enable “Reduce motion” in OS settings; many CSS media queries will swap to click-only. • Global: uBlock Origin’s `:has(:hover)` filter nukes 90 % of hover pop-ups.

If you build UIs, ship a 150 ms debounce by default—fast enough to feel alive, slow enough to respect human rhythm.

I bake that delay into every demo on my AI image tool: type a prompt, nothing flashes until you stop—then FLUX Kontext renders in 2.3 s flat. Try the no-jitter editor at https://flux-kontext.io

[pillefitz]

First I was annoyed by your response, then intrigued: It reads LLM-generated, but is it? If yes, how did it make the link to your app?

[didgetmaster]

Is the feature to disable a 'submit' button after you press it ever used anymore? I hate it when you click a button to complete a transaction and nothing happens for a long time. You think the button missed the mouse click so you press it again, only to find your order just doubled!

[layer8]

I agree with your points, especially #2, but I wouldn’t call that “instant responsiveness”. Reading the submission title, I was expecting advocacy for favoring UI animations over an instantly responsive UI.

It’s good for a UI to be immediately responsive to user actions, as long as the response matches the user’s intent. So it’s not the responsiveness that is the problem, but the response not matching the user’s expectations.

[al_borland]

#1 is especially annoying when it locks up your ability to type, because the site is busy trying to query the first 2-3 letters of the input. The whole process ends up taking longer. If #1 causes #3 to suffer in any way, it's an anti-feature and slows everything down.

#2 can be an issue the opposite way as well, such as manufactured delays. Think of a modal window that pops-up after you've been on a site for 5 seconds and are just about to click a link, but instead click the modal. Or you begin reading, are 2 sentences in, and the modal pops up. When this happens, I close the page. It's so frustrating.

[ahdanggit]

crates.io suffers from this on huge crates (e.g. the windows crate) the first time I experienced it I thought something was broken.

[satvikpendem]

This is why a good design sense is important and it always makes me laugh to hear on HN of people wanting instantaneous responses with zero animations on websites. It sounds good in theory but not so in practice. There have been studies to show that people don't think anything has happened if for example they click a button to compute something and it instantly runs and returns. A delay is actually more comforting to them.

[3036e4]

You can have visual feedback without delays, so that is no excuse. A UI that operates as fast as I can type, with no visible frame-skips, or click is always going to feel better to use than some sluggish bloat ui.

[aosaigh]

I agree with your points. I think the main issue is that most developers don’t consider UI.

They consider app functionality and features, or look-and-feel and design, but they ignore UI (or don’t know what good UI is).

Like you described, even a simple search bar requires careful thought and experimentation to get right.

Another issue is UI libraries. People plug these in thinking they solve everything but in reality they only get you so far.

[xplt]

I especially love the part of "instant responsiveness" where a UI changes on interaction an then just shows placeholders while actually fetching data for 2-5 seconds.

Otherwise, snappy interfaces are kinda nice.

[bediger4000]

Isn't the issue variable response times? You get used to some sequence of clicks and changes in the interface. Occasionally one response is much slower, so your clicks go away

[rrgok]

It is amazing how most replies make the software engineer or developer the culprit of this. How the user interact and sees the product is the role of UI/UX designer.

[Ethee]

Except that's not really true. Take OPs example of the search bar, in most shops as a UI/UX designer you put a search bar on your figma page and hand it off to the engineer who then implements it. It's entirely up to the engineer how the search functionality is going to work, am I going to query my backend on every keypress? Depending on how big your database that could be anywhere from 50ms-1s for a response PER KEYPRESS, which is exactly OPs problem. I don't see how the UI/UX designer is going to fix or solve that.

[ted_bunny]

I always hated mouseover menus, but haven't they gone out of style at least?

[3036e4]

Always seems random to me. Can't guess if a menu is going to display itself or wait for a click. The worst kind behaves differently if you click or not. Clicking the menu button brings you to some kind of special menu/profile page, but hoover for a while and instead you get the actual menu to pop up.

Or the menu displays itself, just when I decided to click, so my click instead closes the menu just as it appears.

[benoau]

#2 happens to me a lot, never ceases to annoy me.

[adrianwaj]

Speaking of annoying and never pointed-out, shouldn't all the text in the HN top-posting box be darker.. it's like the OP is being downvoted from the outset? Makes people less responsive.

[al_borland]

I think this is done to discourage text posts and encourage linking to an original source. This way HN links to good and interesting things, rather than being the site holding these things. We can see how the latter can go poorly with how things have gone with Reddit.

[supriyo-biswas]

There is no downvoting on posts; it’s intentionally like that to avoid the use of this site as a blogging platform.

[samdoesnothing]

This is really a taste issue, and many developers lack it.

[bitpush]

haha, there is that word again - "taste", another way of saying design sensibility, or "good eye". "Taste" is now gaining popularity, ever since LLMs have made is accessible for anyone to create anything.

At its core, the idea is the same - some folks can produce exceptional products with same tools, but it is now packaged for the LLM era.

[jabjq]

Or they are just lazy. Recently I had to implement text search and making it load the results instantaneously on every keystroke is easier than implementing a delay. I was hoping the client wouldn’t complain, and thus far he has not.