I'm looking to build a set of usability heuristics to use for projects at my current company, and I think it would be useful if we could include a check for elements that suggest to users an application or page is broken.

There are some obvious candidates - like long operations that don't provide feedback, and unstyled elements, but otherwise, what kinds of visual cues trigger a sense of 'brokenness' in most web users? Have you ever seen any 'legitimate' design choices interpreted as 'broken' in a user test or feedback?

  • 1
    Well, the classic is the blank white screen – Ben Brocka Nov 13 '12 at 3:10

Here's two situations that could be deliberate decisions that seems as though they're broken:

Inconsistent Layout
This stands out whenever there are animations or transitions from one screen to another that usually are in a certain position, but every once in a while switch to a different layout for no apparent reason. This could be as simple as elements that are offset, or even elements that are clipped at the edge of the screen. The designer may even want the elements slightly clipped off the screen to de-emphasize them, but if this shows up only occasionally, there is a risk that it will seem broken. Overlapping elements are especially in danger of being misinterpreted.

Seemingly-Impossible Modes [with no clear entrance or exit]
Spotify comes to mind here, as I often notice it "freezing" on occasion between songs on my mobile phone. Noticeable things that make me think its broken are the lack of slider on the track-progress bar. What mode am I in? The screen shows a pause button, so clearly it thinks that it is playing, yet no music is audible and it shows no track-progress. How do I get my music? In reality, this might be a design decision to show buffering, but it doesn't communicate to the user to wait a while. Worse yet, if the connection is quite bad, the buffering state of limbo might last a minute or two, with the user not realizing what is happening behind the scenes.


Once nice one is "things happening too quickly".

I've seen people assume that file copies have failed, or searches haven't worked properly, because they were essentially 'instant' with no visible progress bar, etc.

Another is users preconceptions of how things should work. For example we now have some workflows where you don't "save" files or "quit" applications (e.g. most iPhone apps). Others where you need to do both explicitly (e.g. most Windows apps).

When people used to one system hit the other confusion can ensue ("I can't save it's broken" vs "I switched the computer off. Where did my document go? It's broken").

  • +1 Things happening too quickly is a really good one, and definitely a great example of a case where it was designed to work that quickly but can be perceived as broken even though nothing is really wrong. Many times, if pages seem to stop loading abruptly, I assume that something did not load correctly. – sacohe Nov 13 '12 at 14:18

This is not complete but just to start a list:

  • long-running operations without feeback (from OP)
  • unstyled elements (from OP)
  • white screen (from Ben in comment)
  • disabled sections (especially if the majority of the page is disabled), as it looks like the page didn't finish loading
  • 404 Page Not Found error
  • elements that are noticibly out of place (for example, overlapping divs that should clearly be next to or following each other), even if this is caused by browser compatibility issues
  • frozen progress bar
  • poorly worded alerts/pop-ups can be misinterpreted as error messages
  • elements that don't appear as expected, such as:
    • empty drop down
    • cut-off text
    • links or menu options that don't do anything when clicked
  • missing/unloaded/broken images

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.