Have you ever worked at a company with an in-house development team? Then you know developers are always busy and have a ton of work on their backlog. That’s something that won’t change in the upcoming years, unfortunately.
In this article, I share my thoughts on how we can make it as easy as possible for the development teams to understand our bug requests so that they are able to prioritize, plan and get more things done.
Here is a quick overview of where this article is about.
The first step is to understand the product. What is the product? A product is something that is created through a process and that provides benefits to a specific market. In our case, this could be a SaaS website or e-commerce platform, for example.
Within the product you have a core, it’s the basic part that the product can’t function without. Take Uber, for example, one of the features they have is that you can see where the Uber driver is. What happens if that’s broken? The right answer is nothing, it’s a nice feature to have that builds on top of the core of the product. The core product of Uber is that you can get a driver from your specific location to somewhere else.
Everything that’s broken but isn’t related to the core product has less priority than things that are broken and are needed to keep the product going. An example of such functionality can be payment options. If payment isn’t working, your users can’t do the payment, and you don’t have revenue coming in. Your users can’t buy the thing they want, so they’ll leave. You might never get them back from this point. This has a direct impact on the business.
In short, think about what the core of the product is and what isn’t. This way, you can start prioritizing yourself before you even contact the product owner or the development team.
Now you’ve learned a little about the ‘product’. The next step is what you probably often already do. You want something from the development. Let’s start with defining the problem and what the development team needs in order to reproduce the bug, so they can fix it.
The first step to take bug requests is by writing down the bug you’ve found. Do this as clearly and detailed as possible including date, time, browser, device and the URL.
For example, I’ve found that the search form on our homepage isn’t working anymore. The form itself isn’t the problem, but something goes wrong when I try to submit the search. I tried this on 23-03-2020 in the Chrome browser on a mobile device. This is the URL of the page: theurlhere.com. My input was the date 04-04-2020 to 06-04-2020, after selecting these days I’ve submitted the form.
You’ve written down the problem, now it’s time to research the bug. This is important because it saves development time. For example, check if this problem occurs on other pages and other domains (if you have multiple). Does this always happen, in all browsers? Have you tried incognito or a browser that you don’t use often? Did you deactivate all ad blockers?
Besides answering the questions I mentioned, you could also clarify the problem with data from Google Analytics, for example. This way you can find out the impact of the problem and define the priority. Even if the impact on the core of the product isn’t that big (highest priority) you still have lowest to high priority available to choose from. If data indicates you’re missing a lot of revenue because an upsell is broken, you could give these bug requests high priority instead of highest.
Add the findings to your case after writing down the problem. Things like these save time for the development team since they don’t have to check and research the bug extensively anymore.
Not sure what to research? Contact the UX Designer or Product Owner in your company, so they can help you out.
Not everybody is technical, and that’s fine! If you can find a solution or multiple solutions for the bug requests it’s already, it’s nice to mention these. A really black and white solution could be to remove the functionality completely until the bug request is fixed, or add extra text to the place that contains the bug, so users have a workaround.
Keep in mind that the development team needs time to fix the bug requests as well, it might in some occasions even take days before a solution can be found and added to the website. You could give them a temporary solution like for example remove a certain input field from the contact form until it’s fixed.
The PayPal payment option in the shopping cart checkout isn’t working anymore on 08-04-2020 around 12:19. The browser I’ve been using is Chrome on my mobile phone. This is the URL {URL HERE} to the page: and I was trying to buy the new book called Rework.
I’ve checked other items that can be bought on our website and this bug occurs there as well. The other payment options seem to be working. I’ve used different browsers like Firefox and Safari to check the bug, and I’ve also tried incognito mode. I couldn’t find anything on Google related to the PayPal payment option being offline at this moment.
In Google Analytics I found that this bug request occurs since 07-04-2020 since no more PayPal payments came in. PayPal is our number 2 most used payment option.
It’s important that this payment option is fixed as soon as possible since it’s our second most used payment option. Until it’s fixed, it would be better for the user experience to remove the PayPal payment option, so our new users don’t know we have this payment option, they will probably choose another one.
Bug requests priority: Highest
Doing bug requests can be time-consuming, but it has to be done in order to get the development team working on the most important things for the business. Many people don’t understand how the SCRUM/development team is working, so I hope this article gave you some clearance on that.
If you have any questions, feel free to drop a comment or hit me up on LinkedIn. I’m a UX/UI/CRO specialist working remotely from the Netherlands. Find out more about the difference and overlap between UX and CRO in another article I wrote.
Working remotely from Groningen, the Netherlands. Get in touch and let’s schedule a meeting, no strings attached.
Get in touch
