I recently talked with my coworkers about strategies for troubleshooting. We were focused on how to troubleshoot issues while chatting with our users, but I wanted to start with a basic workflow for troubleshooting bugs in any support medium. Here’s what I came up with:
- Understand the problem from the user’s perspective
- Determine if it is expected behavior or a bug
- Search for previous reports of the bug or discussion of the feature
- Test to see if the bug is reproducible
- Report the bug in the appropriate place
I feel pretty good about that workflow, in terms of describing how you can identify and report a bug. As soon as you start considering the rest of the support picture, though, it gets more complicated.
Here’s a rough flowchart I just sketched out that takes into account the larger context:
I like how that flowchart encompasses not only what to do while troubleshooting a bug, but also some ideas for how to handle non-bugs — and what to do about the user who’s still stuck even after you identify and report a bug. Because let’s be honest, some bugs aren’t going to get fixed, or the fixes might take a while, and we’d still like to help those users get to where they want to go. I guess that’s a more holistic view of troubleshooting, beyond being a bug collector. 🙂
I’ve always appreciated WordPress support. This post explains why 🙂
LikeLike
I was inspired by your post to create a Troubleshooting graph as a thank-you for the excellent support I’ve always received from WordPress.com. You can find it below:
I hope you find it useful – feel free to use as you see fit 🙂
LikeLiked by 5 people
Wow! It looks so formal now. 🙂 Thank you!
LikeLiked by 1 person
A pleasure. Glad you like it 🙂
LikeLike
Nicholas, can I ask you which software did you use to create this flowchart?
LikeLiked by 1 person
Good ol’ CorelDraw (12) 🙂
LikeLike
I love this. Add it to the training guide?
LikeLiked by 1 person
Thanks for creating this flowchart, Rachel. I am going to print it and use it in my day job. Cheers.
LikeLiked by 1 person