Show Your Work: Don’t forget ‘loading’ indicators

UX tips from James Bond villains
Who knew a day would arrive in which I miss looking at loading spinners?

Unfortunately, I routinely stumble across awkward interactions in apps these days because they lack such indicators.
I understand why this is a common UX mistake. It’s tempting for developers to to run processes in response to user input without indicating ‘working’, success, and error states, because on our fast devices and connections, requests seem to process instantly. The problem is easy to overlook until users click or type things without realizing they have to wait, which messes up the whole interaction.
When testing our own products, we know what to expect and are trying out idealized scenarios. Other users don’t necessarily share the same knowledge or circumstances, so they have a different experience.
The Internet is slower than you think
This is especially relevant given the rise of Single-Page Apps. In web apps without JavaScript the browser has inbuilt feedback: if you click a link or submit a form, there is plenty of indication that something’s happening until the page reloads. In asynchronous JavaScript requests, there is usually no UI feedback unless developers take time to provide it.
I’ve had to fix UX problems in multiple projects with interactions like paging or autocomplete because we underestimated how slow internet connections are in the real world. Regardless of how fast broadband gets, you can be sure there will be a moment when your app’s user clicks something and has to wait for a couple seconds. Don’t leave them hanging without an explanation.
Learning from Bond villains
For their (many!) faults, we must concede that Bond villains provide clear situational indicators. They set up elaborate designs, and announce how their traps will work. They show us the sharks and the lasers. Bond knows exactly what to expect.

Let us learn from Goldfinger and make our products work with unmistakable clarity.
Further Reading:
How to fix a bad user interface:
“every screen you’ll design for your product can have up to five states: Ideal State, Empty State, Error State, Partial State, Loading State.”
Thoughts or feedback? Let me know in the comments.