Sign up ×

Anyone know of any research or guidelines on if/when relying on the absence of negative feedback is more appropriate than providing explicit positive feedback?

Background: I'm working on an information-dense UI with numerous tables and suchlike, which is fine for the audience we're designing for. At the moment, the only kind of status message you're likely to see on the page is when something has generated a warning or an error. If no warnings or errors are visible, then everything is "fine".

We were having a conversation today about whether that's good enough, or whether it would be more reassuring if you were explicitly shown that there were no warnings or errors. All else being equal, I'd imagine it probably would. But in an information-rich display where every pixel is a prime piece of real estate, and everything should be "fine" most of the time, finding the space to show that there are no warnings or errors would inevitably mean having to slightly reduce the amount of other information we could display.

Of course our users will be the ultimate arbiters of which piece of information is more important to them, but we do strive to make the best design decisions we can up to the point at which we show them any prototypes :)

EDIT: In response to one of the answers below, it's worth noting that the UI isn't really continuously monitoring for any errors/warnings, but rather infrequently polling. In fact, it's quite likely you'd only log on to the system once or twice a week to check for any errors/warnings, rather than keeping an eye on it all the time.

share|improve this question
Devil's advocate: If you have to tell me that everything's fine, does it suggest that it regularly isn't? –  Kai Jun 21 '13 at 14:58
Yes, that's come up in our discussions a couple of times :) One counter to that is that it's just easier to look in one place than to quickly scan a few tables to confirm that everything is fine. But @Matt's notification box answer pretty much addresses that, although we probably can't do something exactly like that unfortunately. –  scottishwildcat Jun 24 '13 at 12:30
I would suggest - though I have no hard evidence to back up my claims, just a pattern I've personally observed - that "everything's ok" green-light notifications should only be used when the user can take an active role in the systems' state. That is, think of your users' response to "system error occurred!" - If your users are capable of (and responsible for) repairing the error - admins, techs etc - then display a green-light notification when everything is OK. If your users have no control over the state ("oh well, I guess I'll have to come back later"), then don't green-light them. –  Kai Jun 24 '13 at 13:11
Yes, that could be a useful way to look at it, thanks. –  scottishwildcat Jun 24 '13 at 16:52
Scott, does one of the answers below solve your question satisfactorily? It'd be cool if you flagged an answer if one did. –  Matt Aug 19 '13 at 14:56

3 Answers 3

up vote 2 down vote accepted

Another method of providing the "all clear" is the "notification box" prototype. It's a well-recognized and comforrtable method to deliver messages to users (See the StackExchange top bar, Google top bar, Facebook, etc.)

  • Use a small amount of space for an icon and a little extra for a flagged condition to indicate when there's new content.
  • On hover or click, user gets the list of:
    • Errors and notifications
    • When they happened
    • Whether the user has seen it or not yet
  • Let the user clear the messages individually or en mass.

This also gives you the flexibility to send non-error messages to the user through the same common communication channel, further increasing the information density and utility of the tool.

Feedback happens in response to stimulus. Whether you have a "green light" that changes when there's an issue, or simply have a space where they're told if something changes, what matters is that the only time feedback will exist is when a change happens. Make sure that when feedback does occur, it is noticable and discoverable.

Edit: Given your update, I'd suggest looking to how your system can support notification workflows -- send the user an email, text message, IM (if all/many of the users will be on an accessible chat platform like Lync or Jabber). If they're only going to log on a few times a week to see if something's wrong, they're going to be ineffective at taking timely action.

Better, then, for the system to do what software is best for, which is automating the stimulus associated to the state change. When a notifiable event occurs, contact them and tell them so that they can go check it out.

Email gives you all the space you need to describe the condition and is really easy to set up in most web languages/platforms. Plus, you can do that independently of having to argue in a boardroom on visual UI changes for in-app notifications (which can then be pop-ups, div modals, etc. that don't move existing elements around).

share|improve this answer
Yes, something a bit like a notification box is actually part of our proposed design too… although unfortunately on this occasion we're largely having to fit in to a long-established corporate framework that makes doing something exactly like that a bit of a challenge. Still, I like a challenge :) –  scottishwildcat Jun 24 '13 at 12:15
Challenges always make the work better :). –  Matt Jun 25 '13 at 15:38

If there is a continuous process which is going on in the background or which you are monitoring then it makes sense to have a continuous positive feedback (the green light!).

Feedback of any kind is in response to a trigger. It can be user initiated or system initiated. If the trigger is continuous, I would suggest a continuous feedback too.

The manifestation of the feedback can be different in different situations:

  • Laptops: Apple removed any indicator that the laptop is on (in the retina macpros). While it is a good argument that when a laptop is running the user can see the screen, it was a piece of affordance which was always handy eg: when your screen was turned off.

  • Monitors/TVs: These devices always use a visual cue to declare their state, on/standby/off (where off is the absence of any signal)

While an always on feedback can be replaced by a conditional (error) feedback, you would want to weigh in all the scenarios and usages before jumping to that decision.

share|improve this answer
Good advice. In this case it's not really a continuous process we're monitoring, though, it's more of an 'occasionally polling for updates' scenario. I'll update the question to reflect that. –  scottishwildcat Jun 24 '13 at 12:17

The de facto standard I've always used is that if nothing is wrong the user will typically continue on doing what they are doing. However, when you have the appropriate warnings and errors in place and the user slips up and receives a warning or error, it is appropriate at that point to notify the user when their input is correct.

i.e. If no errors or warnings, no need to say "You are right". If user causes error/warning, let user know when their input is acceptable.

share|improve this answer

Your Answer


