What is worth waiting for?

What about speed? No, not the Keanu Reeves movie, but the speed of your product. How much thought have you given it? When building a product, speed is the one aspect that I think is often overlooked, yet it’s one of the features we have a lot of influence over.

Take a minute and think about it… Speed can keep us from making a purchase, navigating through a website, or can even seriously harm our view of a brand. We barely notice when a company does it right, but they enjoy huge sales and ensured brand loyalty. It really is the secret feature that everyone knows about.

The list of things you can do to improve your product’s speed is long (and to be honest, often technical). Reducing server requests, minimizing code, and optimizing images are a good place to start. We think, “of course we can do that,” but all of the fancy aesthetic design (custom fonts, etc) choices, new functionality, and increased content cancel out any progress we thought we made. The truth is our users tend to care more about speed than bells and whistles. They want the information now. Did I mention that search engine rankings now consider speed too? How about that?

Bells and whistles can occasionally serve a purpose, but the load time due to analytics and tracking scripts is becoming insane. When the GDPR launched in Europe, USA Today decided to launch a European version without tracking and ads - bringing the page size from 5.2mb to just 500kb - a decrease of nearly 90%!

Nick Heer disassembled a CNN article only to find it contained 11 web fonts (414kb), 4 stylesheets (315kb), 20 frames, 29 XML HTTP requests (500kb) and approximately one hundred (100!) scripts totalling several megabytes.

The vast majority of these resources are not directly related to the information on the page, and I’m including advertising. Many of the scripts that were loaded are purely for surveillance purposes: self-hosted analytics, of which there are several examples; various third-party analytics firms like Salesforce, Chartbeat, and Optimizely; and social network sharing widgets. They churn through CPU cycles and cause my six-year-old computer to cry out in pain and fury. I’m not asking much of it; I have opened a text-based document on the web.
Nick Heer - The Bullshit Web

Speed is a two-way street

While there’s lots you can do to minimize the page load in your end, speed is a two-way street and even with the most efficient product, there’s one thing you can’t control - the user’s connection. We can make our mobile apps load fast, optimize images, and reduce features that aren’t used on mobile, but it’ll only get us so far. If the user is on a slow carrier connection, there’s nothing we can do to improve that situation.

This is a situation that I’ve found myself working around lately in my work. The product I’m working on has many users in Asia with slower connection speeds. Often they also need to go through a VPN as well which slows them even further. So does that mean there’s nothing we can do to better serve these users?

Of course not!

Jacob Nielsen wrote a great article on this topic that we’ve used as a guiding star in our work. The gist of it is this: There are 3 main time limits (which are determined by human perceptual abilities) to keep in mind when optimizing web and application performance.

You can adjust the timings to what fits your situation, but basically we will think of scenarios from these three time limits:

The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]:

• 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
• 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
• 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

For anything that’ll take 10 seconds or longer and we’ll show a percentage indicator so the user gets an idea of the anticipated waiting time. Why? Because users don’t actually hate waiting, they hate not knowing how long they’ll have to wait. This is something that call-in customer service center’s have known for years. Call a customer support line and you’ll likely be greeted with the anticipated waiting time. Being told the wait time is 6 minutes may seem like a long time, but waiting for 6 minutes without being told will feel like a whole lot longer.

Not only does being given the the anticipated wait time give you a reference - it gives you something that’s even more valuable to users - the data needed for making a decision! 6 minutes? Ok I’ll hold. 34 minutes? No I’ll call back later. Without knowing the anticipated waiting time we don’t have the knowledge to make that decision. Wouldn’t you want this information for a lot more interactions in your life? Dinner at your mother-in-laws will be four hours. It sounds like you have a decision to make.

Finally, as you’re aware from waiting on the phone - the time remaining decreases. 6 minutes, now it’s 4 minutes and boom - you’re in. The same input is extremely useful dealing with technical data intensive digital tools. Has it crashed? Is it still processing? A visual indicator is there to show the user that the tool is still working - and even to give you something to rest your eyes on! This is why you’re hearing music while waiting on the phone. The music might be pretty terrible, but in most cases, it at least beats silence (and if not, at least give them credit for trying).

No man is an island

Just like no man is an island, no problem has only one solution. It’s therefore important to remember to tackle things like page speed from multiple angles as there’s only so much you can do on each front - but combined you can achieve far greater results. It is important to look creatively at the problem, collaboratively, and present the solution in a way that considers the user’s needs first. While I have some good ideas on how to improve this experience, my opinion is not the end all. It takes many minds to look at a problem as complex as making our speed strangled digital world faster - or at least more tolerable. So, what is your answer? What are the best solutions increasing our speed? How can we make ourselves more comfortable during the inevitable waits? I’m curious to hear what you have to say!