Getting good reports from users

Earlier this week, Rob Soden asked an excellent question on Twitter: how do you train your non-technical co-workers to file useful/actionable bug reports? Is it possible?

It is, but this question doesn’t just apply to developers. Operations people need useful incident reports from users as well. Users generally don’t provide unhelpful reports maliciously.. In my experience, reports are often the least useful when users are trying to be the most helpful. A healthy relationship between a customer and a service provider means that everyone is working together. Users often don’t know what information is helpful, they just want to go about their work.

A useful report contains the following:

  • What happened and what the desired result is
  • What the user was doing when it happened
  • Any changes that may have happened
  • If the product/service ever worked and if so, when it last worked
  • If the problem is reproducible and if so, what steps are required to reproduce it

A useful report does not contain speculation about what the solution is. But what, Rob asked, if the lesson doesn’t stick? It gets annoying having to ask over and over again. As with any repetitive task, the answer here is to automate it. One option is to have a canned response at the ready. This way, you polish the text once and you never have to worry about irritation creeping in. A better solution is to have a website that explicitly asks for the information you need. This saves a round of back-and-forth and hopefully increases the time to resolution.

The most important part is to modify the process as you learn. Tweak the questions to make it easier on the users. Provide multiple-choice or other defined-response choices when you can to reduce ambiguity. No good process is ever in a final state.

Leave a Reply

Your email address will not be published. Required fields are marked *