I think (I don't want to influence you) that feedback is vital. Both for the user as for the design team.

I'm trying to convince a team that they should put feedback at the core of every user related feature. At this moment, even an email will not trigger an auto-response. But there are other areas where feedback is missing or slow.

Am I mistaken when saying feedback should be 1-On time, 2-On target, 3-Proportional, or am I missing some key point?

How would you go about to argue in favor of timely feedback?

Edit JoJo is talking about user feedback. I'd like to know about feedback to users.

4 Answers 4


To answer your question concerning system feedback to users, I think you have it pretty well covered. Feedback is an essential property of a usable product and necessary to avoid confused or frustrated users; it's critical for the user to naturally “flow” through the UI.

If you need to convince others of the importance of feedback you can point out that style guides like that for OSX list feedback as a basic design principle. Human factors standards, like MIL-STD 1472, require feedback and specify when and what types should be used. Wired has recently run an article on the importance of feedback for human performance in general, and how to have effective feedback.

To build on your list of how to provide feedback, you can add a list of what needs feedback. It should include:

  • What input the user made (e.g., the user selected a specific button).
  • What response the system made (e.g., the system is submitting the data in user’s form).
  • When the response is completed and the system is ready for the next input (e.g., the data has been submitted). For slow response times, also indicate progress towards completion.
  • Whether the input was ultimately successful or not, and, if not, why and what the user can do about it.
  • System state modes or changes that may affect future user input or interpretation (e.g., dropped connection).

Each of these should be on time, on target, and proportional in its own way.

MIL-STD 1472 provides definitions of what constitutes adequately “on time” for various kinds of inputs (see 5.14.9).

“On-target” feedback has two meanings. It means spatially associated with whatever input the user made, and it means wherever the user is attending. Usually these are the same thing, since users tend to attend to wherever they made their last input. However, when response times are slow, the user may have shifted attention elsewhere. In this case you may need two feedback signals, each with its own level of proportionality. One signal is at the point of attention and gives basic feedback that directs the user back to the input, and the other is at the point of input providing more detailed information if needed.

Proportionality is very important; for example, you generally do not want something obtrusive like a message box to tell the user everything worked fine. However the absence or loss of a signal or visual indication is generally not acceptable feedback.


On my website, I have a link to a feedback form on every page. I get around 50 pieces of feedback per day. The following is based on personal experience.

Good for functional bugs

Feedback is useful for quickly finding out about functional bugs. Users are very vocal whenever they see a functional bug. It's very hard to test across all browsers with the cross product of all the operating systems. It's also very hard to figure out what users will do to break your website. Once your revision is out in the wild, it will be tested across all the browser and operating systems, and more likely than not, some particular action on one variant will break the webpage. This is when users write feedback. They love pointing out things that are broken. On the other hand, they'll less likely give praise on things that are working well. Users want something from you. They don't want to help you.

Not for design issues

Users do not complain about design issues. Over the thousands of feedback I've gotten, there were maybe only 1 or 2 messages about design. One said the site looked great. Another said the site looked too bright. I knew some parts of my website looked bad, particularly transparent PNGs in IE6, yet not a single IE6 user complained. I guess the explanation is that most people don't care about design. They only care about how functional and useful a site is.

70% useless

Nearly 70% of the feedback you will receive will be illegible. It's surprising how many low-literacy people are using the web. They don't punctuate, nor spell right, nor clearly explain what they want. So you'll have to throw away most of your feedback.

Not for usability

I haven't found that feedback was of any particular use to improving the usability of a site. Users rarely comment about usability issues, except if there's an obvious feature that's missing, like search. Most people don't have the knowledge on how to fix the usability of a site. For example, they won't be able to tell you to use more white space so they can segregate pieces of content more easily. Usability is really a subconscious thing users deal with and most won't be able to articulate problems. In conclusion, I don't use feedback to fix usability. I leave that up to A/B testing.

  • Good answer. A feedback form is useful of course, but will only get you so far. So in addition to that I'd also conduct proper usability testing. That will reveal deeper insights into problems you never knew you had. Steve Krug has a good example video of a short usability testing session here... sensible.com Jul 31, 2011 at 4:17

JoJo has covered fedback from users, and I would tend to agree. Feedback should be provided for functional bugs, and that is pretty much it.

Feedback to users is critical, but it is a very difficult and complex area. If I send an email, I don't necessarily want a response that tells me that hte email has been recieved. I want a response within a few hours from a person. Even if it then requires more exchange, this is the type of feedback that works. That is making feedback "on time".

Providing feedback to users that what they have just done has been processed acceptably, is vital. However, this also needs to be "propotional" - that is, I want to be able to know that what I have done has worked but more critical is I want to clearly know if it fails.

So yes I agree with you, but it is very difficult and very variable. I would like to be able to set my requirements, and have them replicated across every site. Tell me exactly what I need to know, when I need to know it, and nothing else.

  • I was thinking of an auto-reply saying how many days would pass approximately before a person would respond, unless of course a person would respond in a few hours. But when you have to wait a few days for feedback, that's too much time.
    – GUI Junkie
    Jul 31, 2011 at 13:20
  • I think the point is that the user shouldn't have to wait more than a few hours. Feedback is not just about technical solutions, but about peoples involvement as well. It is always dangerous to assume that there is a technical solution. Jul 31, 2011 at 13:39

To answer the question: Very.

The role of feedback applies right across human behaviour:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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