How to get the best technical feedback possible from a non-technical user when supporting application issues?

Question

A common problem I find when dealing with non-technical users when supporting technical issues is "translating" what I'm hearing to what actually is causing the problem. In our current application we do things like provide error message details that can be forwarded to our support team, however my question is:

1. Is there an approach that any of you have implemented and found successful in helping the user provide quality information about application issues that can help in troubleshooting? If so what is that approach?

What I'm hoping for is a clever approach to designing error message displays in such a way that when the user communicates the issue, it is a better primer for quickly resolving the issue. Thanks!

Answer 1

I've found that logging of end user activities and errors is an effective tool as this reduces the amount of information you require from the end user.

You can also ask the end user to provide screenshots which typically captures URLs, input, error messages, etc..

EDIT: In my experience though, any prompt for information even when provided to help desk staff is typically ignored or misinterpreted. My suggestion is to capture as much information as you can automatically as that eliminates human error/oversight.

Answer 2

If your users aren't computer litterate, then you should use VNC to see what's happening on their computers. Despite network lag, you should be able to see more things happen than the user does

Answer 3

When your application encounters an error, have it log or "phone home" the actual error in addition to showing an error message to the user. The user can then send you the error logs (or you can look at them in your error database if the application "phones home"). This way you can get more detailed information directly from the application. Logging additional information about the application state will help to isolate what the user is doing when the error occurs. You may want to include the ability to turn this logging on/off so that it only occurs, or occurs at different levels, based on some flag. This would allow you to restrict some logging to only those situation that require extensive logging to narrow down the problem.