Or at least, the perception of time
Waiting sucks.
After just 0.1 second [1] users start to perceive a delay if your app isn’t doing The Thing™ that they just told it to do.
So, when our developers did some analysis that the average time for A Thing™ to happen was going to be 4.0 seconds on average and up to 8.5 seconds in the 95th percentile…
😱 No way. Not going to happen.
Count 8.5 seconds in your head…. mississippily.
It’s…
a…
long…
time.
We can’t make them sit there and wait for 8.5 seconds in a core flow.
What can we do?
Understanding Design Constraints
The team had a discussion to figure out what we could and couldn’t do.
Can we speed it up?
No. It’s a complicated multi-step process. All steps are necessary and as fast as they can get.
Can we move The Thing earlier in the flow?
Not really. It doesn’t logically make sense and in many cases it doesn’t buy us the full time we need. Plus there were extra complications with this.
Can we tell them about The Thing later?
Not really. It’s at the end of a core flow and really important information for them to see. If they don’t see it there, they may never see it and that’s a problem.
Can we manipulate time?
No.
Wait…
Maybe?
Manipulating (perceived) time
We knew that tips from SEEK-Alumn Aoife Johnstonfor making your site feel faster weren’t quite right for the length of our delay (staggered loading, dummy content and asynchronous & optimistic actions). Read her tips here:
A skeleton loading with dummy content for 8.5 seconds is just too long and optimistic actions impossible in our scenario.
Fellow SEEK UXer, and the always wonderful, Daniel Jimenez and I had a sketch up to explore viable design options.
We discussed two prominent examples of warping time with design.
Houston Airport — baggage claim
Houston Airport were receiving complaints that it took too long for luggage to come out on the baggage carousel. The average walk from the arrival gate to baggage claim was one minute, leaving passengers standing around for about seven minutes waiting for bags.
Way too long.
They couldn’t speed up this process, but they could make the walk from the gate to the carousel longer. The perceived wait time was now almost eliminated and complaints dropped [2].
I curse these designers every time I have a long walk from the gate because I know what they’re doing!
Mirrors by the lift
The wait time for elevators in very large skyscrapers can be exorbitant. Tenants complain that lifts are too slow. Speeding up the lifts isn’t necessarily an option (although some larger skyscrapers do now have elevators that skip some floors to help this).
In one, infamous example, building management concluded that people were complaining because they were bored while waiting. Their solution? Install mirrors by the lifts. Give the tenants something to distract them while they wait. People were distracted checking their hair or outfits and stopped complaining about the wait time [3].
Eight Design Principles for Waiting Lines
Both of these examples take ‘un-occupied time’ and turn it into ‘occupied time’ so people don’t realise they are waiting. They also follow Don Norman principles for waiting lines [4]. The principles are:
- Emotions dominate
- Eliminate confusion: Provide a conceptual model, feedback and explanation
- The wait must be appropriate
- Set expectations, then meet or exceed them
- Keep people occupied: filled time passes more quickly than unfilled time
- Be fair
- End strong, start strong
- Memory of an event is more important than the experience
Number 8 really struck home from a recent wait experience I had. My EasyJet flight was delayed and they were pretty transparent that we were going to be stuck waiting on the plane. They let us use our devices, but if you have no wifi you’re stuck there bored. So they let us go and play in the cockpit! I don’t remember the wait, but I do remember getting to play in the cockpit and get a photo sitting in the pilot’s seat playing with the controls.
These principles apply to waiting in the digital world too.
We came to the conclusion that we had to come up with an option that added something meaningful and gave the user something valuable while they wait.
A cute loading indicator may be delightful the first time but soon gets tiresome for heavy users.
Hipmunk searching Chipmunk (I’ll never get sick of you)
Having a hot tip, or a piece of information, needs to cycle through regularly enough so that users don’t get bored. There’s an Australian Network TV app that gives the same tired piece of trivia every time a video is loading. If you’re binge watching a show, which to be honest we probably are, seeing something you’ve already seen, again, makes it feel like a long wait in between episodes. Especially when Netflix loads so much faster.
Not only does copy need to be fresh, but it needs to be short enough that it can be read it before it goes away, otherwise that’s just frustrating. But, not too short that I read it and then still have to sit and wait. Slack does this well.
Slack loading tip
I’ll admit, I still didn’t think we could do it. But we tried anyway.
There were two different approaches we could take:
- Having an interim screen with some meaningful information.
- Building the wait into the current page.
Option 2 meant that we were following Norman’s Waiting Principles, namely — “Provide a conceptual model, feedback and explanation” and “Keep people occupied: filled time passes more quickly than unfilled time”. It also meant we didn’t have to worry about moving past the interim screen too quickly for users to understand or read what was going on.
I built a conceptual prototype to show what this could look like and explore whether it would actually work. The first rough concept was done in PowerPoint as it was the quickest way to get everything moving using animations, timings and automatic slide advancing.
I sat back and watched the whole prototype. We’d done it.
Now we had to get buy-in.
Show don’t tell
Our very rough prototype — Text cropped on purpose
We first showed the prototype in our design critique session with fellow UXers and made some improvements based on their feedback.
Next, I showed the project team. They watched the animation, and liked it but one asked…
“That’s great. But how will it work for the 8.5 seconds?”
I looked at them and say…
“That was 13 seconds”
We’d done it!
The executive leadership team were also sceptical, until we showed the prototype.
We firmed up the prototype in Axure — holding it together with animated gifs and complicated Case statements to put it in front of users.
Testing the Concept of Time
We put the prototype in front of real users, set them a task to do and let them at it.
Participants did not seem to have an issue with the 8.5 seconds animation. Rather, it was positively received as they felt it was more transparent about the steps SEEK was taking, particularly when compared to the current design. None commented on the time without prompting. When they were prompted we got answers including:
“In an instant”
“Instantly”
“A couple of seconds”
“5 seconds”
Given what we know from Nielson’s guidelines, and own observations from research, we’ve decided to implement this solution. We are confident that we’ve created occupied time in a useful manner and reduced the perceived wait.
TL;DR — How do I warp time?
Even if you don’t think you can, just give it a shot with a (very) rough prototype in PowerPoint using animations. You may surprise yourself.
Provide meaningful information within context, that doesn’t disappear. The copy should also explains the wait and useful transparency of system status.
- Use animations to communicate that things are happening, but don’t rely solely on ‘delightful’ animations.
- Get buy-in from other sceptics with a rough prototype to show how you are manipulating time with the above tips.
Good luck!
[1]
Miller 1968; Card et al. 1991; NNG Group 1993 & NNG 2010 https://www.nngroup.com/articles/website-response-times/
A huge thanks to Daniel Jimenezfor co-designing the solution with me and Rob Veitchfor reminding us of the lifts by the elevator example and supporting us to try.