I often have to deal with customers or users which are reporting errors in applications. Most of the time their content is something useless as

  • ERROR!!!
  • x does not work

without much more information.

For resolving the issue I have to request every single detail of them, which often is more time consuming than fixing the issue itself. Other send information in formats which are not ideal, like screenshots (of data records, not of errors) although they could send a link (we have access to the systems) and so on.

How do you tell your users/customers to describe the problems with more details so that the whole process could be easier for both sides?


This question is more about the social skills, than how to achieve programmatic collection of logs and error information. I'm aware of the fact that this should be part of good software design.

  • 24
    You don't, you design your software to send error logs/messages to you. May 4 '11 at 13:54
  • 8
    This unfortunately is not always possible particularly if you're supporting software which you did not develop, but which you bought in.
    – temptar
    May 4 '11 at 14:15
  • 1
    @Mahmoud: That's good advice, but it's really only relevant if you're at the design stage of a new app, or if you have the luxury (time and budget) of building such a feature into an existing appliation. May 4 '11 at 14:20
  • 1
    "easier for both sides"? Both sides? They're already doing what's easiest for them.
    – S.Lott
    May 4 '11 at 14:28
  • 1
    You can't control the application, but you think you can control the users? You're in the wrong field.
    – JeffO
    May 4 '11 at 21:06

11 Answers 11


Reward your users for good bug reports, punish them for bad ones (well at least a little).

The user needs to understand that a good bug report is essential for you to fix the problem quickly and therefore is good for him as well, because he'll get the solution a lot faster.

So the first response could be something like "Okay, I have read your report but I don't know where to start. Can you tell me: Has this happened once? Is it a recurring phaenomenen? Could you try X and tell me what Y looks like after that?" and so on.

Quite often when people get this kind of feedback telling them what to do and telling them (directly or indirectly) what they didn't do in the first place they will learn. Maybe not immediately but the more reports they're filing the more they will (often unconciously) anticipate what you're going to ask them and provide the answer directly.

Yes, this is a step-by-step process and will not fix all the communication problems until tomorrow morning, but it's a start nevertheless.

  • 2
    Punish them for bad reports: respond with a list of questions that they need to answer, and tell them to resubmit their support request when they have the information. Back of the queue! Nov 23 '11 at 5:23
  • Sometimes it's sufficient to have a proper annotated screenshot of the bug/error together with meta information. Usersnap is a small button which you can add to your web project to enable easy bug reporting.
    – Gregor
    Aug 21 '13 at 13:02

One thing that I've seen several open-source projects do is to write up a standard "form" for bug reports, with sections for commonly-needed information.

If you have a bug reporting site or application your customers have access to, see if you can make a blank version of it the default text of the bug description field. Otherwise, put it somewhere they can find it (or where you can point them at), e.g. on your site or in the install directory of your product.

For your case, this could be something like:

URL where the error occurred:

What you did:

What you expected to happen:

What actually happened:

<Some other information you (ckeller & colleagues) often find useful>:

Any extra information you think might be relevant:

("You" here refers to the customers)

The idea is to encourage them to provide useful information by providing a list of the kind of information that is most often useful.

  • 1
    +1: When faced with a template, people generally try to fill it in. And if they don't, it does not take much of your time to simply ask them to fill the report. Also, by guiding them carefully, you may avoid the typical "It doesn't work!" May 4 '11 at 17:14
  • 5
    We implemented this pattern at work. 75% of all bug reports have a variation of "I expected it to work" in the "expected" field and "It didn't work" in the "actual" field. Sigh.
    – Charles
    May 4 '11 at 23:33
  • 1
    @Charles: Then close the report with a comment of “Resolved: no action”. May 5 '11 at 10:46
  • @Donal Fellows - I would reject it as "Duplicate" instead.
    – mouviciel
    Nov 23 '11 at 8:48

Usually I ask them for a screenshot of the error every single time, and eventually they start sending me the screenshot with their error request because they know I'll ask for it.

I still have to call them up for more info on occasion, but quite often I can see the problem just by looking at the screenshot

But I agree with @Mahmoud's comment that the best way is to get the application to send you errors instead of relying on the users.

  • 1
    You've never had the case where you get a screenshot of a dialog box or something small that the user thinks is relevant but actually isn't? I get this all the time... May 4 '11 at 23:15
  • Actually I do get that on occasion, but when I do I'll usually ask them for a screenshot of the actual error. After a while they get used to sending me the actual error
    – Rachel
    May 5 '11 at 12:14

The pessimistic take: You can't. It's the same situation like 40 years before, except there are more users, more systems, more applications.

(Note that a pessimist is just an optimist with experience.)


Make it easy for them to do or they won't.

Preferably make the easiest way that they can report an error the way that provides you the information you need. This almost certainly means automating the error reporting process in the software.

Keeping a detailed log file, and having it attached the error report is a start.


When you finish the conversation with the customer, say to them "The next time this happens, please have data item A, B, C, etc.. ready for me". Of course, this only works if these are the same customers repeatedly calling back. I have had success with this approach, where the users learnt certain key things that would a) speed up the call, b) make overall resolution much quicker.

If most of them are one-time callers, it might be best to update the "ERROR!" screen with text that says "You must gather data items A, B, C, ... before you speak to our representatives". This will really depend on how much control you have over the app, so it may not be do-able at all. This is not a sure-fire way either, but hopefully it will get the idea into the customer's head that screaming "ERRORZ PLZ HLP!!!" is not enough.


The problem with error messages in modern applications is that it is virtually impossible to include all the context which might be relevant. Anything from the processor architecture to the time of day can be relevant, which is why both error reporting and error handling are more art than science. Systems like apport-bug are useful in that they collect relevant information and submit it to you. Unfortunately, until the days of matter replicators, time travel and Heisenberg compensators, there's no way to be sure that the information you get from users will be enough to debug or even reproduce the problem.


Log everything you need. We have a rolling log file of x mb. If something bad happens, the user sends the logfile and often that's enough to fix a problem.

Another option is to use a remote desktop client to see for yourself what's wrong. These days that's as easy as letting the client download an exe.


You are going to have to ask pointed questions and be very demanding of them to give you all the answers. Sometimes their complaint of the problem will be interspersed with their plans for the weekend, complaints about their significant other, or the weather. Try to keep them on task and ask them, "Ok, when you do X but don't do Y, what happens?" Annotate their responses so you start to build a sequence diagram of events that you can later go back and debug.


You can invest some time and add a 'Report a bug' red button in the top right corner of your app. When a user presses the button try to take screen shot, collect all available logs for the session, (may be its worth to) open the direct screen sharing to the user screen , show him the simple form and automatically send data to your server.

-Try to ask a user as little as possible if your app can get data itself. Screen resolution, OS version, user name, login, last actions and logs

-Assign a ticket to a user and provide him a link, so he know that he has bug number 1234 on www.yoursite.issues/1234

-Ask a user what he tried to achieve.

I think this all together, or even partially, can help you to receive enough data and show the user that he can help you to make your software even better.


The easiest way is to use a tool that can "understand" what actually the client wants. There are many tools, but maybe the best is Usersnap. See this story here.

  • 1
    This is little more than a link-only answer. Your answer would be stronger and more valuable if you explained why the tool answers the OP's question.
    – user53019
    Feb 12 '14 at 16:50

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.