Bugs happen, it's a fact of life. But setting up a standardized system for users to report them can make a world of difference. Let's learn how.
The Status Quo = Freeform
When users find a bug in your software, what do they do? If you're like most places, they open a support request, followed by entering a big block of undifferentiated text about what they found. This can be helpful, if they know what they're doing, but it can also be vague and slow down your debugging process.
I found a problem in your software. When I click the Submit button, it doesn't work. Could you fix this, please?
The Problem = Ambiguity
While it's good of them to point out flaws in your software instead of just silently leaving and never coming back, this report isn't really as helpful as it could be:
- Where are they in your software?
- What did they try to do before they clicked the Submit button?
- What's their definition of "doesn't work"?
There are so many questions, and while you can definitely send responses to clarify their initial message, this costs time and money, while your software is still out there broken. Surely it would be better for everyone if you could get as much information as you need in the first message.
The Solution = Templates!
When you're asking users for information, it pays to be specific. At the same time, you don't want to overwhelm your support reps with irrelevant details that only serve as either ignored boilerplate or distracting red herrings.
The best solution is to break things down into a core of information you need from every request, and then rely on your reps to extend as needed from there.
Here's a sample template you could try using right now:
Hi, welcome to YourCorp's bug submission form! We really appreciate you taking the time to help us get better, and promise to get back to you with a solution as soon as we can.
Question 1: What were you trying to do? (This could be something like "I tried to change my password" or "I tried to buy a widget")
Question 2: What did you expect to happen when you performed the above action? (ex. "I expected my password to be reset" or "I expected a pop-up message saying 'Order Received'")
Question 3: What happened instead? (ex. "I tried to use my new password, and it was rejected" or "A pop-up message appeared, but it said 'AutoXHR error 24601'")
Question 4: What's the best way to reach you in response to this submission? (ex. enter a phone number or email address you have access to)
Click below to submit your bug report, and thank you again for your time.
(submit button, with confirmation message)
What you do with the results from this form are up to you: It can be emailed to someone, sent to your support hub's API for automatic ticket creation, or otherwise organized however you'd like for your workflow.
The Result = Clarity
Now that we have a form, let's see how our initial bug report would have looked if it had come through our new templating setup:
User was trying to: I was trying to modify the group one of our new employees was assigned to.
User expected: I expected the employee to be shown as a member of the group I assigned them to.
What actually happened: When I clicked the submit button, it didn't do anything, the screen didn't change, I didn't get an error, it just was like the button wasn't hooked up to anything.
Contact info: email@example.com
From here, your support reps can test this sequence of events, see if the same thing happens to them, and work the issue much more quickly than before.
Bug report templates are a great way of making your debugging process quicker and easier. And when it comes to squashing software bugs, every little bit helps.