How Houston Airport solved your app’s loading woes

Not so long ago, 2013 to be precise, our old friend (or perhaps fiend?) the buffering spinner was everywhere. At the time, we were pre-4G, and the average download speed for the UK was a measly 14.7Mbps, yet online video was being consumed at an ever increasing rate.

As video play speed was generally faster than download speed, videos would first buffer to provide sufficient padding before they would start to play, thus the old buffering spinner was a common sight. Apps like Vine got around this issue by focussing on super short, generally low resolution videos but as 4G rolled in and download speeds increased, the necessity to buffer disappeared, so too began the process of truly improving user experience during loading.

If, like me, you’ve ever taken a 15 minute detour on a clear road to avoid 10 minutes in traffic this next example will resonate with you perfectly.

A few years ago, Houston Airport was inundated with huge numbers of complaints from passengers that it took too long for their bags to arrive on the baggage carousels. In response, the executives worked out a plan to speed up the baggage handling process and managed to reduce the average waiting time to 8 minutes from the passengers arriving at the carousels, which was well below the industry benchmark at the time.

This was quite rightly considered a huge success but while the executives patted themselves on the back, the complaints still came in thick and fast.

It was at this point some bright spark realised that the pain point was the wait itself, not the amount of the time they were waiting for. Knowing they had done everything they could to speed up the baggage handling process, the only solution was to try and replace the pain of waiting with something less painful.

The answer turned out to be blissfully simple, Houston moved the arrival gates from their close proximity, to roughly an 8 minute walk from the baggage carousels. So when passengers would arrive to collect their bags they would typically be waiting seconds, or sometimes not at all.

By deliberately inconveniencing their passengers with a walk, Houston had effectively swapped out the pain of waiting, with the much more pleasurable alternative of walking through the terminal. I’m sure some people would have still complained about the walk but complaints regarding baggage waiting times disappeared overnight.

This process of disguising an unavoidable pain point with something more pleasurable is the crux of the art of loading. If you reach a point where your users aren’t even aware of the loading time at all, only then you can truly consider yourself a master of the art.

As with most UX practises, there’s no perfect solution that will fix all of your problems as It’s an ever changing and adapting field that is constantly improving. So much so that I’m sure in just a couple of years time this post will seem woefully out of date.

“We are all users, we are all the target market we are aiming to help.”

The good news is that we are all users, we are all the target market we are aiming to help. Hopefully, if you’ve read this far you will already have a few ideas in your mind of previous experiences that have annoyed you. If so, hold onto those thoughts as we run through the below examples.

Please note that these examples are simplified and represent broad categories of loading styles, rather than specific examples.

First of all, the worst possible thing you can do is present the user with a blank or static screen. The gears may be whirring in the background, but if the front end doesn’t display anything indicating that to the user they may assume the app has crashed or attempt to resubmit their request, often exacerbating the issue further.

Even the addition of a little bit of descriptive text can go a long way to help reassure users that everything is ok and they need not worry. Better still, animating the ellipsis in this example would provide the crucial visual indicator users need.

On paper the classic spinner, or any variation of it, does the job just fine. It lets the user know something is loading with a little animation so they can rest assured that some sort of loading is taking place in the background.

Where these fall down are their inability to inform the user how long loading will take. If you have a slow loading app or website, or the user is on a particularly slow internet connection (we can often be guilty as designers and developers of forgetting the rest of the world isn’t running on fiber), an infinitely spinning wheel won’t offer the slightest bit of reassurance to them.

The same can be said for the much more attractive, but equally unhelpful animated loading indicators, although much more visually pleasing, a looped animation of a cat chasing its tail will only delight users for so long, or so many instances before it too becomes a source of irritation.

One of the most simple and effective ways of providing users with sufficient information and reassurance is the loading progress bar.

While this doesn’t exactly excite, delight or disguise the loading pain being experienced, it does at least provide the user with the minimum amount of information required to let them work out how long loading is going to take while being reassured that it’s still working. Again, by adding an additional animation it adds reassurance that loading hasn’t stopped, even if the progress bar isn’t moving.

What is important to remember is how unreliable progress bars can be at displaying estimated load time accurately. With so many different hardware variations it’s still common for a bar to pause or shoot ahead. If you are going to use a progress bar, do as much as you possibly can to make sure it runs at a constant speed.

When it comes to loading bar pauses, if you can’t simply make it go faster, it’s genuinely worth considering slowing down the loading speed of your app if it helps it load more smoothly. Just like with Houston airport, it’s more annoying to a user to be stood there waiting for something to happen than it is to see slow but constant progress.

Skeleton pages are all the rage at the moment and for good reason, they allow the user to see a glimpse of the content to come and where it will sit on the screen which excites and prepares them for what follows. It also provides a lot of visual stimulus, temporarily overloading the user with things to look at, buying your app a valuable second or two to load in the background.

Better yet, combine the skeleton pages with additional indicators and staggered loading of content so users can not only see how long is left to load but also start to engage with content while the rest is loading.

My two favorite real world examples are YouTube and Origin. Both have slightly different approaches but the end result is the same.

Origin is a very image heavy application and takes quite a long time to load. As a result, you are presented with a perfect wireframe of the store page for the first few seconds. To add reassurance that loading is taking place, a slight ripple animation moves through the cards on screen.

YouTube are the current masters of loading. Depending on where you are and what you’re doing on the site, you will see one, or a combination of skeleton screens, progress bars and buffering wheels, but one thing they do particularly well is to load the most important content to the user first.

When you click to view a video, you will see a skeleton screen but instead of waiting for everything to load like Origin, YouTube drip feeds content as soon as it becomes available. Where this gets really clever though is that the video, the most important part of the page to the user, will always be the first thing to load despite being the largest image on the page. No one clicks on a video to look at the “up next” thumbnails so there’s no point loading them first.

Einstein’s explanation of relativity in layman’s terms was “When you sit with a pretty girl for an hour, it seems like a minute. When you sit on a hot stove for a minute, it feels like an hour.” Oddly, this perfectly summarises the challenges faced by UX Designers as we strive to develop the perfect solution for this problem.

Time isn’t linear, at least not in our minds, and our perception of it changes depending on our situation and what we are experiencing at the time. Was it fair that people were complaining about a baggage waiting time of 8 minutes? Probably not in the grand scheme of things but after you’ve just got off a long flight, those 8 minutes would have felt like an eternity.

Always put yourself in your users shoes when considering app and website performance, there’s a reason we create user personas, so don’t fall into the trap of thinking you know best or picking form over function. Your first call should always be to make it load faster, but different products and services will have their own degree of accepted load time based on the services they provide. For example, It wouldn’t matter to a user how pretty an emergency services app is if it takes 20 seconds to load.

Always strive for perfection when handling loading, but don’t let perfect be the enemy of great if the alternative is sub par or nothing at all. As designers, work with your developers to create something functional as well as beautiful and champion what’s best for the user, rather than dribble.