Interface Anxiety

A sense of chronic unease or acute worry experienced while interacting with a software system.

This post exists because I’ve recently realized that a good 70% of my application development work is based around minimizing this feeling. If I have to use something I’ve made, I can’t live with it being subtly painful.

While a good test of a system’s value proposition is how much anxiety people will deal with to continue using the service, I would much prefer to never be the subject of such a test.

It’s possible that my sensitivity is a unique personal symptom of screen-induced ADHD. But it feels more true that I am just defining and describing a feeling that most people share. In any case, I believe that noticing and focusing on this emotion does contribute to better design.

The definition itself, being quite simple (tautological, even), doesn’t convey anything useful. That’s what the rest of this page is for; an attempt to describe it’s facets through example:

Notifications

The little red dot has the most ridiculous size-to-effect ratio of any element we’ve ever come up with. This should have led to careful usage, instead it has meant alerts everywhere, for everything.

The dots don’t even mean anything specific! Users have primitive levels of control over what becomes a notification, they’re freely abused for marketing nonsense (or worse), unread badges don’t ensure you’ve actually dealt with the message, etc. Every dot looks the same, and could mean a dozen different things.

Within apps, the least we could have done is a single inbox for better triage, but most apps just show multiple dots all over their interface instead.

Heaviness

It comes in two forms:

1. Latency: Loading spinners, a perceptible gap between a click and the resulting action, a frozen interface – all of these are an unsettling game of “guess what happens next?” If a page scrolls slower than your mouse wheel does, it feels like being stuck in molasses.

One underrated aspect of network-based latency is that the delay could be anywhere between imperceptible and…forever. Each click is a painful roulette game.

It is harder to trust the system as a whole when parts of it will randomly let you down. The trust that follows from consistent speed is why the best software is fast, and vice versa.

2. Visual noise: To the degree that software is about information design, it ought to guide the eye, and thus make it easy to skim each screen. Dividers, colors, icons, and density are all tools to make this easier, but are easily overused to achieve the opposite effect. And a poor data ink-ratio is almost as bad as…

Hidden information

Visual heaviness cannot be solved by naive minimalism. Look at this coffee machine panel (source, worth reading) for example: it is minimal but it hides information from you.

An absence of information asks you to fill in the gaps, to memorize things.

In many apps, it makes for a series of nervous back-and-forth jumps between multiple screens. This is what makes hyperlinks dangerous, because they are a tool for indirection.

Non-standard behaviour

Interfaces deserve to be innovated on. But only when existing patterns fall short, and only while respecting the standards of the operating system/browser.

Don’t break URL navigation, tabbing through items, common shortcut => action mappings, CMD + F, etc. just because you can. Your novel patterns will not do that much better than the most tried and true defaults. (Unfortunately, so many applications break those rules that even relying on the defaults starts to feel anxious)

Even when adding them, a naive way would be to use them for infrequent or otherwise unpopular sections of the interface. But this is doubly bad. When users finally decide to do an action they don’t normally do, they will be confronted by a more-alien-than-usual interface. They have had no time to practice, and just want to get it over with.

Instead, use novel patterns for more common actions, for two reasons:

1. A core action is used often, giving it the chance to graduate to the comfortable familiarity of muscle memory.
2. It forces you and your users to use the action often enough to receive feedback about it’s effectiveness. Too many bad ideas are left alive through hiding.

Powerlessness

For the longest time, algorithms have taken (deserved) flak for this, but it doesn’t stop at there. Most systems have things that they will just do, whether you approve or not.

• Crash, and lose your work
• Stop working in the absence of perfect internet connectivity
• Auto-magically “fix” problems through a misguided concierge attitude
• Silently restart in the background, losing your context

When it happens, it might look like a specific moment of frustration. But from the first time onwards it sets in motion a permanent background discomfort. Users will spend as little time as they can in this environment of anxiety, but be unable to point out why. They will use your software defensively — writing drafts outside the app and only pasting in when ready, spam-clicking “Save” before leaving a page.

I pay Bear $15/year to give me Markdown notes with sane conflict resolution (choose between the two conflicting version) instead of Apple Notes’ terrible approach (brutally overwrite). Once bitten, willing to pay to never be bitten again.

Change

Memorization, once achieved, is a form of lightness. It frees you from looking. It enables fluency, which is the opposite of anxious usage.

So when things are rearranged, lost, or otherwise modified, the pain is felt most by the power users. They are deprived of their shortcuts, their buttons are moved out of familiar tap territory. Back to square one, this time with their trust burned. Once bitten, forever shy.

Furthermore, software veterans can smell the desperation in every rebrand. They can sense the upcoming product pivot that finally casts their specific needs aside.