UX Quick Tip: Applications Should Work Like Elevators


Users experience your website or mobile app through elements that they can interact with. Try thinking of YouTube without a Play button or one that’s implemented so badly you can’t figure out what it does.

Quick Tips is a series of short articles featuring knowledge that gets passed on around the office daily from seniors to juniors (and sometimes vice versa). This time we’ll cover a UX problem that easily creeps into projects if designers and developers don’t pay attention to details.

The problem


Imagine walking up to an elevator and pressing the button to call it. The button doesn’t light up, there’s no display to let you know on which floor the elevator is and you can’t hear it moving. You’ll probably wait, but after a while you’ll get tired of waiting and take the stairs. Of course, that’s when the elevator shows up, but you don’t know that. And you don’t care.

It’s the same with web or mobile user interfaces that hide their function or don’t let you know if anything’s happening once you’ve interacted with them. This can lead to user frustration and, let’s face it, closing your application or website is much easier than taking several flights of stairs.

Lesson 1

Let the user know if something’s interactive

If a part of your UI should be interacted with, let the user know. I’m talking about UI elements that inherit from the OS (like a scroll bar or plain button). I’m talking about any element that allows for interaction.

Links should always be styled differently from the text surrounding them. Define a hover state and use the pointer mouse cursor.

Wrong way:

Making a link look like a button is fine too, as long as it’s clear that it is a button and it has a hover and active state.

Right way:

The same rules apply to any element that’s interactive. Make it obvious that your users can use an UI element such as a link, scroll bar, button or even a surface, and they’ll gladly do so.

Lesson 2

Let the user know they’ve done something

Looking at the elevator example, it’s clear that any delay that doesn’t let the user know that everything’s still underway leads to confusion and frustration. UI elements that change state after interaction or start a background process should let the user know that something is going on.

Take a look at the following example – it’s a simple form that lets users edit the price of a product and choose if they want to save the price or not. The price is saved via an AJAX request that takes around 2 seconds to complete.

By playing around with the example you can see that:

  • the Edit button is prominently displayed and lets users move forward with the task of changing the price,
  • cancelling changes is a no-brainer,
  • saving changes displays a loader,
  • if the changes are successfully saved, the border of the input field turns green and a message is displayed,
  • clicking on the input field or Edit button resets the state of the form.

In case of an error, the input is colored red, a message is displayed and the the user is allowed to edit the field again.

The takeaway

Never let your users wander around your UI and wonder whether they’ve actually accomplished anything with the action they performed. 

Also, plan for the worst case scenario (a slow mobile connection or an error in your application) and make your users feel in control.

Failing to do so will make them feel uneasy about their actions and shy away from using the functions of your web site or web application. No matter what happens, the user always has to feel in control.

These tips might seem obvious, but it’s astonishingly easy to forget about them.