Halvor William Sanden

How pointer coursor affects our usability decisions

Most interfaces, design systems and UI frameworks seem to be made by someone who has only heard stories of interfaces.

It’s what we get when imitating each other. It’s what we get when bad practices become expectations. It’s what we get when making decisions without reasoning.

We know what interfaces look like and how to get them working, but we don’t know why they should be in certain ways. The source material remains obscured in favour of doing what feels right for the thing in front of us, usually because someone bigger has already done the same.

A pointer cursor might feel right on a button because we reduce the interface into being about clicks and usher users towards them. After all, that is what we measure. To us, clicking equals functionality, and we think the users see it the same way. They don’t.

From clickbait to comprehension #

Users expect functionality in the entire interface.

To get users to click what we want them to click, we have come up with an attention-seeking, arbitrarily coloured rectangle with a cursed cursor. From links, we have taken the pointer we feel is a clickability indicator and combined it with the shape of the button that we feel it’s about visibility. And splashed our favourite colours on top.

We don’t help users by making elements look like whatever we want, forgetting about conventions and states like hover and focus, and slapping a pointer on top to indicate clickability.

Clickability isn’t anything unique. As good as every pixel of an interface is clickable in some way. Alt-click or press and hold is also interactivity, and so is text-highlighting. Users know this. More than looking for the thing to click, they want to make sense of the interface, so they can do what they came to do.

The meaning of an interface is rooted in conventions. Like words, the elements rarely have one immutable meaning; context and delivery matter. We communicate better when we know both the standalone and combined meanings. If we do that successfully, the interface will guide users instead of rushing them towards some call to action they aren’t ready for yet.

Learning about cursors, especially the pointer, is a starting point to getting rid of this click fetish.

Two rules about cursor use #

  1. We rarely have to specify a cursor. It’s primarily relevant if we are attempting to pass one type of element off as something else or if we are building non-native functionality.
  2. The pointer cursor is for links.

Functionalities’ cursors #

Button and label have the default arrow. Summary too, but with the text I-beam on its content. Input has cursors based on the type, like the default arrow for radio and I-beam for various text types. I-beam is on most text elements. Resizing has a small bidirectional arrow. Scrolling in all directions has a circle with arrows in four directions. All of these are clickable, but we don’t feel the need to make them the same.

Cursors indicate functionality, but some are specific to certain elements. That’s why we can say that the pointer indicates a link, but we cannot say the default arrow indicates a button.

Why pointer is for links #

The pointer cursor is not a hand that clicks or presses; it is a hand with a pointing finger. Together with the link itself, it indicates an entire set of pointing functionalities, including things like direct navigation, opening in a new tab, bookmarking, copying and sharing. If we use the pointer on a button, we indicate it has the same options.

Few people will try to open a close button in a new window or bookmark a submit, but many become disappointed and confused when a button with navigational functionality doesn’t behave like the link we are telling them it is.

In the few instances where it makes sense to style a link and a button the same way, the cursor can be the one thing that helps the user to discern one from the other.

It’s a small detail, and for touch screen users, it doesn’t matter. But it’s a sign that we take defining element properties too lightly, gradually affecting more significant aspects of the interface.

Element facets #

Knowing an interface element means knowing its facets: tag, attributes, usage, behaviour and defining visual properties. The more we work with them simultaneously, the better the interfaces get because we communicate using properties that set elements apart from each other.

Like letters of different shapes and heights, interface elements of different visual and behavioural properties are easier to recognise and navigate. Differentiated elements help users to read the complete interface.

Knowing the conventions of the interface elements means we can make decisions with verifiable arguments about how users comprehend the interface. We can also build from the native element’s conventions when we make custom elements.

The critical question, though, is still not what the knowledge is but who’s responsible for having and using it.