Without users, you’d struggle to know what’s going on in every corner of your app. Getting bug reports from users is useful, and when you consider how they take the time to write to you instead of jumping to a competitor product, you have to be flattered!
But your users aren’t trained bug reporters and they just want to get on with their day. That’s why some bug reports simply say “it’s broken.”
It is tough to fix “it’s broken.” You need more details.
Here’s how to coax more information out of your users.
Use Instrumentation in Your App to Understand Your Users Better
With the right analytics and reporting you can see the actions your users are trying to perform. Reporting will help you understand what the user was doing before they encountered the issue.
You can handle this with your own Logs table, which would have `user_id`, `page`, `action_performed`, `date_and_time_of_action`. Logs allow you to see what pages and actions a user took at a given time.
Once you have the table made, you need to populate it every time a user performs a key action on your site.
If someone fills in a newsletter form that appears at the bottom of every page, then you could add the following information to the log.
- User_id: 55
- Page: /blog/5-tips-when-writing-example-pages
- Action_performed: newsletter signup
- Date_and_time_of_action: 2019-11-11 07:20:15
If you don’t want to make your own log system, you could always set up Google Analytics or MixPanel to do the same thing.
Find User Browser Setup to Quickly Debug Issues
If you’re building a mobile application, the crash reports you receive will generally come with useful device information.
For web-based applications, bug reports can come from users with browser and device combinations you haven’t logged in your system.
Prompt your users for version information by having them fill out a quick form that asks for operating system and web browser versions.
Alternatively, you could ask them to visit a site such as http://www.supportdetails.net and share the results.
Ask for More Information to Narrow Down the Issue
When you get back to your user, make it easy for them to send you the information you need. Explain where they can find information about their setup, using links and images where possible.
For example:
I’m sorry to hear you’re having issues with this, could you let me know your username? You can find it by visiting site.com/profile.
The most common information left off a bug report is the steps to reproduce. Adding to the challenge, the person fixing the bug usually hasn’t seen the original support ticket and doesn’t have any context.
You should have a message ready to go asking the user for that extra information you need. Your help desk might have a way to store up small text snippets for you, or you can use an expansion app like we do in TextExpander.
For example:
So that we can accurately recreate and solve the issue, we’d love to know what happened before you ran into the problem.
Can you let me know:
– Which page you were on when the problem occurred
– Which page you came from
– If you were entering details into a form, which details were you entering
– Please send a screenshot of the last screen you see before the error happens (On a Mac, press CMD+SHIFT+3, on a Windows PC press Windows key + Print Screen)
The great thing about making this a “snippet” of reusable messaging to users is you can share it with others on your team who deal with customer issues and collaborate on the best wording to use.
What is the “Best” Bug Report You’ve Received?
Have you received an excellent bug report from someone? Either because it was super detailed and easy to follow, or because the bug itself was just so random it made you smile! Let us know by sharing great issue reports in the comments below.
