Not true. Faster isn't _always_ better. If some features seem to take a lot of time, it appears to the user that it's "working". Take a website I hate a lot - TurboTax. A lot of the wait times between transitions is incredibly long. But I'd bet money that it increased conversions.
Yes, it's more of a UX issue than an engineering one. But users don't give a shit. If something appears slow, no one knows/cares if it's an animation or a slow server.
Sigh... Thinking up a different situation (or even an exception) doesn't make a general statement "not true". We aren't arguing mathematical theses here.
It is true that Intuit inserted some explicit delays to give the impression that their software is "working" really hard to deliver value. But, TurboTax is still very snappy in response to user action. That response is often an intentionally long, slow animation carefully designed to help you keep calm through a stressful process. But, the response came quickly.
Personally, I have measured direct correlations between our apps' latency&stutters vs revenue trends. This effect has been well publicized by Google and others. Users don't consciously give much of a shit. But, their behavior in end is significantly affected regardless.
>Sigh... Thinking up a different situation (or even an exception) doesn't make a general statement "not true". We aren't arguing mathematical theses here.
It's amazing how often people confuse discussion for mathematics...
While you're right that people sometimes value operations that take time, that's certainly an edge case - in general, snappiness leads to a better user experience.
Also: if an operation is fast, you always have the option to make it appear slower. The inverse is not true.
> in general, faster operations leads to a better user experience
That's just too general of a statement. That's like saying a landing page with a hero image is, generally, a better page. It's a good place to start, but it's just bad advice in the long-term.
I agree that response times from the backend should be fast, especially the initial response (as the article mentions). But anything on the frontend experience should be judged on a case-by-case basis.
Every time I've ever conducted user experience testing the results have always been far more positive the faster the app or page is. In fact, while it's still only anecdotal, I have never seen a decrease in any of the overall measurements of a user study where, between two versions, the speed of the app or page improved and little else changed.
Honestly I think it's a great general statement. I'm sure there are exceptions but that's the case with almost any general rule of thumb.
> That's like saying a landing page with a hero image is, generally, a better page.
No, not at all. Speed isn't everything and no one was suggesting that. A faster application, however, is always better than a slow one as long as you are comparing apples to apples.
With the way technology works nowadays it's actually very doable to get the 75th percentile to load really, really fast. But it's not without effort and earlier work may need to be redone, something many avoid at all costs.
If the UI is quick to inform I'm happy to wait for a big task to finish.
Even if the message is nonsense, I just want to know work is still occurring
"Reticulating splines" may not mean the app is just reticulating splines, but I know it's doing something, and I'm less concerne my Sim City hasn't loaded
But with things like my iPhone where the UI just halts after some requests and quits responding to input without me knowing why, is bullshit
I want my software to listen to me and inform me about the status of work I'm performing
I wish more work was done in operating system UIs informing users. I use a terminal a lot and can see what's going on as I work
The OS should be capable of detecting overload, and take control enough to alert to degraded general operation and inform as to what's up. Possibly offering options to resolution
I remember a study done a while back that found there are kind of "islands" of wait time that are acceptable, and "valleys" that are annoying.
I can't recall the numbers, but it was something like under xxxms was consitered "instant" and therefore wasn't an annoyance, from xxxms to 1 second is consitered annoying because it's too slow to be "instant" but not slow enough to let you context switch. Then from like 3-5 seconds was another "island" as it's enough time to context switch then return.
The end of the study found that by delaying some actions that were in the "valley" to be slightly longer and making them consistent it was reducing frustration while using the application.
I think there's a difference between "fast" and operations that take a while. Apps that do slow things should still be fast, even if fast just means "fast to pop up a progress meter".
Also, I ditched TurboTax for TaxACT in part because it was a much less ponderous experience. Anecdotes aren't data and all that, but I doubt TurboTax is super sophisticated about measuring their in app funnel.
The single site I visit the most when I am on mobile is Hacker News. The reason is simple: It's very fast and well structured, and most importantly it is free from bloat, no ads or unnecessary menus.
I feel like Hacker News is pretty much the best example for the concepts mentioned in the blog post and it proofs that beeing fast can be a sites main feature (or one of them).
In addition to this, it's important to validate on your own system. Your company's specific mix of traffic characteristics, offer, etc., means that not everyone will see the same results. Even for best practices.
I just ran a split test (>99% significance) where adding a heavy Salesforce chat widget to the site correlated with a 40% increase in the primary CTA actions taken. Adding in the chat leads, it was more like a 70% lift. From making the page load more slowly.
We verified that one a few times, but the results were consistent.
Your argument sounds like Stockholm-syndrome. Its not so much "faster" as it is latency. Any time the feedback between idea and execution starts to lag, it becomes painful.
Also, performance is important in the same sense that efficiency is important. If you can run the same logic with half the processing power you'll be able to either run more processes or shrink the necessary processor size.
Software may be a heavenly world of abstraction, but in the end the hardware has to pay for our sins.
I totally agree that app speed should be considered along side all other interface usability. There is probably a list of customer-requested features, bugs, marketing tricks, and other UI attributes that should be prioritized according to their ROI (projected affect on sales versus cost of implementation.)
Too often speed is seen as a back-end engineer thing when it should be handled the same way as any customer-facing feature.
Yes, it's more of a UX issue than an engineering one. But users don't give a shit. If something appears slow, no one knows/cares if it's an animation or a slow server.